Lazy loading is a technique that delays loading images, videos, iframes, and other resources until they are about to scroll into view, instead of loading everything on the page as soon as it opens. By loading only what the visitor can actually see first, lazy loading reduces the amount of data the browser downloads up front, speeds up the initial page load, and saves bandwidth for visitors who never scroll to the bottom.

Used correctly, lazy loading is one of the simplest and most effective page speed improvements. Used incorrectly, particularly on the main image at the top of a page, it can make a page slower in exactly the metric Google measures most closely.

How lazy loading works

Modern browsers support lazy loading natively. Adding loading="lazy" to an <img> or <iframe> element tells the browser to defer fetching it until it is near the viewport. The browser decides how close is close enough, based on factors such as connection speed, so images usually finish loading just before the visitor scrolls to them.

Before native support was widespread, lazy loading was done with JavaScript: images were given a placeholder and the real address was stored in a data attribute, and a script swapped it in when the image approached the viewport, typically using the Intersection Observer API. JavaScript approaches are still used for special cases, such as background images set in CSS, but native lazy loading is simpler, faster, and does not depend on scripts running.

Since WordPress 5.5, core has added loading="lazy" to images automatically, and later versions refined this to skip the first images on a page, which are likely to be visible immediately.

Why lazy loading improves performance

A long page may contain dozens of images, many of them far below the fold. Without lazy loading, the browser requests all of them at once, competing for bandwidth with the resources the visitor actually needs first: the HTML, the CSS, the fonts, and the images at the top of the screen. Deferring the offscreen images lets those critical resources arrive sooner.

The benefits include faster initial rendering, lower total data transfer (important for visitors on mobile data), less work for the browser during load, and reduced server and CDN bandwidth. The gains are largest on image-heavy pages: portfolios, galleries, long articles, product listings, and pages with embedded videos or maps.

The biggest mistake: lazy loading the hero image

The most important rule of lazy loading is never lazy load images that are visible when the page first loads, especially the largest one. On most pages, the hero image or main photo at the top is the element Google uses to measure Largest Contentful Paint (LCP). If that image is lazy loaded, the browser waits until it has laid out the page and determined the image is in view before it even starts downloading it, which can add significant delay to LCP.

For above-the-fold images, the opposite approach is correct: load them eagerly (the default, or loading="eager"), and for the LCP image specifically, consider adding fetchpriority="high" and preloading it so the browser requests it as early as possible. Getting this one detail right is often worth more than every other image optimization combined.

This mistake is common because lazy loading is frequently applied globally, by a plugin, a theme setting, or a page builder, without regard to where images appear. Audit the templates that matter most, especially the homepage and key service or product pages, and confirm the first visible images are not lazy loaded.

Lazy loading and layout shift

Lazy-loaded images that do not have their dimensions specified can cause Cumulative Layout Shift (CLS): when the image finally loads, it pushes the content below it down the page. The fix is to include width and height attributes (or a CSS aspect ratio) on every image so the browser reserves the right amount of space before the image arrives. This applies to all images, but it matters most for lazy-loaded ones, because they load while the visitor is already reading.

What else can be lazy loaded

Iframes and embeds. Embedded YouTube videos, maps, and social posts are often much heavier than images, loading scripts and resources from third parties. Lazy loading them, or replacing them with a lightweight preview image that loads the real embed only when clicked (a facade), can dramatically reduce page weight.

Background images. CSS background images cannot use the native attribute, but can be deferred with a small script or by applying the background class only when the section approaches the viewport.

Below-the-fold components. Chat widgets, review carousels, and other interactive sections can be loaded after the main content, or on first interaction, to reduce the JavaScript that runs during page load and improve Interaction to Next Paint.

Scripts. Related techniques such as deferring non-critical JavaScript follow the same principle: load what the visitor needs first, and the rest when it is needed.

Native vs. JavaScript lazy loading

For most sites, native lazy loading is the right default. It needs no script, works even when JavaScript fails or is blocked, keeps the real image address in the HTML where every crawler can see it, and lets the browser tune loading thresholds to the visitor’s connection. JavaScript libraries still have a place: they can lazy load CSS background images, apply custom thresholds, fade images in, or load components on interaction rather than on scroll. The trade-off is that they add code the browser must download and run, and poorly written implementations can hide content from crawlers or delay images longer than necessary. If a site uses a JavaScript lazy loader, check that images still have a real src or a noscript fallback, and that the loader is not also applied to the hero image.

Lazy loading and SEO

Google can see natively lazy-loaded images, because its crawler renders pages with a tall virtual viewport and the loading attribute does not hide the image address. Problems arise with some older JavaScript implementations that keep the real image address out of the HTML until a scroll event happens. Crawlers that do not scroll, or do not run JavaScript at all, may never see those images. Many AI crawlers fall into the second group. Native lazy loading, with the real address in the src attribute, avoids the problem.

Images that matter for search, such as product photos and infographics, should also have descriptive alt text and appear in the HTML regardless of how they are loaded.

How to check lazy loading on your site

PageSpeed Insights and Lighthouse flag offscreen images that should be deferred and warn when the LCP image was lazy loaded.

Chrome DevTools shows, in the Network panel, which images load immediately and which load on scroll, and the Performance panel identifies the LCP element.

Viewing the page source confirms which images carry loading="lazy" and whether real image addresses are present.

Lazy loading on WordPress

WordPress core handles basic image lazy loading automatically and tries to exclude the first images on each page. Performance plugins add options for iframes, videos, and background images. The risk is overlap: a theme, a page builder, and one or two plugins may each apply their own lazy loading, sometimes including the hero image, sometimes conflicting with each other. The cleanest setup uses native lazy loading, explicit image dimensions, eager loading and high fetch priority for the LCP image, and facades for heavy embeds, implemented in the theme rather than layered on with plugins. Lazy loading also works alongside caching and minification; none of them replaces properly sized, compressed images in modern formats such as WebP or AVIF.

Getting it right

We implement lazy loading carefully, never on above-the-fold images, as part of our page speed optimization services, and verify the effect in field data rather than lab scores alone. For more on how load speed affects AI systems as well as search, see why AI and LLMs prefer fast websites. If your pages feel slow despite a caching plugin, book a discovery call.