Web Platform

A native lazy load for the Web platform

Published on

A new Chrome feature dubbed “Blink LazyLoad” is designed to dramatically improve performance by deferring the load of below-the-fold images and third party iFrames.

The goals of this bold experiment are to improve the overall render speed of content that appears within the users viewport (also known as above-the-fold), as well as, reduce network data and memory usage. ✨

👨‍🏫 How will it work?

It’s thought that temporarily delaying less important content will drastically improve overall perceived performance.

If this proposal is successful, automatic optimisations will be run during the load phase of a page:

  • Images and iFrames will be analysed to gauge importance.
  • If they’re seen to be non-essential, they will be deferred, or not loaded at all:

    • Deferred items will only be loaded if the user has scrolled to the area nearby.
    • A blank placeholder image will be used until an image is fetched.

The public proposal has a few interesting details:

  • LazyLoad is made up of two different mechanisms; LazyImages and LazyFrames.
  • Deferred Images and iFrames will be loaded when a user has scrolled within a given number of pixels. The number of pixels will vary based on three factors:

  • Once the browser has established that an image is located below the fold, it will issue a range request to fetch the first few bytes of an image to establish its dimensions. The dimensions will then be used to create a placeholder.

The loading attribute will allow authors to specify which elements should, or should not be lazy loaded. Here’s an example that indicates that this content is non-essential:

<iframe src="ads.html" loading="lazy"></iframe>

There are three options:

  • lazy - Indicates a strong preference to defer fetching until the content can be viewed.
  • eager - Fetch this resource immediately, regardless of view-ability.
  • auto - Let the browser decide (has the same effect as not using the loading attribute at all).

Implementing a secure LazyLoad policy

Feature policies exist to allow authors and site owners to be able to control how given web platform features can be used.

For example, if you wanted to disable lazy-loading site-wide, you could do so with a HTTP header:

Feature-Policy: loading-frame-default-eager 'none'

Feature policy for lazy-load is still being developed and has not yet been fully resolved. If you’d like to follow along check this Github pull request, or the lazy-load feature policy page.

🤔 What about backwards compatibility?

At this point, it is difficult to tell if these page optimisations could cause compatibility issues for existing sites.

Third party iFrames are used for a large number of purposes like ads, analytics or authentication. Delaying, or not loading a crucial iFrame (because the user never scrolls that far) could have dramatic unforeseeable effects.

Pages that rely on an image or iFrame having been loaded and present when onLoad fires could also face significant issues.

These automatic optimisations could silently and efficiently speed up Chrome’s rendering speed without any notable issues for users. The Google team behind the proposal are carefully measuring the performance characteristics of LazyLoad’s effects through metrics that Chrome records.

Detecting support for lazy-load

If you’d like to detect support for lazy-load, start with this snippet:

if ('loading' in HTMLImageElement.prototype) {
  // Browser supports `loading`..
} else {
  // Fetch and apply a polyfill/JavaScript library
  // for lazy-loading instead.
}

💻 Enabling lazy-load

LazyLoad will be enabled in Chrome 75+. For older versions of Chrome, it’s hidden behind two flags:

  1. chrome://flags/#enable-lazy-image-loading
  2. chrome://flags/#enable-lazy-frame-loading

Flags can be enabled by navigating to chrome://flags in a Chome browser.

📚 References and materials

👋 In closing

As we embark on welcoming the next billion users to the web, it’s humbling to know that we are only just getting started in understanding the complexity of browsers, connectivity and user-experience. Be sure to subscribe to see more posts like this.

Performance Newsletter
Performance Newsletter
Web performance tools, talks and resources delivered to your inbox.
Subscribe