The performance effects of too much lazy loading

Lazy loading: when a performance cure becomes the problem

Browser-level image lazy loading via loading="lazy" has been a web standard since 2019 and is now supported by most major browsers. The technique is straightforward: defer downloading a resource until it's needed, cutting unneeded bytes and reducing network contention for critical assets. But an analysis of web transparency data and A/B testing by the Chrome team suggests that overuse of lazy loading—specifically applying it to images in the initial viewport—can hurt real-user performance metrics like Largest Contentful Paint (LCP).

The data points to an optimized approach: eagerly load images above the fold while liberally lazy loading everything below it. That combination preserves most of the byte savings while eliminating the LCP penalty.

Who is actually using lazy loading?

According to the HTTP Archive, browser-level image lazy loading is now used by 29% of websites, and adoption has been growing rapidly. A query into the raw HTTP Archive data reveals that WordPress is the primary driver: 84% of sites using this technique run WordPress, 2% use another CMS, and the remaining 14% don't use a known CMS.

WordPress adoption of lazy loading has exploded over the past year. In July 2020, WordPress sites using lazy loading represented about 1% of the corpus of roughly 6 million websites. That number has grown to over 1 million sites, now 14% of the total.

Correlational data: lazy loading is linked to slower LCP

Comparing pages with and without browser-level image lazy loading in the HTTP Archive reveals a worrying pattern. Using LCP data from the Chrome User Experience Report (CrUX)—which reflects real-user experiences rather than lab tests—the median page without lazy loading has a 75th percentile LCP of 2,922 milliseconds. The median page with lazy loading comes in at 3,546 milliseconds. Sites using lazy loading tend to have worse LCP.

Because WordPress sites dominate the lazy loading cohort and may have other performance characteristics, the comparison was narrowed to WordPress sites only. The pattern persists: the median WordPress page without lazy loading has a 75th percentile LCP of 3,495 milliseconds, versus 3,768 milliseconds for those with lazy loading enabled.

These are correlational findings. To answer the causality question, the team designed a lab-based A/B test.

Causal testing: what lazy loading actually costs

The experiment tested a demo WordPress site running the twentytwentyone theme. Archive and single pages (home and article page types) were tested on desktop and emulated mobile devices via WebPageTest, with each combination run nine times to obtain median LCP and image byte counts.

The LCP results were stark. Disabling lazy loading on archive pages produced a significant LCP improvement. On single pages, the differences were smaller; while disabling lazy loading seemed slightly faster, the change was within one standard deviation on both desktop and mobile, suggesting variance rather than a meaningful effect. For archive pages, the difference was closer to two to three standard deviations.

Lazy loading showed a clear positive effect on reducing image bytes. When a real user scrolls through an entire page, all images eventually load as they cross into the viewport, but the initial page load carries fewer bytes when lazy loading is in place.

The bottom line from the A/B test: WordPress's lazy loading approach significantly reduces image bytes, but it does so at the cost of a delayed LCP.

Above-the-fold is the problem

WordPress's current implementation lazy-loads images within the initial viewport—above the fold. This pattern was previously acknowledged in guidance for CMSs as one to avoid, but experimental data at the time suggested the LCP impact would be minimal, and the simpler implementation was judged worth it.

Given the new data, an experimental fix was created: avoid lazy loading images above the fold, and only lazy load below-the-fold images. Tested under the same conditions as the original A/B test, the results showed a complete reversal of the LCP regression, with a possible slight improvement over disabling lazy loading entirely. One explanation: by not loading below-the-fold images, network contention with the LCP image is reduced, allowing it to load faster.

The byte savings were unchanged by the fix. Lazy loading below-the-fold images preserved the main benefit of the default behavior.

Caveats with the heuristic

The fix has limitations. WordPress determines which images to lazy load server-side, so it doesn't know a user's viewport size. Instead, the fix uses heuristics based on an image's relative position in the markup. The first featured image on the page or the first image in main content is assumed to be at or near the top of the viewport and is not lazy-loaded.

Accuracy can vary based on page structure and user behavior. The number of words in a heading or early paragraph text can push an image below the fold. Viewport size and anchor links that change scroll position also affect whether the heuristic holds. The fix is calibrated for general performance, not for every real-world edge case.

How to apply the findings

For sites running WordPress, a patch to core implementing this experimental fix is the highest priority change. The guidance in the Browser-level lazy-loading for CMSs documentation will also be updated to clarify the negative effects of above-the-fold lazy loading and how CMSs can avoid the antipattern.

For developers generally, tools like Lighthouse may eventually flag lazy loading antipatterns; follow the feature request on GitHub for that progress. In the meantime, adding detailed logging to field data is a practical approach to detecting when LCP elements are being lazy-loaded.

The preceding JavaScript snippet will evaluate the most recent LCP element and log a warning if it was lazy-loaded.

The findings also highlight a sharp edge of the lazy loading technique and an opportunity for platform-level improvements. An open Chromium issue is experimenting with natively loading the first few images eagerly, despite the loading attribute.

If your site uses browser-level lazy loading, check how it's implemented and run A/B tests to measure its impact on your performance. More eager loading above the fold may well be worth it. WordPress sites should see a patch land in core soon; other CMS users should ensure their platforms are aware of these performance considerations.