> The accepted practice is to not add lazy-loading to images above the fold, especially the LCP image.
I didn't know that. Apparently (at least according to Claude) you shouldn't use loading="lazy" on images that you expect to always display because doing so causes them to not be loaded until the browser has determined they are definitely in the viewport, which is a minor performance regression.
LCP = Largest Contentful Paint, the Core Web Vitals metric for when the largest visual element finishes rendering. That's usually the largest above-the-fold image.
Yes but the post is explicitly about images that are initially loaded only on certain devices/screen sizes, hence the need for conditional application of lazy loading.
Attempting to lazy load an LCP could delay the loading the image as much as 15% [1].
Lazy-loading is an effective technique we can use to delay non-critical resources at the beginning of the page load. However, a considerable problem occurs when we apply this technique to an LCP image. Lazy-loading prevents the browser from loading the image immediately because it takes time for it to realize that the image is in the viewport and needs to be loaded. According to some lab tests, this could cause a 15% regression in LCP performance. This might sound obvious for someone working on web performance, but the fact that nearly one in five web pages are doing it is a sign that it’s not very well understood by most other web developers.
I like this solution, it looks very simple and should’ve been consider as part of best practices if it works technically. However, I also think that this whole trade off is broken from the beginning, it should be part of browser’s set of rules to either decide or not it should render the image or not by default, and the decision of eagerly load an image should just an hint given by the developer as a scape hatch. The current approach forces the decision to be forcefully deferred to the application which needs to guess what’s the best approach for the current set of devices in the market which also adds a constant maintenance burden.
Browsers already have an early scanner to look ahead for things that it may need to load soon, such as images, and piles of heuristics. Those heuristics are hard in part because many HTML authors don't bother marking up their image dimensions. The lazy attribute helps avoid loading images that the author can be fairly sure will not be in the initial viewport, so is an optimisation hint to override some of those heuristics. So it saves some bandwidth and helps ensure that things above the fold are not fighting things below in the initial viewport construction. So we're about two levels of optimisation in here, but browsers do a reasonable job when fed good img tags anyway.
> Not documented anywhere (but seems to work fine in major browsers)
Which part of it is not documented? Putting device width dependent preloading in HTTP header? MDN says that the HTTP link header works the same way as the link element, and also that the link element a has media attribute : https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
It’s not a hack, but you may find more documentation for the equivalent preload values expressed as a <link> tag. There is (near) parity between that and the HTTP Link header. The values used in the article should work in HTML as well.
I guess it depends highly on what you value. I dislike site that eagerly load all their images below the fold, since on my mobile phone I have a metered data plan. Unlimited data is still uncommon or very expensive in many countries. For example I pay $13/mo for 650Mb of data, which is one of the best value plans (under $40/mo) from any provider.
> The accepted practice is to not add lazy-loading to images above the fold, especially the LCP image.
I didn't know that. Apparently (at least according to Claude) you shouldn't use loading="lazy" on images that you expect to always display because doing so causes them to not be loaded until the browser has determined they are definitely in the viewport, which is a minor performance regression.
LCP = Largest Contentful Paint, the Core Web Vitals metric for when the largest visual element finishes rendering. That's usually the largest above-the-fold image.
Yes but the post is explicitly about images that are initially loaded only on certain devices/screen sizes, hence the need for conditional application of lazy loading.
Attempting to lazy load an LCP could delay the loading the image as much as 15% [1].
Lazy-loading is an effective technique we can use to delay non-critical resources at the beginning of the page load. However, a considerable problem occurs when we apply this technique to an LCP image. Lazy-loading prevents the browser from loading the image immediately because it takes time for it to realize that the image is in the viewport and needs to be loaded. According to some lab tests, this could cause a 15% regression in LCP performance. This might sound obvious for someone working on web performance, but the fact that nearly one in five web pages are doing it is a sign that it’s not very well understood by most other web developers.
[1]: https://calendar.perfplanet.com/2022/lazy-loading-lcp-images...
I like this solution, it looks very simple and should’ve been consider as part of best practices if it works technically. However, I also think that this whole trade off is broken from the beginning, it should be part of browser’s set of rules to either decide or not it should render the image or not by default, and the decision of eagerly load an image should just an hint given by the developer as a scape hatch. The current approach forces the decision to be forcefully deferred to the application which needs to guess what’s the best approach for the current set of devices in the market which also adds a constant maintenance burden.
Browsers already have an early scanner to look ahead for things that it may need to load soon, such as images, and piles of heuristics. Those heuristics are hard in part because many HTML authors don't bother marking up their image dimensions. The lazy attribute helps avoid loading images that the author can be fairly sure will not be in the initial viewport, so is an optimisation hint to override some of those heuristics. So it saves some bandwidth and helps ensure that things above the fold are not fighting things below in the initial viewport construction. So we're about two levels of optimisation in here, but browsers do a reasonable job when fed good img tags anyway.
> Not documented anywhere (but seems to work fine in major browsers)
Which part of it is not documented? Putting device width dependent preloading in HTTP header? MDN says that the HTTP link header works the same way as the link element, and also that the link element a has media attribute : https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I could not find this hack documented or discussed anywhere, that's what I meant.
It’s not a hack, but you may find more documentation for the equivalent preload values expressed as a <link> tag. There is (near) parity between that and the HTTP Link header. The values used in the article should work in HTML as well.
> It’s not a hack
Yeah, this isn't a hack; this is what media queries were made for.
Now, this is a hack!
You had to do this to make :hover work correctly for IE6—IE8 [1]:
[1]: https://pawelgrzybek.com/internet-explorer-just-hit-the-end-...I agree, this was not a hack. It is combined behavior from documented features (preload with media and lazy loading).
Nice pure-declarative responsive tweak!
Not a fan of lazy loading. My time is more valuable than bandwidth.
I guess it depends highly on what you value. I dislike site that eagerly load all their images below the fold, since on my mobile phone I have a metered data plan. Unlimited data is still uncommon or very expensive in many countries. For example I pay $13/mo for 650Mb of data, which is one of the best value plans (under $40/mo) from any provider.
Isn’t that why you should like it then? It saves your time because you’d get the page earlier
I dont think this works.
I just tested on Chrome Android via remote inspect using developer tools. It loaded the image even when the image was below the fold.
likewise - it always loads the image up front.
Are you sure? I can see the image loading much later on mobile: https://pagegym.com/compare/uu5641qndi/4d3ifzdbxk
Is it the “min-width=1024px” in the link that causes it to not load on smaller devices?
Yes, it's a media query (https://developer.mozilla.org/en-US/docs/Glossary/Media_quer...) on the <link>. Only if the media query passes will the link "activate".
To not preload, yes