IntersectionObserver has made lazy loading a lot easier and more efficient than it used to be, but to do it really right you still gotta remove the src and such, which is cumbersome. It’s definitely not as easy as:
<img src="celebration.jpg" loading="lazy" alt="..." />
Addy Osmani says it’s coming in Chrome 75:
The
loadingattribute allows a browser to defer loading offscreen images and iframes until users scroll near them.loadingsupports three values:
lazy: is a good candidate for lazy loading.eager: is not a good candidate for lazy loading. Load right away.auto: browser will determine whether or not to lazily load.
I’ll probably end up writing a WordPress content filter for this site that adds that attribute for every dang image on this site. Hallelujah, I say, and godspeed other browsers.
Easy lazy loading of images will have the biggest impact on the site as a whole, but lazy loaded iframes will be even bigger for the individual sites that use them. I’m into it.
Yes yes whatever native lazy loading of images but lazy loading of iframes is gonna be a goddamn game changer for ad tech: https://t.co/ADGc1UsVBf
— Laurie Voss (@seldo) April 8, 2019
I hope this pushes along the need for native aspect ratios as well, since a major reason for that is preventing content reflow from things loading later. We do have ways now, though.
If you’re looking to add lazy loading to your site’s media right now, you’d be smart to include these native lazy loading attributes, but as of this update (July 2019), support in stable browsers in non-existent still. You’ll want to look at doing more:
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
Desktop
| Chrome | Firefox | IE | Edge | Safari |
|---|---|---|---|---|
| 77 | 119 | No | 79 | 16.4 |
Mobile / Tablet
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 115 | 115 | 115 | 16.4 |
I wonder if JavaScript adding loading=”lazy” would be effective, or if it would be too late in the loading process? An extension, or even a Tampermonkey script to set all images and iframes to lazy loading might be nice.
Something else I notice in that description. “An implementation detail of loading in Chrome is that it fetches the first 2KB of images on page-load. It fetches the rest of the image byes when the user is about to see them.” This suggests to me that the browser is going to prevent content reflow by getting the sizes of the images without loading the entire images.
Setting loading=”lazy” by JavaScript can’t work because browsers start loading images right away, the instant they parse the DOM node. The other way, changing loading=”lazy” to loading=”eager” by JavaScript works as expected. And yes, the “pre-flight” range requests which get the first 2 kB are used to determine the image’s dimensions.
There’s already a proposal for a Feature Policy to set all images to loading=”lazy” by default without having to change each img tag.
I wrote a comprehensive article about this which includes code snippets and response timing tables for all requests. You can find it here: https://tiny.pictures/guide/native-lazy-loading
What about background-images? I’m using divs with CSS background-images…
Hey. Using background images as images can be handy sometimes, depending on what you need to do. But you shouldn’t, if your images are content. Because regular images are printable, are accessible, are best for SEO, etc. Read more about lazyloading of responsive images here: https://www.andreaverlicchi.eu/lazy-load-responsive-images-in-2019-srcset-sizes-more/. By the way, the vanilla-lazyload script also allows you to lazy load background images, and use native lazyloaded where supported. Give it a try!
Will this feature work on chromium based browsers aswell?
Well that code failed to show, let’s try this:
<img src="whatever" async>This is great news! I do wonder about carousels or slideshows…WIll the browser be smart enough that it will know that slide image “x” is still 15 slides away when the user is on slide 5…and thus not download the image until it is near the visible window…
Perhaps a fourth possible value for the “loading” attribute of “never” …which would mean “never load” and then you could switch the “loading” attribute to “eager” (via JavaScript) when the slide approached being visible in the carousel…
Either way, a great new feature to add to the native web.
I guess it is too soon for that day …
What if we could have both native lazy-loading and js-based lazyloading with IntersectionObserver with just a few lines of code? Here’s how:
https://www.andreaverlicchi.eu/native-lazy-loading-with-vanilla-lazyload/
I’m struggling to see how this feature will be effective if it has to fetch the first 2KB of all images on page-load, just to determine what images are in viewport. Let’s say I have 20 images stacked on top of each other … The browser will need to make 20 image requests to determine which images are in viewport, and only then will it start loading the full images that are within viewport. That’s 22 server requests even if there are only 2 images in viewport, something which might slow down the response. And it means 40 server requests for 20 images on a page in total, basically doubling the amount requests.
One could include correct intrinsic placeholders for the images in the layout, but then what would be the point of the browser pre-fetching 2KB data from each image in the first place? Waste of requests and bandwidth.
For now, modern JS IntersectionObserver seems more effective, causing much less requests, only for images in viewport.
Did I miss something?
Hey guys, can’t find the answer on the Web.
Maybe I’m being dumb but, now that Chrome v75 is out, is finally native lazy loading supported?