Updated: August 1, 2026
Quick answer: Identify the actual LCP image, serve a correctly sized candidate, make it discoverable in HTML, avoid lazy-loading it, test priority/preload carefully, and reserve dimensions. Then measure LCP and CLS on throttled and field data.
Core Web Vitals are user-experience metrics, not file-format badges. Image compression can reduce transfer time, but a page may still have poor LCP if the browser discovers the image late or a server transform is slow. CLS is usually a geometry problem: the browser needs dimensions before the image arrives.
Which Metric Is the Image Affecting?
| Metric | Image-related failure | First place to look |
|---|---|---|
| LCP | main image is large, late, low-priority, or slow to transform | trace, LCP URL, request timing |
| CLS | image has no reserved dimensions | width/height, aspect ratio, injected media |
| INP | heavy image decode or script work competes with interaction | main-thread trace and image decode |
This article focuses on image causes, not every cause of each metric. web.dev’s LCP guidance and CLS guidance provide the broader metric definitions and techniques.
Step 1: Identify the Actual LCP Element
Do not assume the hero image is LCP. On some pages the headline or a text block wins. Use a performance trace or a lab report to find the element and its resource URL. Then record:
- request start relative to navigation;
- response and decode duration;
- intrinsic dimensions and transferred bytes;
- selected
srcsetcandidate; - cache status and image transformation;
- whether the image is in HTML, CSS, or injected by JavaScript.
Only optimize the image path if it is actually relevant to the metric.
Step 2: Serve the Right Pixels
Generate responsive candidates from the clean source and use srcset/sizes. A 2400px desktop image sent to a 390px viewport wastes bytes and decode work. An image that is too small for its CSS slot may be fast but blurry.
<img
src="hero-1600.webp"
srcset="hero-640.webp 640w, hero-1000.webp 1000w, hero-1600.webp 1600w"
sizes="(max-width: 720px) 100vw, 1000px"
width="1600"
height="900"
alt="A mountain road at sunrise"
/>
web.dev’s responsive image guidance explains how candidate selection reduces resource load duration when the LCP element is an image.
Step 3: Make the Image Discoverable
Prefer a standard <img> for a meaningful LCP image. An image hidden in a CSS background or created after JavaScript runs may be discovered later. If a background is unavoidable, measure its request timing and consider a carefully matched preload.
Do not preload every format and every responsive width. A preload that does not match the eventual src/srcset can create duplicate work.
Step 4: Use Priority Hints Carefully
If the trace shows the LCP image is discovered but not fetched early enough, test fetchpriority="high" or a responsive preload. MDN’s fetchpriority reference describes it as a browser hint. It cannot fix a wrong candidate, a slow server, or an image that is not LCP.
Do not assign high priority to multiple large images; they will compete with the actual main content.
Step 5: Do Not Lazy-Load the LCP Image
Native lazy loading is useful below the fold. If the main image is lazy-loaded, the browser may wait for layout or JavaScript before starting it. Remove lazy loading from the confirmed LCP candidate, then measure rather than applying the rule to every page blindly.
Step 6: Reserve Space for CLS
Use width and height or an aspect ratio on content images. The browser can then allocate the box before the response arrives. web.dev’s CLS article describes this as a primary image-related fix.
Step 7: Tune Encoding Last
Once dimensions and discovery are correct, compare JPEG, WebP, and AVIF from the same source at similar visual quality. Inspect the image at its rendered size. A smaller file can improve the resource-load portion of LCP, but aggressive compression that makes the main message unclear is not a good user-experience trade.
Distinguish Transfer, Server, and Decode Time
An image may be slow because:
- the server waits to generate a variant;
- the response is large on a slow connection;
- the browser decodes a huge intrinsic canvas;
- the request starts late;
- the resource is blocked by other high-priority work.
Compression only addresses part of the second and sometimes the third. Use the trace to choose the remedy.
Field Data vs Lab Data
Lab runs help reproduce a page under controlled throttling. Field data reflects real devices, networks, caches, and page variants. Compare both when available and avoid claiming a universal improvement from one desktop run.
Common Mistakes
- converting to WebP without checking LCP discovery;
- lazy-loading the actual LCP image;
- preloading all image formats;
- serving a full desktop candidate on mobile;
- omitting dimensions and causing CLS;
- applying
fetchpriority="high"to every image; - measuring only the local file, not the network response;
- using a CSS background for meaningful content without testing discovery.
Final Checklist
- LCP element identified from a trace;
- candidate dimensions match the viewport;
- HTML discovery path verified;
- lazy loading removed only from actual above-fold main content;
- priority/preload tested and scoped;
- width/height or aspect ratio present;
- format and quality compared from the master;
- LCP, CLS, bytes, and request timing remeasured.