Lazy-loading every image on a site is a good habit: nothing below the fold is fetched up front and the initial load gets lighter. But there is exactly one image you must not lazy-load — the big one on the first screen. That is the image the visitor needs right now.
What perceived speed is measured by
Whether a page feels fast is well described by when the largest element on the first screen finishes drawing. Usually that is the hero image or a large heading. However quickly everything else arrives, if that element is late the page feels slow.
So for the first-screen image the question narrows to one thing: how soon does the browser find out this image exists? If the request starts late, a small file still paints late.
Three things to get right
First, put it in the markup as an ordinary image tag. An image written into the HTML is found as the browser scans the document and the request starts immediately. A background image in a stylesheet is only found after the CSS has been fetched and parsed; an image inserted by a script waits for that script to run.
Second, do not lazy-load it, and raise its priority. It is worth telling the browser explicitly that this resource is needed now.
<!-- First-screen hero -->
<img src="/img/hero-1200.webp"
srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w, /img/hero-1800.webp 1800w"
sizes="(min-width: 992px) 60vw, 100vw"
width="1200" height="750"
fetchpriority="high"
alt="…">
<!-- Images further down get the opposite treatment -->
<img src="/img/section.webp" loading="lazy" decoding="async"
width="800" height="500" alt="…">Third, always write the dimensions. With width and height present the browser reserves the space before the image arrives. Without them, everything below jumps the moment it lands — the same class of problem as a late font swap.
Preloading is not a cure-all
When the image really is a CSS background or lives inside a slider and the structure is hard to change, preloading can pull the discovery time forward. There is a trap, though: several preloads compete with one another. Preload a handful of font subsets and a few images at once and the largest element is the very thing that gets pushed back.
The fastest hero image is no image at all
One design option is worth leaving here. Build the first screen from typography and blocks of colour and the large image request disappears entirely. The largest element becomes the heading text, and text — given a font that arrives on time — paints far sooner than any photograph.
Businesses that genuinely need photography will of course use it. But “a hero needs a big photograph” is a convention rather than a requirement, and remembering that what goes on the first screen is partly a performance decision widens the options at design time.
The same subject as a checklist lives in the hero preload checklist, and image optimisation generally is covered in the images and media series. Measuring and fixing the bottleneck on a real page is part of our optimization program.