Deferred Loading

Of course, this function is not very useful. We moved from native loading of images to JS-based loading, but we’re still loading all the images! To improve on that, let’s improve the logic to only load images that are “above the fold” (see Example 8-3).

// Test if an image is positioned inside the initial viewport
function isAboveTheFold(img) {
    var elemOffset = function(elem) {
        var offset = elem.offsetTop;
        while (elem = elem.offsetParent) {
            offset += elem.offsetTop;
        }
        return offset;
    };
    var viewportHeight = window.innerHeight || document.documentElement.clientHeight;
    var imgOffset = elemOffset(img);
    return ((imgOffset >= 0) && (imgOffset <= viewportHeight));
}

// Load either all or only "above the fold" images
function loadImages(policy) {
	// Iterate all image elements on the page
    var images = document.querySelectorAll("img");
    for (var i = 0; i < images.length; ++i) {
        var img = images[i];
		// Skip below the fold images unless we're loading all
		if (!policy.loadAll && !isAboveTheFold(img))
			continue;
		// Copy the data-src attribute to the src attribute
		if (!img.src && img.getAttribute("data-src"))
			img.src = img.getAttribute("data-src");
	}
}

// Load above the fold images
loadImages({loadAll: false});

// At the load event, load all images
window.addEventListener("load",function() {
    loadImages({loadAll: true});
});

Let’s review the additional code changes we’ve made:

1. We added the isAboveTheFold function to test if an image is above the fold.

2. We wrapped the image loading in the loadImages function, and added an option to load images only if they’re above the fold.

3. We use loadImages to load images above the fold immediately.

4. At onload, we load all images.

The first three steps create the prioritization we’re looking for, only loading above the fold images, and keeping lower images from interfering. Once the page is loaded, the last step triggers and loads the remaining images for those users who do scroll down. Such loading is called deferred loading, and is a good way to accelerate the more important content.

Lazy Loading/Images On Demand

While deferred loading accelerates pages, it doesn’t prevent waste. As we mentioned before, many users don’t scroll all the way (or at all), and thus many of the images are never seen. Loading those images later would still not avoid the wasted bandwidth and battery drainage they incur.

To avoid this waste, we need to change our image loading to be “on demand,” only loading an image when it comes into view. This technique is often called lazy loading, as we only do “the work” (downloading the image) when we absolutely must. Other common names are images on demand or just-in-time images.

Pure lazy loading will start the image download only when the image comes into view. However, doing so is likely to impact the user experience, as the user will be looking at a blank space while the image is actually downloaded and rendered. To mitigate that, we can try to anticipate user actions and download the image ahead of time. For instance, we can load images that are fewer than 200 pixels below the current visible area, trying to stay ahead of slow user scrolling. A more aggressive prefetch can improve the user experience, but will also increase the amount of wasted downloads.

In code, lazy loading requires listening to a variety of events that may change the content in view, such as scrolling, resizing, changing orientation, and more. It may also need to track application actions that impact what’s in view—for instance, collapsing a page section. Each time an event fires, we need to re-examine all undisplayed images and choose which ones to load.

Lazy loading is a fairly simple concept, but it’s hard to do it well. It’s easy to miss a change in the visual area, as there are many events to listen on, and browsers implement them in subtly different ways. Even when you capture a change event, traversing all images to determine which is now visible is hard to do efficiently, especially when it may be called many times in sequence.

When considering lazy loading, first confirm whether deferred loading would satisfy your needs. It’s much easier to implement, and is less error prone. If you still want to do lazy loading, it’s recommended that you use an existing JavaScript library. A prominent example is the lazySizes library, which lazy-loads images while playing well with the various responsive images solutions (more on that in Chapter 11). There are also automated services that can help you get lazy loading working in an optimal way with minimal effort.

If you still insist on implementing it yourself, remember to err in favor of loading the image—for instance, loading any image whose location you can’t easily determine—and consider a background “cleanup” loop that will confirm you haven’t missed any images every second or so.

IntersectionObserver

Traditionally, lazy loading libraries relied on the browser’s scroll events to know when the user scrolled the page, and concluded from that when certain images would enter the viewport and therefore should be loaded.

However, scroll events handling is very easy to get wrong, resulting in janky scrolling, which frustrates users. The fact that many different libraries on the page were registering scroll events in order to figure out element visibility (resulting in abysmal scroll performance) prompted browsers to think about creating dedicated, highly performant primitives for that purpose.

The result of that effort is the IntersectionObserver API, which permits you to “observe” the intersection of a certain element with another element or with the viewport, and get dedicated callbacks when an element is about to enter the viewport.

You can also define custom distances for “intersections,” which permits you to tell the browser things like “let me know when this element is 75% viewport height away from the current viewport.”

As of this writing, the API is only shipped in Chrome, but as more browsers adopt it, lazy loading libraries are bound to move to this dedicated, jank-free API.

