Slight change of plan

I've been coding, and re-coding a lot recently. Optimising. Not SEO exactly - more general. Optimising in the sense of performance and ease of use. A big part of of this recent surge is using JSON to pass around meta data. I can't work out whether it's a genius move or a total idiocy for not it years ago. It feels like both.

Images and emails

Images and email are the two areas of development I find the most challenging. By 'email' I mean the automation of sending email from a website - password reminders, events listings, news and other general web content and that sort of thing. Developing a CMS that takes info from a database and delivers it via a browser is relatively simple. Taking the same info and delivering it by email is a different pescatarian kitchen appliance. You can't reliably use modern HTML in emails. If you look at a MailChimp template - possibly the global leader in email delivery - you'll see a structure based on tables which was common in the late 90s before CSS, Web Standards, Web 2.0 and all that.

There are other aspects that make things tricky. Image tags on a web page don't need to include the domain name they're on, eg. they can be '/images/photo1.jpg' rather than 'https://www.mysite.org/images/photo1.jpg'. This might not seem like a big deal, but if users of your system decide to add images to a page without the domain name and then decide they want to send the contents of the page via an email function on a website, then you have a problem. A background process used as a mail queue for multiple domains won't know what the missing domain name is automatically, or whether there's an SSL certificate and to use 'https' rather than 'http'. The same issue affects links too.

The main issue with images is the large number of variations needed to supply a set that incudes one for each potential view - ie screen size, device resolution, device rotation and so on. The maths aren't that hard, and in situations where you might post a page with a few images, it's not that big a deal. However, you might have an e-commerce site with 1,000 products with each one needing 20 variations. If the original image is uploaded from a phone or tablet without being downsized it might be 3 MB or so as a JPEG. To make a variation of the file it needs to be opened and read into memory, which means uncompressing it to say 50MB. No big deal unless the variations are created on demand. Visiting a page featuring 10 or 12 products that each have an image that need 20 variations generating at the same time and, well, you're going to see some lag. Maybe not that much, and maybe you and your site's visitors won't really notice. But chances are Googlebot and other crawlers will, as they're more likely to be the first visitor to your content.

Solutions

I've haven't written this with a 'tada' ending. I'm still experimenting with this stuff. I've limited the number of images that are automatically generated for each view, and added a new database table that tracks missing variations so that they can be generated when things are quiet. Meanwhile, on the email front, I think I'm just about ready to send a few tests.

I suppose once all the technical stuff is sorted then the next problem is coming up with interesting pictures and pithy prose to post online and/or send by email. Although I do have a cat, so you know, there's always that option.