I’ve noticed that using the html api, the sizes attribute is missing for the webp version of the image when multiple images are in a grid, while the sizes attribute is present in the non-webp version of the image. This results in a bigger image being loaded than necessary.
The expected behaviour is that if the sizes attribute would be present under picture> source, a smaller image could be loaded to improve the page speed
@vperrin Thank you for bringing this to our attention! I have created an internal ticket and will have one of our devs investigate, it does appear to be a bug on our end! We appreciate the feedback and will let you know once we are able to fix!
Hey @vperrin thank you for following up on this issue!
I spoke with our dev team again, and we still have a ticket for this in our backlog, currently though it has not been prioritized for work just yet.
That being said, I did a little more digging, and a few things I noticed…1 is that I am seeing this behavior in Chrome, but Firefox for example seems to be displaying the correct images, so it is somewhat browser specific. Also, I noticed that, for example on your homepage even though the URLs for some images was showing width=2000, the images were still maxed out at 969px…which I assume is the size they were uploaded at? The reason I bring this up is to say that our Image API will never “upscale” any images, it will only “downscale” them or have the browser resize the image on render.
All of this is to say, this is definitely an issue worth exploring and further investigating once we have the resources for it, but I don’t think it should result in major performance issues for all users, so hopefully it is not a high priority issue for your site. If you think this is a blocker for your team let me know and we can take that into consideration as we prioritize and scope our work in the coming weeks.
Hi @TimG ,
Thanks for getting back to me, I agree that is not a very high priority.
When uploading the images, we didn’t fix the dimensions, so I’m not expecting them to be fixed at 969px.
I don’t know if it is related, but when using running the website through a page speed report, I get the warning that on desktop the images aren’t served in webp format (and pagespeed is based on Chromium) https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.sachini.co.uk%2F&form_factor=desktop
My team and I had the same negative experience with the 2000px image variant.
Would be nice to see a fix for it to satisfy angry google bot.
Page performance is money.
Thanks for investigating and looking into this.
If my understanding is correct, the source set is only used if the sizes attribute is present, which I think is still missing for the webp version.
Also, when I look at the network tab in the dev tools, the image that is transfered over the network is the large one.
Hey @vperrin it looks like you are on a large size desktop in that image, so it should be expected that the large image comes through. When I shrink down to a small view port, I am getting the smaller images in the network tab:
Thanks for getting back to me.
A few days ago I moved from the html api to the content api because of an issue I had with the html api (see Issue with symbol using custom component).
The situation seems to have improved. I think the only question I have left (but that is probably more like a feature request than a bug), when you have three pictures next to each other or in general when you have pictures that don’t span the entire page, can the srcSet element reflect that? To given an example, if we have three pictures next to each other, the srcSet element for 1600w has now a width of 1600, which 500 would be more than enough given we have three images next to each other.
