Core Web Vitals are Google's user-centred performance metrics, and images influence every one of them. A heavy hero image slows your Largest Contentful Paint, an image without declared dimensions causes layout shift, and decoding oversized files can block the main thread and hurt responsiveness. Get images right and you move from failing to passing on the metrics that affect both user experience and search ranking. This guide connects image optimisation directly to each vital.
We will reference the optimise JPEG tool for the fixes, but the diagnostics apply to any toolchain you use.
The Three Core Web Vitals
As of 2026 the three metrics that make up Core Web Vitals are:
- Largest Contentful Paint (LCP): How long until the biggest visible element renders. Often an image.
- Cumulative Layout Shift (CLS): How much the page jumps around as it loads.
- Interaction to Next Paint (INP): How responsive the page feels to user input.
Images and LCP: The Biggest Lever
On most pages the LCP element is a hero image, banner, or product photo. Because the browser cannot paint it until it has downloaded enough bytes, image weight directly sets your LCP time. A 600 KB hero on a mobile connection can push LCP past four seconds; the same image optimised to 120 KB can bring it comfortably under the 2.5-second "good" threshold.
The fixes are straightforward: right-size the image to its display dimensions, compress it to around quality 80, strip metadata, and consider WebP. Walk through the exact settings in how to optimise JPEG, and for the format question see JPEG versus WebP. Preloading the LCP image and making sure you do not lazy-load it also help it arrive sooner.
Images and CLS: Reserve the Space
Cumulative Layout Shift happens when content moves after it first renders. The classic cause is an image with no declared width and height: the browser does not know how tall it will be, so surrounding content jumps when the image loads. The fix costs nothing — always set width and height attributes, or a CSS aspect-ratio, so the browser reserves the correct space up front. This single habit eliminates the most common source of layout shift.
Images and INP: Decode Cost
Interaction to Next Paint measures responsiveness. Very large images are expensive to decode, and decoding can occupy the main thread at exactly the moment a user is trying to interact. Smaller, right-sized images decode faster and free the main thread, indirectly helping INP. This is yet another reason not to ship a 4000px image into an 800px slot.
A Diagnostic and Fix Checklist
Run through this list for any page that is failing its vitals:
- Identify the LCP element. Use Lighthouse or PageSpeed Insights; it is usually an image.
- Right-size it. Resize to display dimensions with the resize image tool, allowing for high-density screens.
- Compress it. Run it through the optimise JPEG tool at quality 80 and strip metadata.
- Serve WebP. Add a smaller WebP via the JPEG to WebP tool with a JPEG fallback.
- Set dimensions. Add width and height attributes to every image to eliminate layout shift.
- Preload the hero. Preload the LCP image and do not lazy-load it.
- Lazy-load the rest. Defer off-screen images so they do not compete with the hero for bandwidth.
Optimised JPEG Versus Unoptimised: The Impact
- Unoptimised hero (600 KB): LCP often 3.5–5 seconds on mobile; frequently fails.
- Optimised JPEG (120 KB): LCP often under 2.5 seconds; passes on most connections.
- Optimised WebP (90 KB): Fastest of the three; best headroom on slow networks.
Measuring Real Users
Lab tools like Lighthouse are a starting point, but Core Web Vitals ranking uses field data from real visitors. Monitor your Chrome User Experience Report metrics over time, and bake image budgets into your process so regressions are caught early — see how to automate image optimisation and the broader strategy in optimising images for the web. For a fast smaller fallback file, the compress JPEG tool will do it in one step.
Why the LCP Image Deserves Special Treatment
Not all images are equal in the eyes of Core Web Vitals. The single image that becomes your Largest Contentful Paint element has an outsized effect on the metric, so it deserves more care than the rest. Beyond optimising and right-sizing it, there are delivery tricks that help it arrive sooner.
Preloading the hero with a link rel preload tells the browser to fetch it early, before it would otherwise discover it in the markup. Avoiding lazy loading on that one image is equally important, since lazy loading deliberately delays the fetch. You can also set the fetchpriority attribute to high to nudge the browser to prioritise it over less important downloads. Together these ensure the most important pixel on the page is also the fastest to render.
The Hidden Cost of Layout Shift
Layout shift is easy to underestimate because it is not about speed but stability. Yet a page that jumps as images load feels broken, and Google measures that frustration as Cumulative Layout Shift. The most common offender is images without dimensions, but it is worth auditing for less obvious cases too.
Late-loading ad slots, embedded media, and web fonts can all shift content, and an image that loads into an unsized container compounds the problem. The reliable fix is to always reserve space: set width and height attributes on every image, or define a CSS aspect-ratio on its container, so the browser can lay out the page correctly before any image bytes arrive. This habit alone resolves the majority of real-world CLS issues.
Balancing Quality Against Speed
It is tempting to compress hero images aggressively to chase a fast LCP, but a blurry, artefact-ridden hero undermines the very impression you are trying to make. The goal is the smallest file that still looks good, not the smallest file full stop. Quality around 80, combined with right-sizing and a WebP variant, almost always finds that balance. Verify the result visually rather than trusting the number alone, especially on faces and product detail where artefacts are most noticeable.
Lab Data Versus Field Data
One source of confusion is that the score you see in a one-off Lighthouse run can differ from the Core Web Vitals Google actually uses for ranking. Lighthouse measures a single simulated load in lab conditions, while ranking relies on field data aggregated from real visitors over time. An image fix can show up instantly in the lab but take weeks to move the field metric, because the field figure is a rolling average across your real audience.
The practical implication is to use lab tools for fast iteration while you tune images, then watch the field data to confirm the improvement reaches real users. If your lab score is good but field LCP is still poor, the culprit is often a slow network segment of your audience or a heavy image on a page the lab test did not cover. Optimising images broadly, not just on the page you happened to test, is what moves the field numbers.
Conclusion
Images touch every Core Web Vital: they drive LCP, cause CLS when undimensioned, and tax INP when oversized. Right-size, compress to quality 80, set dimensions, and serve WebP with a fallback. Start with your hero image in the optimise JPEG tool at jpegoptim and watch your vitals improve.