Currently, I gave myself the task of remaking all images on my website. But before I can do that, I am presented with a big dilemma of choosing appropriate image dimensions, to satisfy ever growing variety of modern devices and screens.
Modern devices grow in both dimensions and pixel densities. No longer exists a simple choice between Retina and non-Retina. For example, iPads use 264ppi, iPhones use 326ppi, 401ppi, 458ppi and 460ppi, while desktop displays use anything from 4k to 6k, usually in 218ppi to 228ppi density.
So, how should I determine generic image dimensions to satisfy all, or most, of those pix density standards. What image dimensions do I actually use and input in image-stack settings?
I’d be very interested to hear thoughts and opinions on this topic from as many of you as possible, because there’s many possible approaches. Perhaps some of you already did a thorough research of this topic?
For BG images use 1 single 2000px wide image and then for all other images reduce the size to the maximum that they can appear on the page and just use 1 image. Then optimse well and also create a webP version.
If you need convincing, then you could create an image heavy test page and check in PageSpeed Insights and alter a few image sizes or add the webP versions, etc…
That’s, more or less, what I’ve been doing up until now, except I never used webP format before.
I neglected to mention, that my goal is not only to get smallest possible file size, but also to retain as much image quality as possible.
So, up until now, my maximum image size is 2500px. That looks great on my old non-Retina Apple Cinema monitor. But I doubt it would look good on a new 27" 5k iMac (which I don’t have, so I can’t see it for myself) – hence my call to you, guys.
I think anyone with a large wide monitor, will have the good sense to not use a browser in full screen. Even if they don’t have that good sense, they will be used to seeing reduced image quality images by browsing in full screen or may not even notice it.
Both of you @Webdeersign and @Jannis give valid reasons not to be too picky about image sizes. And—as I mentioned— that’s been my own approach so far.
Indeed, my website is only 980px wide and I’m not worried about site-wide images. But I am wondering about full-width banner images and such.
I wonder if I could get some comments from photographers, because they tend to have higher quality requirements for their images than regular web developers. @Nick, care to share your perspective?
On another note, I have worked out a Retrobatch workflow for scaling images and outputting both JPEG and webP format. It seems to work great. I can’t wait to input my final image sizes and start using it.
I have settled on @habitualshaker Srcerer stacks for the majority of my images, they work wonderfully. .
Image sizes: the stack allows multiple sizes of the same image and I have settled on 600 / 900 / 1500 px, with 2100px versions too for banners and full width images. The background images with text overlaid on my wildlife site are 900 / 1500 px.
I’m using Lightroom / Camera RAW for output, and using 50% quality for the majority, occasionally 40%, but that really is not good enough. I have not checked G speedtest recently, but results were pretty good when I did. For me, images are critical to what I do, so I will accept speed compromises (to a degree) as a trade for the look of the image. Hope this helps?
One thing to remember - sharpening images is critical to the look, as is colour management, so the colours are corrrect - I was looking at a showpiece on the Adobe site yesterday and the photog had turned colour up to 11. As a result, his credibility was down the pan, as no professional would dare deliver such hyper-real colour as it cannot be reproduced in print.
Thanks, Nick. So far, consensus seems to be pretty solid: don’t go wild on large dimensions. This is good enough for me. I will stay my course and maybe even lower the max size from 2500px to 2100px.
As for my own workflow, it includes Lightroom (old pre-2018 images) and Capture One (new 2018-to-present). I am exporting one rectangular image of maximum size and one square version with custom crop/composition (for galleries’ thumbnails). Then I open Retrobatch workflow, scale my rectangular image to 4 different smaller sizes and output them as JPEGs and as webP formats.
If anybody would like to add something to this thread, I am all ears. Hopefully, this discussion will help not just me.
@fapkogi there are many advantages in terms of image quality by outputting each file individually from the original RAW file - it saves compresion damage and (I assume?) will improve size as each file is rendered from non-pixels (ie RGGB) to a pixel-based RGB image. I did a lot of testing with this and C1, back in the mists of time and the time and trouble were worth it, but it was (still is) a slow way to work.
Your workflow is my plan ‘B’. The reason I prefer Retrobatch approach is that I can output all required sizes—JPEG and webP—in a single run that way. As far as I can tell, C1 does not output in webP format.
EDIT: By the way, Retrobatch resizes (scales) images without quality degradation.
The recipes feature is brilliant isn’t it @LiveShots ? Lightroom Classic has the same option, sadly the new multi-device based LR CC doesn’t.
@Fapkogi it has been discussed elsewhere (I think I started it!) but I have real reservations about WebP - in reality it is only another flavour of JPG )If you change the file ending from .webp to .jpg, the file opens as normal). Google have so many agendas to suit themselves that I now actively avoid anything they recommend.
(Now Rambling, feel free to ignore…) All google scripts have been removed from my own sites as they are quite meaningless - I and so many others block them by browser choice (DuckDuckGo is now my default browser on all devices) that stats are not nearly so helpful as they were. FB warn that they cannot provide accurate stats for ad views too.
You shouldn’t have any reservations IMHO. If you change the jpg extension to webP, then it won’t even display on non capable webP OS’s.
WebP isn’t jpg and can create significantly smaller images that you will not be able to determine what the image type is, by looking at the images. If you are using many or large images, then using webP images (in addition to the fallback jpg) can create a significant reduction in download times.
There is a lot of push back from RW users because very few image stacks support webP, but the good stacks certainly do and allow seamless access to this potential speedup.
I wrote a post a while ago that many misinterpreted. The post was about the speed of a well built Source site is so fast that you don’t need to go as far as also using webP images, to get a 100% Google speed PageSpeed result.
I wasn’t saying webP images are not required or that they have no value. Using webP images give a further boost to performance. Like turning the amplifier up to 11.
I totally agree with this statement. I certainly do not use any Google scripts either. The only thing Google I do use is their Noto font, which is said to support all (or almost all) languages in the world. It also looks modern and pretty nice. But even this font is warehoused on my server rather than called from Google. Also, I ceased using Chrome browser and Google Search several years ago.
Well, off I go to start remaking all images on my site and experimenting with the webP format. Thanks to everyone for participating in this discussion…
I certainly don’t agree with the Google model of world domination, and there is a not so secret agenda in their punitive treatments of slow websites (they want the web rapidly accessible to smartphones on G5, so they can quickly identify what their owners are looking at and target them with something to buy). Nonetheless I agree with Gary that good practice in web design is to aim for the best performance possible. From that point of view, even 2000px/2500px images seem excessive. Retina screens are lovely, but very few images need Retina quality anywhere apart from the focal point. An image with 100% sharp depth of field a feels a bit weird, because that’s not how we see things. Hence the vogue for HDR having quickly passed. On a laptop screen a 1270px image at normal resolution is fine for full width, especially if there is an area of about 200-300 pixels at Retina resolution.
It really depends on your target audience? For casual web viewing, with a 50% mobile audience, 1275px will work fine and as you say, laptop.However my own audience tends to be photographers, have far higher resolution screens and a predominance of Macs, so retina screens. I find 600/900/1500 with the odd hero image at 2100px works well.
PS I do like your idea of layering images, will try at some point, not sure I am so worried though as I think the 600px images cover the phone / 5g scenario.
Of course, if you want beautiful images that are as crisp as can be, go big without compression! Desktop users tend to use wired internet access, with much faster download speeds, so this is less of an issue. But… the new compression formats (WebP and AVIF) are pretty amazing at saving detail. And it’s usually worth comparing a 1 for 1 image with a 2 for 1 Retina image just to see how noticeable the difference is. It will be more so on some images than others.