The image loading attribute depends only on the fetchpriority value

[cavaglieridomenico]

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 the fetchpriority value (which already has correct logic and props via CMS).

Furthermore, this feature removes the auto value that is not present in the possible loading attribute values (HTMLImageElement: loading property).

How to test it?

Workspace

Screenshots or example usage:

Production

Workspace

[vtex-io-ci-cd]

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.

• No thanks, I would rather do it manually 😞

[vtex-io-docs-bot]

Beep boop 🤖

I noticed you didn't make any changes at the docs/ folder

• There's nothing new to document 🤔
• I'll do it later 😞

In order to keep track, I'll create an issue if you decide now is not a good time

• I just updated 🎉🎉

[iago1501]

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

[cavaglieridomenico]

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)

The aim of this PR is to achieve the possibility of managing the following cases:

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.

[iago1501]

Hi @cavaglieridomenico , I will agree with this PR, mainly because auto doesn't exist, and lazy should be the correct behavior instead of auto. But, I only have some concerns about it. When I changed the way you did, I just found some important metrics running through lighthouse on devtools, here they go:

When adding loading lazy in elements above the fold, it triggered a warning regarding a delay in largest contentful paint, which makes sense. The LCP will always be the LCP no matter if it's loaded lazy or not. The way it makes more sense, it's using the prop that we have thinking about performance optimization in fetching priority, which is byPosition. This prop will give higher render priority for the first images (above the fold), giving high priority, the browser will have high priority when downloading (better TTFB). Check loading attribute, the recommendation is to only add it in images that are positioned below the fold:

https://www.w3schools.com/tags/att_img_loading.asp

When checking the delay in LCP, we can find these information:

The worst aggressor for the content is the TTFB for the assets, when checking load and render metrics, they are responsible for only 6% of the LCP, so, for a better metric on that, we should check for a better cache policy on the images maybe or something on the assets server.

But, I agree with you that the shouldResize doesn't look useful and there's no auto in loading attribute, but, keep in mind that this implementation might not affect your use case about an increase in LCP.

Another important references that might also be useful to understand:

https://web.dev/articles/lcp-lazy-loading?utm_source=lighthouse&utm_medium=devtools
https://web.dev/articles/optimize-lcp?utm_source=lighthouse&utm_medium=devtools#optimize_when_the_resource_is_discovered

[iago1501]

TL;DR;

• shouldResize doesn't look useful for not loading eager
• loading attrib doesn't have auto
• This might not reduce LCP of the page (check above evidences)

[vtex-io-ci-cd]

Your PR has been merged! App is being published. 🚀
Version 2.90.0 → 2.90.1

After the publishing process has been completed (check #vtex-io-releases) and doing A/B tests with the new version, you can deploy your release by running:

vtex deploy vtex.product-summary@2.90.1

After that your app will be updated on all accounts.

For more information on the deployment process check the docs. 📖