Add Lazy Loading to images and iframes

[RiccardoMasutti]

(Replaced by #340)

Why native lazy-loading?

According to HTTPArchive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send about 4.7 MB of images on desktop and mobile. That's a lot of cat pictures.

Embedded iframes also use a lot of data and can harm page performance. Only loading non-critical, below-the-fold images and iframes when the user is likely to see them improves page load times, minimizes user bandwidth, and reduces memory usage.

SEO Benefits

Google has indicated site speed (and as a result, page speed) is one of the signals used by its algorithm to rank pages. And research has shown that Google might be specifically measuring time to first byte as when it considers page speed. In addition, a slow page speed means that search engines can crawl fewer pages using their allocated crawl budget, and this could negatively affect your indexation.

Page speed is also important to user experience. Pages with a longer load time tend to have higher bounce rates and lower average time on page. Longer load times have also been shown to negatively affect conversions.

Currently, there are two ways to defer the loading of off-screen images and iframes:

• Using the Intersection Observer API
• Using scroll, resize, or orientationchange event handlers

Either option can let developers include lazy-loading functionality, and many developers have built third-party libraries to provide abstractions that are even easier to use. With lazy-loading supported directly by the browser, however, there's no need for an external library. Native lazy loading also ensures that deferred loading of images and iframes still works even if JavaScript is disabled on the client.

Starting with Chrome 76, we are able to use the new loading attribute to lazy-load resources without the need to write custom lazy-loading code or use a separate JavaScript library.

Demo:

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

[m52go]

To be honest, I don't see a difference in the way images are loaded, and browser support isn't great, but I don't see a downside either.

Please double-check that spacing is good throughout...I spotted 1 error.

[RiccardoMasutti]

To be honest, I don't see a difference in the way images are loaded, and browser support isn't great, but I don't see a downside either.

Please double-check that spacing is good throughout...I spotted 1 error.

We delay the loading of images until the point where user really need it. This makes the website load faster, the user saves bandwidth and the overall SEO is improved.
Putting in simple words, on demand object loading rather than loading objects unnecessarily.

[m52go]

Yeah I think I was testing on Firefox, which isn't supported yet. Works on Chromium though.

https://caniuse.com/#feat=loading-lazy-attr

[m52go]

@RiccardoMasutti this is ready...merge conflicts just need to be fixed.

[FKrauss]

https://caniuse.com/#feat=loading-lazy-attr

This does leave out over a third of our website users:

But when it is not supported, what happens? does the page load all the content? If that is the case then we still get the SEO benefit of having faster loading times?

[RiccardoMasutti]

@FKrauss yes, unsupported browsers load images as usual.

It will boost SEO because of Google renders pages with latest Chromium updates

[RiccardoMasutti]

The loading attribute can be treated as a progressive enhancement. Browsers that support it can lazy-load images and iframes. Those that don't yet can load images just like they would today.

In terms of cross-browser support, loading should be supported in Chrome 76 and any Chromium 76-based browsers. There is also an open implementation bug for Firefox.

A similar API was proposed and used in IE and Edge but was focused on lowering the download priorities of resources instead of deferring them entirely. It was discontinued in favour of resource hints.

Btw now Edge ships as Chromium-based so it will add loading feature ;)

[FKrauss]

Cool, so that's a non issue in terms of user impact

…

On Fri, 7 Feb 2020, 18:50 Riccardo Masutti, ***@***.***> wrote: The loading attribute can be treated as a progressive enhancement. Browsers that support it can lazy-load images and iframes. Those that don't yet can load images just like they would today. In terms of cross-browser support, loading should be supported in Chrome 76 and any Chromium 76-based browsers. There is also an open implementation bug for Firefox <https://bugzilla.mozilla.org/show_bug.cgi?id=1542784>. A similar API <https://w3c.github.io/web-performance/specs/ResourcePriorities/Overview.html> was proposed and used in IE and Edge but was focused on lowering the download priorities of resources instead of deferring them entirely. It was discontinued in favour of resource hints <https://w3c.github.io/resource-hints/>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#331?email_source=notifications&email_token=ABEY5S4PDM73KNGWKO5MP7DRBWNOJA5CNFSM4KHJ45J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELD6JJA#issuecomment-583525540>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEY5S6PDP7QRC2LLEZPE7TRBWNOJANCNFSM4KHJ45JQ> .

[RiccardoMasutti]

Cool, so that's a non issue in terms of user impact

Exactly. Let's say it is a long term investment as loading="lazy" is the future and will become a standard

[RiccardoMasutti]

It will make the site faster, more appreciated (by users and Google). 47% of content type are images and 83% of requests are from images.

https://tools.pingdom.com/#5c08661c34000000

Content size by content type:

CONTENT TYPE	PERCENT	SIZE
Image	46.69%	222.2 KB

Requests by content type:

CONTENT TYPE	PERCENT	REQUESTS
Image	83.05%	49

[RiccardoMasutti]

@FKrauss @m52go should be ready to merge

[m52go]

Huh? This PR closed just as I pushed an update 🤔

@RiccardoMasutti can you reopen it? I don't have a button to reopen.

[m52go]

Ah shoot, I screwed it up...force-pushed an empty set of changes (or something) and that automatically closed the PR.

Correction is here. @RiccardoMasutti would you like to make a new PR from that branch? That's ready to merge.

---

FWIW there were over 50 merge conflicts that had to be corrected one by one.

I really need you to take care of this type of stuff in the future...I'm happy to explain it to you, but I can't spend time doing it myself. It's a contributor's job to make their PRs ready to merge—as maintainer, if I can't merge PRs with little/no work, I'm going to have to close them.