
Native lazy loading has landed in Chrome - yeasayer
https://dev.to/yashints/native-lazy-loading-is-landed-in-chrome-2kli
======
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?

~~~
davidweatherall
I imagine anti-lazyloading extensions will start appearing soon.

~~~
mantas
And that's exactly why common API for lazyloading is awesome. It's a PITA to
write such extension when everybody is using custom approaches for
lazyloading. Once there's a common API, there will be a common approach to
override it.

------
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?

~~~
acdha
It's becoming more common as people use aggressive blockers but the main
reason to care about it is that JavaScript breaks fairly regularly. On LTE, I
see pages where a simple HTML display would work but a JavaScript loader
failed on first load generally a couple of times a day.

~~~
toastal
With uMatrix I'm often without the necessary script to load basic static
content. I love JavaScript and PWAs, but many sites aren't an application so I
don't want extra scripts running who knows what.

------
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](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](https://placedog.net/400/400)

~~~
_def
I remade the example with placeholder.com:
[https://codepen.io/_def/pen/MWgpqmq](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.

~~~
mark_and_sweep
I think the previous poster was referring to the unnecessary `=== true` part.

~~~
Raphmedia
It's quite common to compare against "true" using "===" in JavaScript.

~~~
wereHamster
I wouldn't say it's common. Most JavaScript developers (who aren't familiar
with JS coercion rules or the difference between == and ===) wouldn't even be
able to tell you for certain what the code does, exactly.

Using === to compare against "true" makes only sense if the variable can be
something other than boolean (undefined, null, string etc). Or if you are
programming defensively – by choice or because the codebase is messy.

~~~
tobr
The `in` operator always returns a boolean, though.

~~~
reaperducer
Maybe it was just done out of habit.

A bool can be expected today. But why about 10 years from now? Defensive
programming isn't a bad thing. Making assumptions is why we had the Y2K mess.

~~~
mark_and_sweep
That's an unreasonable, excessive use of defensive programming.

We're not talking about an unstable API here, we're talking about an operator.

It would be just as unreasonable to "defend" your code against `1 + 1`
suddenly returning a boolean rather than a number.

~~~
Raphmedia
You already know that ìn` will return either `true` or `false`. Why use `==`
which will convert data instead of `===` which will test for a boolean
directly?

Ignore the symbols and use the words. Which makes more sense to you?

"[My test] strictly equals true." or "[My test] loosely equals true."

------
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!

~~~
zsrxx
about:flags

~~~
rasz
Show me on the doll where Chrome has an option to disable Ping attribute (dont
bother looking for chrome://flags#disable-hyperlink-auditing, its gone), or
set custom localstorage quotas?

------
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...](https://web.dev/native-lazy-loading#how-does-the-loading-attribute-
work-with-images-that-are-in-the-viewport-but-not-immediately-visible-\(for-
example-behind-a-carousel\))

> 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.

