Why one image matters more than the rest
Google measures perceived load speed partly by the Largest Contentful Paint (LCP): the moment the largest immediately visible element has finished loading. On most pages that's an image — the hero shot, a large banner, the product photo. If that one image loads fast, the whole page feels fast. If it loads late, all other optimization helps little. That's why it pays to speed up this one element specifically.
Step 1: find the LCP element
Before you optimize, you need to know which image it is. Open the page in Chrome DevTools → "Performance" tab → record the page load; the LCP marker shows you the element. Alternatively the Lighthouse report shows the "Largest Contentful Paint element" directly. Usually it's predictable — the big image right at the top.
Step 2 (the most important): do NOT lazy-load
The most common mistake first: the LCP image must never have loading="lazy". Lazy loading deliberately delays — exactly the wrong thing for the image that should be there early. So check first whether the LCP image accidentally has a blanket lazy attribute (see Lazy loading for images).
Step 3: preload
A preload link in the <head> tells the browser: load this image immediately and preferentially, without waiting to discover it during rendering.
<link rel="preload" as="image" href="hero-1200.jpg">For responsive images you can even couple the preload to srcset/sizes, so the browser preloads the right variant straight away:
<link rel="preload" as="image"
href="hero-1200.jpg"
imagesrcset="hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
imagesizes="100vw">Step 4: set fetchpriority
Even simpler than a preload link, on an <img> element, is the attribute fetchpriority="high" — it raises the load priority directly on the image:
<img src="hero-1200.jpg" alt="..." width="1200" height="600" fetchpriority="high">For most cases that's already enough. A preload link and fetchpriority can be combined, but each is often sufficient on its own.
The three mistakes that undo the effect
- Preloading too much. Preload is for exactly one element. Multiple preloads compete and slow each other down.
- Preloading the wrong element. If you don't speed up the real LCP image, it does nothing — measure first, then act.
- Preloading an unoptimized image. A 4-MB image loaded early is still slow. First bring it to sensible dimensions (resize) and compress it (WebP), then prioritize.
Preload and fetchpriority are the final polish — the foundation stays a small, correctly sized image. The full Core Web Vitals picture is in Improving Core Web Vitals.
Frequently asked questions
What is the LCP element?
Largest Contentful Paint measures when the largest immediately visible element has loaded — usually a hero image, a large banner, or a prominent heading. Google treats the LCP time as a central Core Web Vitals value; a fast LCP makes a page feel fast to users.
What does preloading an image do?
A preload link in the head tells the browser to load this image early and at high priority instead of discovering it only during rendering. For the LCP image this can noticeably shorten the measured load time — it appears visibly sooner.
Should I preload all images?
Absolutely not. Preload pulls bandwidth forward onto a single element. Preload too many and they compete, making everything slower. Preload is a scalpel for exactly one element: the LCP image.
What does fetchpriority="high" do?
It signals the browser to load an image preferentially, without a separate preload link. For an img LCP element, fetchpriority="high" is often the simplest way to prioritize it — and lazy loading should be explicitly removed from that image.
Sources
web.dev — Largest Contentful Paint · MDN — rel=preload · web.dev — fetchpriority.