Hi everyone, I have been looking at GTMetrix etc to try and get my site better optimised. Recently, I have been getting the error "Serve scaled images". I have spent all night trying to get it sorted. My other images do not have this issue that I am getting now (other images are displayed in fallback and css grid with varying sizes, percents and max- none). I have try to tweak images with their settings but any new images I add to the website I get these annoying messages.
Coffeecup introduced in RSD 1.5 the ability to add easily different sized dimensions of the same image for different breakpoints or media queries. This allows you to use a smaller dimension for mobile to download faster but a larger dimension for desktop.
If you only add one link to a picture below the lowest breakpoint it applies to all breakpoints and is considered the source and given the src attribute. If you were to add additional links to the same picture element at higher breakpoints then you create a source set of pictures. The addtional picture links are given the srcset attribute. When the browser loads the page, it will find the picture you have in the srcset group for the right media query or breakpoint you have set. This saves bandwidth and supposedly gives you points for having a faster and more responsive website page.
Thats about it in a nutshell.
If your image is 85kb for example and you use that for both mobile and desktop, then the mobile device is obviously going to "struggle" downloading the 85kb compared to a desktop computer on a high speed land line.
It could be that the error message is triggered because you exceeded a total number of seconds allowed for a group of images to download quickly. Was the image toward the bottom of the loading queue ? Was it the largest image in size on the page ?
Using the srcset is a lot of extra work because for each image you have to change the size of the image and save it in a external photo editor. I have used 400w pixels, 800w pixels, and 1600w pixels for each picture. It does start to become complicated too....what about retina image display. You need a picture 2x the size for that.
One could even challenge the use of the picture tag. Most people now agree that the better way to serve images is by width not breakpoints or media query's. With grid now in the picture it complicates things further. I certainly do not want to be constantly editing photo sizes to react to my changes of the grid. I can actually make a grid pattern that changes within the media breakpoints too.....how do I serve a image size for that change ? The answer is to use width based photo serving and let the browser decide which photo size to use.
We asked for just a simple <img> tag but did not receive one. It would probably be useless unless they discontinued the use of the picture tag which would then free up the reserved srcset attribute needed for proper coding of the <img> tag. As far as I know, Coffeecup is the only software that uses this approach. But I can live with it because there are SO many other advanced features that other software do not do simply and cleanly like Coffeecup.
Perhaps the recommendation
(a) is made on a page that is slower to load, because of the size or amount of other elements etc. on that page;
(b) is not made on a page that is pretty fast loading anyway.
The new images perhaps are further reducing the load speed, and so giving rise to the recommendation also regarding them.
PS I see once again a better answer has crept in while I was typing the above.
Then on the page where I want them, I pop in a picture element, and at the smallest breakpoint I select pic-s.jpg and select a max width, then move the slider past the breakpoint and change the picture to pic-m.jpg and select a wider max width... and so on.
I think this will be of importance if you have large images. With those tiny ones I mentioned above, the combination to one image solution would be better, I think.
Perhaps there isn't any need to change the pictures at all, although, of course, reducing their size will always help if it doesn't lead to a significant deterioration of quality.
Have something to add? We’d love to hear it!
You must have an account to participate. Please Sign In Here, then join the conversation.