Native lazy loading has landed in Chrome

[sharpercoder]

As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).

[cameronbrown]

Hmm, maybe if websites don't use lazy loading JavaScript anymore (guilty as charged btw) then you'll be able to configure it however you want in browser settings?

[bgdnyxbjx]

Lazy loading doesn’t have to mean waiting for user input to load a resource, or waiting for the viewport. It just gives the developer a way to break up their bundles and control over when they get loaded a fetched.

A well designed web app would have a small start up bundle so the user can get something useful quickly, and then it would start prefetching and loading the rest of the bundles.

[city41]

The article contradicts itself a little bit. It says "Currently the images are fetched with different priority in Chrome, the ones which are not in the viewport have less priority. But they're fetched as soon as possible regardless."

But it also says: "lazy: Defer loading of resources until it reaches a calculated distance from viewport."

If a lazy image is only loaded when within a distance of the viewport, then your "come back later" strategy stops working. But if instead off screen images are just bumped down in priority and still download after higher priority stuff finishes, then your strategy should still work.

[tgv]

> As a user, ... I like to ... and expect ...

Sorry, but the format made me laugh.

[toastal]

I'm happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn't account for this accessibility.

[holtalanm]

just curious -- in what situation would your average user not have javascript turned on?

[tyingq]

One watch out is that the lazy loading only grabs the first 2048 bytes. That gives you the dimensions of an image, which is a plus, but not the whole image, unless the image is tiny. That likely means more total connections. Probably fine for http/2 sites, maybe not so for non-http/2 sites. Would be interesting to see perf stats for that case.

[kaycebasques]

For anyone hearing about loading=“lazy” for the first time from this article , I’ll reiterate the main idea because the article doesn’t go into much depth about the motivation.

The main idea is that some pages use a lot of cellular data to load images that are further down the page, out of the viewport. If the user glances at the page and decides it’s not relevant and exits, then those offscreen images were just a waste of cellular data. loading=“lazy” addresses this problem by deferring the image loads until the user has scrolled the page and the image is soon to be in the viewport.

Disclosure: I write the Chrome DevTools docs

[d--b]

The demo on the page clearly shows a delay between the start of the load and the actual display of the image. So "soon to be in the viewport" should be quite sooner.

[Volundr]

I may be the odd one out here, but I hate lazy loading. I get why it's a big thing on cellular connections, but I do most of my browsing on WIFI. With lazy loading I'll frequently be reading an article, reach an image that hasn't loaded in yet, and have to wait for it, even though I've been reading for several minutes. Sometimes I also have to refind my place as the whole darn page reflows.

I wish there was a middle ground... detect I'm on WIFI and go ahead and load in the lazy stuff after the above the fold stuff.

[5-]

Link could be replaced with the original from which all content was plagiarised?

https://web.dev/native-lazy-loading

[outside1234]

Edge will pick this up going forward as it is based on Chromium.

[holtalanm]

been using the beta version for the last week or so. pretty solid, imo.

[tsp]

Seems like the image service the author is using is down because of traffic…

https://placedog.net/400/400

[_def]

I remade the example with placeholder.com: https://codepen.io/_def/pen/MWgpqmq

[wereHamster]

`if ('loading' in HTMLImageElement.prototype === true) {`

/rolleyes

[danShumway]

I'm missing why this is a bad thing?

It make polyfills way easier, and makes it drop-dead simple to programmatically toggle lazy-loading on existing elements.

[Dutchie2020]

Nice, native deferred rendering for style sheets next please!

[zsrxx]

Good. I hate lazy loading. I hope they add an option in the browser so I can disable it globally.

[josteink]

Chrome? Google Chrome and options?

Hah! Good one!

[milad_nazari]

English isn't my first language but shouldn't it be "... has landed in Chrome" instead of "... is landed in Chrome"?

[garblegarble]

Yes, you're correct - they should be using "has"

[d--b]

This is a poorly thought feature.

You always want to have the image loaded before you actually use it. You don't want to wait until you actually use the image. For instance in a carousel, you'll want to load the next and previous image, not just the current displayed one.

I'd much rather have a "loading order" than lazy loading. Sure, I don't want to load first the big images that I'll want to display later, but I definitely don't want them to appear while I scroll down...

[acdha]

This is covered in the part about the “calculated distance” where they describe the logic used to load the images in the current implementation: it loads before use but waits until the images are near the viewport.

There's an FAQ about carousels, too:

https://web.dev/native-lazy-loading#how-does-the-loading-att...

> How does the loading attribute work with images that are in the viewport but not immediately visible (for example, behind a carousel)? > > Only images that are below the device viewport by the calculated distance load lazily. All images above the viewport, regardless of whether they're immediately visible, load normally.