The Preloader and Images

As we mentioned in the previous chapter, browsers use the preloader to accelerate pages. The preloader parses the page ahead of the DOM builder, primarily to identify and start downloading external resources.

Not surprisingly, many of the resources the preloader finds are images. While it depends on their prioritization logic, browsers will often start downloading these images while still busy downloading and processing JS and CSS files. Even images that are not immediately fetched may be accelerated through early DNS resolution of their hostnames, pre-establishing TCP connections to those hosts, and more.

When we use JavaScript to load our images, we effectively disable the preloader. Our JS code, regardless if it’s written as an onload event or a loop, will not run until the DOM builder has actually reached the element we’re handling. As a result, JS-created image tags are likely to start downloading later than native ones.

While this delay is important to consider, it’s not easy to define just how impactful it will be. Different browsers implement different prioritization schemes, and many will delay image downloads until JS and CSS files have been processed anyway. As a result, an image may be delayed due to prioritization just as much as due to being hidden from the preloader, making this whole conversation moot.

To help visualize this, let’s look at the waterfall chart of two simple pages, created using Steve Souders’s Cuzillion. Both pages hold one JavaScript file and two images, but in Page 1 the images are loaded natively (an <img> tag), while in Page 2 they are loaded using JavaScript. To better visualize the effect in the waterfall charts, subresources take 2 seconds to respond. Let’s first look at the loading of the two pages in IE 11, shown in Figures 8-2 and 8-3.

Figure 8-2. Page 1 (native images) in IE

Figure 8-3. Page 2 (JS images) in IE

As is plain to see, the images created using JavaScript start their download only after the external script completed its download, dramatically delaying its rendering and also delaying the entire page load. In this case, the delay in loading images using JavaScript is very clear.

Now let’s look at the two pages on Firefox (Figures 8-4 and 8-5).

Figure 8-4. Page 1 (Native images) on Firefox

Figure 8-5. Page 2 (JS images) on Firefox

While the pages are the same as before, in this case there is practically no difference in the load time or order between the JS and native image loading. This is due to Firefox’s prioritization logic, which defers all image downloads until all JS and CSS files are fully processed.

Lastly, let’s take a look at how Chrome handles this page (Figures 8-6 and 8-7).

Figure 8-6. Page 1 (native images) on Chrome

Figure 8-7. Page 2 (JS images) on Chrome

Chrome uses a more nuanced logic, wherein only one connection is allowed to download images as long as there are still JS and CSS files to fetch. As a result, the first image on this page is downloaded alongside the JS file, but the second image has to wait, resulting in slightly improved visuals but a similar total page load time.

While this is a simple page, the same behaviors take place when loading a real-world website. The key lessons we can learn are:

• The preloader makes page loads faster, and hiding images from it (by loading them with JavaScript) can delay image downloads and slow pages down. This is most clearly shown in the IE 11 example.

• Image downloads are often delayed due to prioritization anyway, reducing the impact of hiding images from the preloader. This was most clearly shown in the Firefox example.

• Browsers handle image download prioritization very differently, at least in HTTP/1.1. The only way to really know how browsers would do is to test your page with performance tools. As Paul Lewis often says, “Tools, Not Rules”.

Browsers Without JS

Loading images with JavaScript requires, obviously, a browser that supports JavaScript. Browsers without JS support, or ones where JS has been disabled, will clearly not run and thus not load these images.

It’s hard to know exactly what portion of users fall into this group. A 2010 study by Yahoo indicates 1.3% of users used browsers without JS support or with JS turned off. The study was repeated in 2013 by the GOV.UK team, which found that only 0.2% of visitors actively disabled JS, while 0.9% of visitors had enabled JS, but the script did not run nevertheless. A 2014 study by WebAIM showed only 2.4% of screen reader users had JS turned off (mostly on Firefox, presumably using the noscript extension, or another script blocking extension).

The exact stats vary greatly by the specific audience your site caters to. To find your own number, you can repeat the Yahoo study on your own site or find that number in a different way—for instance, using Simo Ahava’s guide for using Google Analytics for this purpose. If you deem the audience big enough to care, you can still partially support them using the <noscript> element.

As you may know, the <noscript> tag holds content that will only be processed by the browser if JavaScript is disabled. We can therefore reference the image a second time inside a <noscript> tag, this time using a simple <img> tag. Example 8-5 does just that.

<img src="1px.gif" data-src="book.jpg" alt="A Book"
     onload="loadImage(this)">
<noscript><img src="book.jpg" alt="A Book"></noscript>

Using <noscript> is simple and has no real downsides, except for the repetition in your HTML (and maintanance costs that may come with it). Since the increase in payload size is likely minor (after compression), and since most web pages are generated using templates or code anyway (making it easy to add the <noscript> portion), I would recommend doing so.

