General question regarding optimised images, compression and best practice going forward

Hi guys,

I’ve done some research but I haven’t really found the “perfect” solution which is “easy to understand and implement” for someone like me.

I found this thread on SEO to be pretty comprehensive and offer good insight but I quickly got tangled in a web so to speak.

Is a Javascipt solution the only way to have optimised images for the following variables, or is there a plugin(s) that I could use to achieve the same or similar results?

  • Connection Speed
  • Screen resolution
  • Minimum Acceptable Quality

Alternatively I understanding I could lightly compress each image as I go and that there’s even a Kirby plugin that does it but I’m hesitant to use too many plugins because I just never know about the support.

I’d like to have the lowest acceptable quality an image can be as a baseline, but also where able/logical to have the best quality and largest.

For example, I have a fast connection and a high res monitor. I want to see the images on the website in the best quality they possibly could be, if my net was tanking I’d like to have lower res images to a certain minimum quality, lets say an arbitrary DPR (Or DPI?).

It’s not 100% mandatory for my current project as I think simply compressing the banner images once off will temporarily fix the issue. However there’s no guarantee the people using the site after me will compress images, in fact they probably won’t. Also If I were doing a portfolio site for a photographer or an artist this would be a must.

On dimensions and compression

I recommend generating a compressed image (a “thumb” in Kirby parlance) from what the admins uploaded), or more likely 2-3 images (for use with srcset and sizes). Kirby lets you generate “thumbs” from a source image, specifying the width and/or height, cropping if needed, and the JPEG quality.

Define the source size you want, for instance if you’re generating a 800px image and a 1600px image, determine if it would work better with a 1600px source, a 2000px source or one even a bit bigger. Create a documentation for the client saying what dimensions, format and compression level each image type should have (for compression: probably 90-95% for a source JPEG, since you’re going to recompress it).

On the perfect size and compression level

Server-side JPEG encoders are often not great, and picking the same JPEG quality for all images in a given template is not ideal. Sure, you could get a perfectly fine image that is half of the weight with a better encoder or a manually picked, per-image quality. But your goal here is not to get to smallest possible solution, it’s to avoid damn the user uploaded a file that is a hundred times too big!!!. Automation requires compromises. :wink:

Also for photos I wouldn’t care too much about serving the perfect image size and density for a device. I’m on a 13" retina laptop, and photos that are not too blown up look alright. So if there is a display width of 600px (that’s 1200 actual pixels on my screen) and the source JPEG is 600px wide and not too compressed it’s acceptable. If it’s a bit bigger, say 900px wide, it’s alright. No need to jump for a heavier 1200px image, unless it’s a 1200px image made specifically for high density screens, with a higher compression ratio to keep the weight down.

For photos, “good enough” is generally the best approach for being able to actually manage the performance (in practice, not just in theory) and keep your sanity. Making sure you have a double-resolution image is more important for things like logos, symbols, icons etc.

On connection speed

Connection speed is hard to detect, indeed you need JavaScript and it’s unreliable and any image referenced in the HTML code as <img src="url" alt="…"> will be loaded by the browser anyway, so you need to remove or obfuscate the image code, then write more code for the no-JavaScript scenarios. Not sure it’s worth it.

On loading many images

Of course a single image’s excessive size or weight can be a problem, but you should also look at the uses cases on your site where you’re using many images (e.g. more than ten). A long page? A photo gallery? Maybe some images should only be loaded on-demand (after a user action) or lazy-loaded (loading when the user scrolls, see lazysizes for that).

On managing client expectations

To have any success with front-end performance on a project, the client must be on board and you should be able to argue against some client expectations and demands if they’re performance killers. On the other hand, some business goals may mean that performance becomes a secondary objective.

If you go for fewer and smaller images, fewer and smaller videos and fewer and smaller JavaScript widgets, you’ll always get a performance win. But you might also get a less successful website.


Thanks for this reply! It’s given me a lot of thought and provided good direction I will trial a few changes and get back to you. I think KISS approach is better eh :slight_smile:

Thanks mate I really appreciate it!

To everything @fvsch wrote (which I totally agree with) I’ll add:

  • when you use tools like WebPagetest, that always tell your images could be optimized, don’t worry too much about it. User-added images will never be ideally optimized.
  • photos can be compressed a lot more than we think. There are tools that try to find the best compression without perceptible visual difference (JPEGmini…) They are good, but still output images bigger than necessary for the web. Try lower jpeg quality (like quality 30 to 50 in Photoshop) then quickly switch between them to find an acceptable compromise.
1 Like