What is Lazy Loading?

I had a great opportunity to attend Google I/O 2019. While there weren't any groundbreaking web technology sessions, some web-related technologies introduced in certain sessions were interesting. Native Lazy Loading, Portals, Duplex, and Rich Results caught my attention. Among them, native lazy loading, mentioned extensively from the keynote to several sessions, was the one I looked forward to the most.

Lazy loading, especially image lazy loading, isn't a new technique[11]. Traditionally, when loading a webpage, browsers download all images within the entire page area simultaneously from the start[9]. Service users might navigate away before seeing all the images on a webpage, yet browsers wastefully download all images beforehand. Image lazy loading prevents downloading all images during the initial page load[14]. Initially, only images visible in the browser's viewport are downloaded. The remaining images are downloaded when needed or likely needed, determined using heuristics[2]. In other words, images are selectively downloaded based on user scrolling and other environmental factors.

Applying lazy loading not only reduces unnecessary network costs but also benefits performance, memory usage, and usability[12]. Previously, lazy loading was implemented directly with JavaScript or by using libraries[9]. With native browser support for lazy loading, the browser internally decides when to download images. This suggests access to more information than JavaScript and the use of more sophisticated heuristics[2]. Conversely, options to intervene in this decision-making process are unlikely to be provided. Chrome plans to natively support lazy loading for iframe and img elements starting from version 75[2][8].

The New loading Attribute

According to the official lazy load design document, lazy loading can be configured using a new loading attribute added to <img> and <iframe> elements[10].

<img src="cat.jpg" loading="lazy" />
<iframe src="some.html" loading="lazy"></iframe>

Setting the loading attribute to lazy makes the corresponding image or iframe lazy-loaded[3][4].

<img src="cat.jpg" loading="eager" />
<iframe src="some.html" loading="eager"></iframe>

The eager value intentionally opts out of lazy loading, behaving like traditional browsers by downloading the image during page load[3][4]. In some situations, lazy loading might not be necessary. If lazy loading interferes with service usability, set the eager option.

<img src="cat.jpg" loading="auto" />
<img src="cat.jpg" />

auto is the default value for the loading attribute, applied if the attribute is not specified[10]. It lets the browser decide whether to lazy load or not[9].

Chrome has long been the most used browser globally, and in Korea, it currently holds over 53% usage share.

Considering this 53% user base, preliminary testing is necessary. Services particularly sensitive to images should definitely test usability before the feature is included in the stable release and prepare appropriate responses. While it's expected to be non-problematic in most cases, the auto default could potentially cause unintended usability issues[9]. For services not yet ready to consider lazy loading, it might be necessary to explicitly apply loading="eager" to each image to maintain the existing behavior. Of course, auto might pose no problems at all.

Feature Detection and Fallback

Looking at the LazyLoad Explainer document reveals how to detect browsers supporting lazy loading. Similar to other feature detection methods, it checks if the loading property exists on the prototype of the HTMLImageElement interface.

if ('loading' in HTMLImageElement.prototype) alert("Native lazy loading supported"); else alert("Not supported");

While the loading attribute is simple to use and unlikely to negatively impact services significantly, using native lazy loading in Chrome and ignoring it in other browsers can still be effective. However, if you want to provide lazy loading across all browsers, consider using other libraries as a fallback (or build your own).

Google I/O's "Speed at Scale" session shared example code using the lazysizes library as a fallback. The image code was hard to read, so I copied the equivalent code from Addy Osmani's blog.

<!-- Let's load this in-viewport image normally -->
<img src="hero.jpg" alt=".."/>

<!-- Let's lazy-load the rest of these images -->
<img data-src="unicorn.jpg" loading="lazy" alt=".." class="lazyload"/>
<img data-src="cats.jpg" loading="lazy" alt=".." class="lazyload"/>
<img data-src="dogs.jpg" loading="lazy" alt=".." class="lazyload"/>

<script>
  if ('loading' in HTMLImageElement.prototype) {
    const images = document.querySelectorAll("img.lazyload");
    images.forEach(img => {
      img.src = img.dataset.src;
    });
  } else {
    // Dynamically load the LazySizes library
    let script = document.createElement("script");
    script.async = true;
    script.src = "https://cdnjs.cloudflare.com/ajax/libs/lazysizes/4.1.8/lazysizes.min.js";
    document.body.appendChild(script);
  }
</script>

Although I haven't used libraries like lazysizes, image lazy loading implementations tend to be similar, so I can guess how it works. Initially, all <img> elements display placeholder images. The images from the data-src paths are downloaded under appropriate conditions, and once completed, the src of the image element is updated. The fallback example initially sets up the code for lazysizes. Then, using feature detection, if native lazy loading is available, it modifies the elements by replacing data-src (needed by lazysizes) with src to utilize native lazy loading.

Summary

After returning home, I tested it in Chrome Canary following the instructions at the bottom of Addy Osmani's blog. Feature detection worked, and I could even check the loading property value on the Image object. However, lazy loading didn't function correctly; all images were downloaded from the initial page load. Since the feature is still under development, I expect it to work correctly in the stable release or a future Canary version. The Canary version I tested was 76.0.3799.0.

There are rumors that Webkit engine developers are positively reviewing native lazy loading, and Firefox is scheduled to implement the same specification as Chrome soon, according to a ZDNET article[1][8][13]. Since Microsoft's Edge is also being developed based on Chromium, it seems specs initiated by Chrome are naturally becoming standards[5]. While it's a good feature and certainly worthy of consideration as a standard spec, it reminded me of an article I read last year titled "Chrome is turning into the new Internet Explorer 6". Whatever the case, I hope many good specs are developed, further expanding the possibilities of the web and, consequently, my own job prospects.