MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/MDN-Learn-Section-Survey

Lazy loading

Draft
This page is not complete.

Lazy loading is a stretegic delay of loading some assets until they are needed, usually based on user activity or navigation. When navigating to a webpage, it is not always necessary to load every asset, such as scripts, image, etc. on initial load, if the assets are not required immediately. Some assets downloads can be strategically deferred, or lazy loaded,  based on user activity and navigation. If correctly implemented, this delay in asset loading is seamless to the user experience. It might help improve your initial load performance, including time to interactive, because fewer assets, fewer HTTP requests, fewer bytes of data, and less memory consumption, are required for your page to become interactive and useful to the user.

Overview

As the web has evolved, we have come to see huge increases in the number and size of assets sent to users.

The sum of transfer size kilobytes of all external scripts requested by the page. An external script is identified as a resource with the js or json file extensions or a MIME type containing script or json.

The median size of the script files sent to the browser has increased from ~100KB to ~400KB for desktop websites and from ~50KB to ~350KB for mobile websites.

The sum of transfer size kilobytes of all external scripts requested by the page. An external script is identified as a resource with the js or json file extensions or a MIME type containing script or json.

The total size of image assets sent to the browser has increased from ~250KB to ~900KB for the median desktop website and from ~100KB to ~850KB for the median mobile website in that same timeframe.

These numbers demonstrate that the number and size of assets sent to users has increased exponentially; the median website weight (or size) has more than quadrupled.  Websites need to be interactive and visually delightful for better user experience, but JavaScript-based interactivity and image-based designs have a cost in terms of performance, and performance is an important part of user experience. We need to find the right balance for these user experience requirements. 

One of the methods we can use to tackle this problem is to make the initial load smaller and load the larger resources strategically, when they are required (on user interaction or navigation within the website), after the site is interactive and responsive to user input.  To reduce initial load, large script bundles and images can be divided by feature, with only features required at first interactive being downloaded initially, with additional feature assets loaded when required. While the final download size may end up being the same (or even a tiny bit larger), if assets aren't required, the download size will be smaller; even if they are required, the initial load will feel and be faster.

Strategies

Lazy loading can be implemented through multiple strategies, that can be implemented through either "dynamic import()" or controlling resource delivery with resource hints.

Lazy-loading JavaScript with import()

The term "lazy loading" often refers to load deferment techniques for assets not needed at load, such as loading below-the-fold imagery only when those images scroll into view. In this guide, we'll talk about the dynamic import() statement, a newer browser feature, that loads a JavaScript module on demand.

Controlling resource delivery with resource hints

Browsers often know better than we do when it comes to resource prioritization and delivery—but they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.

 

Document Tags and Contributors

Contributors to this page: mojosam, estelle, garyvh2
Last updated by: mojosam,