Don't lazy-load the image people see first (Web HIG tip #15)

[frozonfreak]

Open your home page or a product page on a phone, on a slow connection. The headline and buttons show up, but the big hero image stays blank for a beat longer than everything else. Look at its markup and you'll often find loading="lazy", added to every <img> on the site by a template, a plugin, or a well-meant "lazy-load all images" change.

Web HIG tip #15 (Quick #84): Lazy-load below-the-fold media; never lazy-load the LCP candidate.

Why it matters

Lazy loading is a trade: the browser waits to fetch an image until it's close to the viewport. That's a win for images further down the page, and a loss for the one people see first:

• Images far below the fold that nobody scrolls to never download, which saves data and leaves bandwidth for what's on screen
• A lazy image's fetch can't start until the browser has laid out the page and worked out where the image sits, so a lazy hero image starts downloading later than it would have otherwise
• The LCP candidate is usually the biggest image or text block in the first view. When it arrives late, the page looks unfinished, and Largest Contentful Paint gets worse
• If the image URL only exists in JavaScript, for example a data-src that a script swaps in, the browser can't find it in the HTML at all until that script runs

The full HIG covers the image side of this in §2.1, Document Fundamentals, under responsive images: lazy-load non-critical images where appropriate, and avoid lazy-loading the LCP candidate and other immediately needed content. The LCP candidate SHOULD be discoverable early and MAY use fetchpriority="high" when appropriate. Quick #84 is Quick-only guidance, with no rule ID of its own. It pairs with Quick #83, which asks every image to declare its dimensions or aspect ratio, and with Quick #82's LCP target of 2.5 s or less.

The rule of thumb

Ask: will this image be on screen before anyone scrolls? If yes, don't lazy-load it.

This page looks fine on a fast laptop, but the hero waits for layout and for a script before it even starts downloading:

<!-- Hero: the LCP candidate, hidden from the browser until JS runs -->
<img class="lazy" data-src="https://example.com/img/hero.jpg" alt="">

<!-- Further down the page -->
<img src="https://example.com/img/team.jpg" alt="The team at the spring meetup">

Load the hero early and lazy-load what's further down:

<!-- Hero: a real src in the HTML, high priority, not lazy -->
<img src="https://example.com/img/hero.jpg"
     width="1200" height="600"
     fetchpriority="high"
     alt="A reader using the app on a phone">

<!-- Further down the page -->
<img src="https://example.com/img/team.jpg"
     width="800" height="533"
     loading="lazy"
     alt="The team at the spring meetup">

The page looks the same. The difference is when each image starts downloading.

Do this instead

• Leave loading off the LCP image (the default is eager), give it a real src or srcset in the HTML, and consider fetchpriority="high". Browsers that don't support fetchpriority ignore it
• Add loading="lazy" to images and iframes that sit well below the first view: long article bodies, comment sections, footers, embedded maps and video players
• For a <video> further down the page, use preload="none" (or "metadata") and a poster image. loading="lazy" on <video> is newly specified but only some browsers support it so far, so treat it as a bonus, not the fix
• In a carousel or gallery, load the first slide eagerly and lazy-load the rest
• Give lazy images width and height (or a CSS aspect-ratio) so the page doesn't jump when they arrive
• If the hero is a CSS background-image, the browser only finds it after the CSS has loaded. Use an <img> instead, or add <link rel="preload" as="image"> for it
• The LCP element can be different on a phone and on a desktop. Check both layouts before you decide which images stay eager

Quick check for your app

Open your main pages (say, example.com and example.com/products) at a phone width and at a desktop width. In the browser's developer tools, find the LCP element in a performance recording, then check its markup: no loading="lazy", and a URL that's in the HTML rather than added by a script. Scroll down and watch the network panel: images further down should only start loading as you get near them. A tool can flag a lazy-loaded LCP image in a single lab run, but only checking the real LCP element on your own pages, at the widths people use, shows which image needs to load first.

---

The Web HIG is an open set of guidelines for how the web should behave, not a component library. Design systems define how it looks. The Web HIG defines how it behaves.

• GitHub: Don't lazy-load the image people see first (Web HIG tip #15) #32
• Hashnode: https://thewebhig.hashnode.dev/dont-lazy-load-the-image-people-see-first-web-hig-tip-15
• Dev.to: https://dev.to/frozonfreak/dont-lazy-load-the-image-people-see-first-web-hig-tip-15-38k3
• Bluesky: https://bsky.app/profile/sastha.bsky.social/post/3mzmmnfubak2p