Open cavaglieridomenico opened 2 months ago
Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖
Please select which version do you want to release:
[ ] Patch (backwards-compatible bug fixes)
[ ] Minor (backwards-compatible functionality)
[ ] Major (incompatible API changes)
And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.
Beep boop :robot:
I noticed you didn't make any changes at the docs/
folder
In order to keep track, I'll create an issue if you decide now is not a good time
Hi @cavaglieridomenico , first of all, thanks for the PR.
To accept that, we will have to discuss some points.
Do you have a page in itwhirlpool where it really affected the LCP in a positive way? I tried to check this behavior on certain pages but in none of them is the image the LCP. When not fetching the image, I understand that this image is removed from the SSR, so, in this case, this isn't the LCP anymore since Google is only worried at this point with the SSR, that's why I would like to check
Do you have the lighthouse/pagespeed metrics with this improvement? I'm thinking about why the shouldResize is a condition there, and it looks like this is related to the CLS of the page, when should resize, since it's in runtime, this might cause a layout shift.
Regarding removing the auto, this is correct
Hi @iago1501, thanks for your feedback and insight into the performance topic.
I usually work on many VTEX accounts (itwhirlpool, frwhirlpool, bauknecht, etc.). Many PLPs contain a main banner image or a small banner image in the filter section which is the LCP element, instead of the first product-card image:
Otherwise many other PLPs do not contain any banner image and the first product-card image is the LCP element.
To analyze the second case we can use this URL as an example: https://www.bauknecht.de/hausgeraete/waschen-trocknen/waschmaschinen and here are related Lighthouse daily test reports for the last year.
Before 2024-07-30: LCP element: first product-card image product-card image fetchpriority: high product-card image loading: lazy product-card image size: 200x200 (prop via store)
After 2024-07-30: LCP element: first product-card image product-card image fetchpriority: high product-card image loading: eager product-card image size: 500xauto (default CDN size - I removed the size props from store to obtain loading eager)
Case of PLP without banner image LCP element: first product-card image product-card image fetchpriority: high product-card image loading: eager product-card image size: 200x200 (prop via store with no side effects on the loading type)
Case of PLP with banner image LCP element: banner image product-card image fetchpriority: low product-card image loading: lazy product-card image size: 200x200 (prop via store with no side effects on the loading type)
Case of product-card image on shelf LCP element: Home/PDP/Editorial LCP element on the page product-card image fetchpriority: low product-card image loading: lazy product-card image size: 200x200 (prop via store with no side effects on the loading type)
CLS in rendering product-card images is usually quite controlled using min-height rules.
What problem is this solving?
Currently resizing the images in the product-summary automatically sets the images to load lazy.
This behavior represents a performance issue especially in PLPs since the first product-summary image is usually the LCP element and if width and height are specified (obtaining the correct image size via CDN) the LCP element loads lazy (degrading LCP score).
The suggestion is to connect the
loading
value (without new props via CMS) to thefetchpriority
value (which already has correct logic and props via CMS).Furthermore, this feature removes the
auto
value that is not present in the possibleloading
attribute values (HTMLImageElement: loading property).How to test it?
Workspace
Screenshots or example usage:
Production
Workspace