Unfortunately, the <noscript> mitigation does not work for users that have their JavaScript support enabled, but for some reason (corporate/government firewalls, antivirus software, poor network, etc.) the scripts never fully download and run. This scenario cannot currently be fully addressed. Hopefully in the future there will be a standard way to define a fallback that can address this use case.

Low-Quality Image Placeholders

As you learned in Part I of the book, certain image files, most notably JPEG and WebP, can be made substantially smaller if we reduce their quality rating. Since such compression drops the least significant visuals first, the savings in file size is not linear to the loss in quality, and you can often cut file sizes by half while slightly degrading visual quality.

If we get even more aggressive, we can often cut our image payload by a factor of 4 or more, while suffering only a 20% visual degradation. Such degradation will be noticed by most users, but it should still be clear what the image shows (see Figures 8-8 through 8-11).

Figure 8-8. JPEG quality 90, file size 66 KB

Figure 8-9. JPEG quality 75, file size 37 KB

Figure 8-10. JPEG quality 40, file size 21 KB

Figure 8-11. JPEG quality 25, file size 16 KB

If we make our images that small, the performance impact of downloading “below the fold” images without seeing them won’t be as big. In fact, it may be small enough that we’d prefer to use native image loading and the preloader benefits it carries. Once those low-quality images are loaded, we can use JavaScript to swap some of them with the original high-quality images.

This approach is called low-quality image placeholders (LQIP), as the low-quality images are only seen as placeholders. It consistently makes the page usable faster, and minimizes the need for lazy loading for all but the longest pages (where the number of images below the fold is especially high).

Implementing LQIP is very similar to the implementation of lazy loading, except the 1-pixel placeholders are replaced with the low-quality image variant. In addition, since we don’t want the high-resolution images to interfere with the download of other page assets, we delay their download until after the page is loaded (we can also choose to lazy-load them instead). Example 8-6 shows an LQIP implementation.

<script>
// Load a placeholder image
function loadImage(img) {
// Copy the data-src attribute to the src attribute
	var dataSrc = img.getAttribute("data-src");
	if (dataSrc)
		img.src = dataSrc;
}

// Keep a registry of all image elements that need loading
var placeholderImages = [];
function registerPlaceholder(img) {
// Remove the onload handler, so it won't be called again
	img.onload = null;

	if (isAboveTheFold(img)) {
// If the image is above the fold, load it right away
		loadImage(img);
	} else {
// Register below-the-fold placeholders for deferred loading
		placeholderImages.push(img);
	}
}

// Replace all placeholder images
function replacePlaceholders() {
// Load all placeholder images (can be replaced with lazy loading)
	for (var ph in placeholderImages) {
		loadImage(ph);
	}
	placeholderImages.length = 0;
}

// At the load event, replace placeholders with real images
window.addEventListener("load",replacePlaceholders);
</script>
<img src="book-low-res.jpg" data-src="book-high-res.jpg" alt="A Book"
	 onload="registerPlaceholder(this)">

Note that LQIP is a tradeoff, as it does include showing users a low-quality image at first. On a fast connection, the high-resolution image will quickly take its place. On a slow connection, the low-quality visual may linger, but at least the page will be usable quickly. In my opinion, it’s a good way to get both speed, gained by the low-quality images, and eventual visual perfection.

Critical Images

As you’ve probably noticed, lazy loading is mostly a means to give visible images priority over ones outside the current viewport. The techniques we’ve described so far were all client-side techniques, which helps make them work well across different pages and viewport sizes. However, we can also try to guess what will be visible on the server side, and tune the page accordingly.

Guessing which images will be visible can be done in two ways: logical and technical. The logical path leverages your knowledge of the application. Does your application have a big “hero image” at the top of the page? Does a product image always show up on the top-left side? Is your logo always in the top-right corner? In many cases, we can (relatively easily) use the design guidelines to guess rather accurately which images will initially be in view.

The technical path implies loading the page in a browser, and seeing which images are within view. The most direct way to do so is using a headless browser, such as PhantomJS, in which we can load the page and see which images are loaded. The generic nature of this path allows it to run on any type of page, but doing it well requires a fair bit of R&D investment. It also assumes the page’s layout is pretty straightforward, and content images are displayed in their HTML order (which is usually the case).

My advice would be not to try to implement the technical path yourself, but instead rely on existing commercial or (future) open-source solutions that would do that for you.

When we estimate an image will be immediately visible, we can change the HTML to load it using a simple (and fast) native tag, while loading the others with JS. The native images will load quickly, thanks to the preloader and the lower-bandwidth contention, while the remaining images will be loaded only if/when they’re needed.

Note that while we’re affecting image download priority, we’re not impacting functionality. If we thought an image was visible and it wasn’t, we simply downloaded it prematurely. If we incorrectly thought it was hidden, it’ll still be loaded with JS shortly after. As a result, don’t try to get it perfectly right from day one. Start by prioritizing (natively loading) the obviously important images (e.g., hero images, product images), and gradually tune over time.