
Chrome to get lazy load below-the-fold images and iframes - rbanffy
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/jxiJvQc-gVg
======
altmind
This feature seems to be involved. In order to layout the html page you need
to know the image sizes(unless they are explicit), and for that you still need
to download the image header, and the headers are of different sizes for
different returned image formats. And some images change when you load them
second time.

So it seems the only way to correctly implement that is to open a connection
to load an image and stall it after receiving the content-type and appropriate
image header and hope that the server will not close the hanging connection(?)

PS: Seems that chrome will download the first 2K if byte-ranges are supported.
If there is no dimensions in the first 2kb or byte-ranges are not supported,
the full image will be downloaded non-lazily
[https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...](https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#)

~~~
gkoberger
There's a link explaining how it's done!

It tries things in this order:

1\. If the full image is present and fresh in the cache, then use that.

2\. Otherwise, if the server supports range requests, and the image dimensions
can be decoded from the first 2KB of the image, then generate and show an
image placeholder with the same dimensions.

3\. Otherwise, fetch the entire full image from the server as usual.

So, it'll only lazy-load images if it's in the cache or certain criteria is
met. Also, it seems like it's opt-in using an attribute, so the implementer of
the website can avoid it if they're worried. But overall, there won't be any
reflow issues.

[https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...](https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#)

~~~
ec109685
Why does it download the 2kb if the image dimensions are specified?

~~~
zamadatix
The doc states 2 reasons:

\- If the image is fits in 2kb (icons/ui elements) then they can just do a
full decode and not have to lazy load these ui items as the page scrolls.

\- It allows them to load low resolution versions of progressive image formats
rather than stick up a generic placeholder (marked as a future improvement
right now).

~~~
ec109685
For your first point, reading the specified dimensions from the page would be
sufficient to tell the browser whether it's a small image to skip lazy
loading.

------
geocar
No need to rely on IntersectionObserver() or even for JavaScript to be enabled
-- Adtech vendors (like Google) can now detect scroll position server-side!

~~~
thug
What? As far as I know this feature is completely client-side.

~~~
thug
I see.. but this would only make a difference for people who disabled JS, and
these people can probably also disable lazy loading.

~~~
zamadatix
Assuming lazy loading remains a flag. Chrome just removed the flag to disable
hyperlink auditing and that one was even blatantly about privacy.

------
bsdetector
Why they say they are pushing this:

* "Speed up the load of above-the-fold content, since there will be less competition for network resources during the initial page load"

Why don't they just set a low priority for offscreen images and resources?
Isn't this the entire premise for HTTP/2, that multiplexing with priorities
and flow control would load the important data first? Do servers not implement
the spec correctly? So this reason is BS as the data saved is immaterial.

* "Reduce memory usage."

Even commodity phones come with several gigabytes of RAM, the memory may have
to be used anyway if the user scrolls, and if you have unlimited scroll or
massive scroll something will need to unload data anyway. So this reason is
marginal at best.

* "Save network data by avoiding downloading any deferred content that the user doesn't end up scrolling to"

Most phone plans are unlimited or have data capable of watching movies. On
Google's own Fi plan "less than 1% of individual Fi users ... use above 15
GB". So this is another BS reason as the data saved is immaterial.

So why are they _actually_ pushing this?

Under "privacy considerations": "so slightly more information about the user's
scrolling position on the embedding page is exposed" and "a deferred cross-
origin image gets an additional piece of information about the user's
scrolling position".

This is not hard to figure out - they are barely even trying to hide it. Same
thing as pushing HTTP/2, which I contend was at least partly to track people
using socket IP:port address (for instance by keeping a single connection to
google-analytics open that all domains' data goes through and boosting the
connection keep alive from a few minutes to like half an hour, which they
did).

~~~
akie
Wow, how can this conspiracy-theory-like nonsense be voted to the top of the
comments? I thought Hacker News was a rational place.

The reality is that lazy loading images really does help webpage performance,
especially on mobile. You cannot properly implement it in the browser without
additional information from the page developer - because you'll never know
which images are so important that they will _always_ need to be loaded, and
which ones can be lazy loaded once they're almost in view.

We're talking about the addition of one attribute to the <img> tag here.
There's no conspiracy, and there's no ulterior motive.

~~~
bsdetector
No we're talking about every website having to make this work because the
default is to not require loading the resources or else be blamed for not
being compliant with a spec forced on them by Google through their browser
monopoly.

Google should need some really good evidence to support this.

What points do you disagree with, and why? Where are the metrics? If it's
better performing than just priorities and flow control then by how much, and
how do you justify breaking sites to achieve that margin?

~~~
chronogram
Then just don’t specify the loading=lazy tag...

~~~
bzbarsky
Doesn't matter. The actual discussion on blink-dev is pretty clear about the
plan being for lack of that attribute to mean "use some heuristics of Google's
choice to decide whether to lazy-load".

------
username223
The downside of this is that it assumes that I am always online, and I can
never know if a page has finished loading. Say I load an article in a
background tab to read later, then go somewhere without WiFi like, say, an
airplane. I read the first page, hit the space bar, and see gray boxes. Now I
need to either scroll all the way through any article I want to read later
(unless "infinite scroll" happens), or save it as a web archive (if that even
still works).

~~~
hn_throwaway_99
Tons of web pages (especially e-commerce sites where initial visible page load
time is critical) already do this, just with more complicated code.

~~~
username223
And mobile browsers randomly purge and reload pages when they're low on
memory, and news sites do lazy image loading with miscellaneous Javascript. It
all sucks, and it's too bad that Google wants to (i.e. will) "make it
official."

~~~
hn_throwaway_99
You think this sucks? So instead of optimizing for the 99% case where I go to
a site and want to see the images on the page as fast as possible and defer
loading what I can't see initially, you instead want to prioritize "Say I load
an article in a background tab to read later, then go somewhere without WiFi
like, say, an airplane."???

Thanks, I'll take Google's solution.

------
alangpierce
I've had the idea of doing a similar thing in application code for XHRs. For
example, if you have a React app and you structure your code so that
components declare their own data dependencies, then you can have a framework-
level solution where you measure component positions on mount and give
priority to data fetching for components above the fold.

I never actually implemented it, though, just seemed like a nice idea. Anyone
know if existing data fetching frameworks (e.g. Apollo Client) can do anything
like that?

------
randyrand
How is this only now getting implemented? I’m very surprised.

Also, do we yet unload images (from memory) after a user scrolls far past
them?

I’m always surprised how slow “long” webpages become.

~~~
acdha
> do we yet unload images (from memory) after a user scrolls far past them?

Last time I looked, the answer was no for images but yes for background
images. I implemented a lazy-loader which did the latter for a pretty
significant measured improvement on gallery pages.

------
bonsai80
The post says "Firefox: No public signals" \- does that mean there is no word
from Firefox if it'll be implemented in Firefox?

~~~
pbasista
There is an open Firefox bug about it:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1535749](https://bugzilla.mozilla.org/show_bug.cgi?id=1535749)

But the last comment raises concerns about privacy implications it may have.
So, I think that right now it is unclear whether Firefox will eventually
implement it and in what form.

~~~
callahad
That's not this. Bug 1535749 is about lazy-loading images on the new tab page,
not about implementing native support for the "loading" attribute on img tags.

------
dmarble

      On Android Chrome with Data Saver turned on, elements with loading="auto" or 
      unset will also be lazily loaded if Chrome determines them to be good 
      candidates for lazy loading (according to heuristics).
    

I don't agree with this design decision to make the default ("or unset...")
allow for lazy loading, even if limited to Data Saver enabled phones. Doesn't
this mean every site on the planet that deems Android >= 7.0 web traffic
important and makes use of pixel-based or iframe-enclosed tracking will have
to go through testing and potential modification?

------
bart3r
How will this affect analytics with tracking pixels, etc?

~~~
jroschen
I think that this could be a boon to pixel tracking. From my understanding, a
site could embed multiple tracking pixels on a page to give a good
approximation of how far the user scrolls and how long it takes them to scroll
down the page, all without JavaScript.

I would be curious if this would also be apply to email clients that render
using Chrome.

------
PaulHoule
So that means the ads load right away and then the content loads later, if at
all?

------
thijsw
Previous discussion
[https://news.ycombinator.com/item?id=19596458](https://news.ycombinator.com/item?id=19596458)

------
tqkxzugoaupvwqr
The new attribute’s value names look poorly chosen. “Lazy” and “eager”. Why
don’t they use existing vocabulary like “deferred“ for lazy, and a new,
equally professional word for eager.

~~~
plorkyeran
"lazy" and "eager" _are_ the pre-existing widely used terms for this.

------
XzetaU8
Firefox is also planning to add support for off-screen image lazy-loading.

[1]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1535749](https://bugzilla.mozilla.org/show_bug.cgi?id=1535749)

~~~
callahad
That's incorrect. See clarification at
[https://news.ycombinator.com/item?id=19604145](https://news.ycombinator.com/item?id=19604145)

