Lazy Loading - Web Performance | MDN

• Skip to main content
• Skip to search
• Skip to select language

1. References
2. Web performance
3. Lazy loading

Article Actions

• English (US)
  • Remember language
  • Deutsch
  • Français
  • 日本語
  • 한국어
  • Русский
  • 中文 (简体)

• Overview
• Strategies
• Specifications
• See also

1. Animation performance and frame rate
2. CSS and JavaScript animation performance
3. Critical rendering path
4. Lazy loading
5. Navigation and resource timings
6. Optimizing startup performance
7. Performance Monitoring: RUM vs. synthetic monitoring
8. Performance budgets
9. Performance fundamentals
10. Populating the page: how browsers work
11. Recommended Web Performance Timings: How long is too long?
12. Speculative loading
13. Understanding latency
14. Using dns-prefetch

• Overview
• Strategies
• Specifications
• See also

Lazy loading is a strategy to identify resources as non-blocking (non-critical) and load these only when needed. It's a way to shorten the length of the critical rendering path, which translates into reduced page load times.

Lazy loading can occur on different moments in the application, but it typically happens on some user interactions such as scrolling and navigation.

Overview

As the web has evolved, we have come to see huge increases in the number and size of assets sent to users. Between 2011 and 2019, the median resource weight increased from ~100KB to ~400KB for desktop and ~50KB to ~350KB for mobile. While Image size has increased from ~250KB to ~900KB on desktop and ~100KB to ~850KB on mobile.

One of the methods we can use to tackle this problem is to shorten the Critical Rendering Path length by lazy loading resources that are not critical for the first render to happen. A practical example would be when you land on the home page of an e-commerce site with a link to a cart page/section, and none of the cart page's resources (such as JavaScript, CSS, and images) are downloaded until you navigate there.

Strategies

Lazy loading can be applied to multiple resources and through multiple strategies.

General

Code splitting

JavaScript, CSS and HTML can be split into smaller chunks. This enables sending the minimal code required to provide value upfront, improving page-load times. The rest can be loaded on demand.

• Entry point splitting: separates code by entry point(s) in the app
• Dynamic splitting: separates code where dynamic import() expressions are used

JavaScript

Script type module

Any script tag with type="module" is treated as a JavaScript module and is deferred by default.

CSS

By default, CSS is treated as a render blocking resource, so the browser won't render any processed content until the CSSOM is constructed. CSS must be thin, delivered as quickly as possible, and the usage media types and queries are advised to unblock rendering.

html<link href="style.css" rel="stylesheet" media="all" /> <link href="portrait.css" rel="stylesheet" media="(orientation:portrait)" /> <link href="print.css" rel="stylesheet" media="print" />

It is possible to perform some CSS optimizations to achieve that.

Fonts

By default, font requests are delayed until the render tree is constructed, which can result in delayed text rendering.

It is possible to override the default behavior and preload web font resources using <link rel="preload">, the CSS font-display descriptor, and the Font Loading API.

See also: Element Link.

Images and iframes

Very often, webpages contain many images that contribute to data-usage and how fast a page can load. Most of those images are off-screen (non-critical), requiring a user interaction, like scrolling, in order to view them.

Loading attribute

The loading attribute on an <img> element, or the loading attribute on an <iframe>, can be used to instruct the browser to defer loading of images/iframes that are off-screen until the user scrolls near them. This allows non-critical resources to load only if needed, potentially speeding up initial page loads and reducing network usage.

html<img loading="lazy" src="image.jpg" alt="..." /> <iframe loading="lazy" src="video-player.html" title="..."></iframe>

The load event fires when the eagerly-loaded content has all been loaded. At that time, it's entirely possible (or even likely) that there may be lazily-loaded images or iframes within the visual viewport that haven't yet loaded.

You can determine if a given image has finished loading by examining the value of its Boolean complete property.

Intersection Observer API

Intersection Observers allow the user to know when an observed element enters or exits the browser's viewport.

Event handlers

When browser compatibility is crucial, there are a few options:

• polyfill intersection observer
• fallback to scroll, resize or orientation change event handlers to determine if a specific element is in viewport

Specifications

Specification
HTML Standard # lazy-loading-attributes

See also

• Render blocking CSS
• Browser-level image lazy loading for the web

Help improve MDN

Was this page helpful to you?YesNoLearn how to contribute.

This page was last modified on Nov 22, 2024 by MDN contributors.

View this page on GitHub • Report a problem with this content