How to improve Core Web Vitals: a practical guide to LCP, INP and CLS

Core Web Vitals are three measurements Google uses to describe the experience of loading and using a page: how quickly the main content appears, how quickly the page responds when someone interacts with it, and how much the layout jumps around. They're part of how Google evaluates page experience, though relevant, helpful content matters far more for rankings. Mostly, they're a good proxy for whether your site feels fast.

The three metrics and what counts as good

• Largest Contentful Paint (LCP) — when the largest image or text block in the viewport has rendered. Good: 2.5 seconds or less; poor: over 4 seconds.
• Interaction to Next Paint (INP) — how long the page takes to visibly respond to clicks, taps and key presses, across the whole visit. Good: 200 milliseconds or less; poor: over 500 ms. INP replaced First Input Delay as a Core Web Vital in March 2024.
• Cumulative Layout Shift (CLS) — how much visible content moves unexpectedly. Good: 0.1 or less; poor: over 0.25.

A page passes when 75% of page loads (the 75th percentile) meet the "good" threshold for each metric, measured separately for mobile and desktop. That means the slower quarter of your visitors don't count against you, but the typical visitor on a mid-range phone does.

Lab data versus field data

Field data comes from real visitors. Google's Chrome UX Report collects it from Chrome users who opted in, over a rolling 28-day window, and it's what Search Console's Core Web Vitals report and the top of PageSpeed Insights show. It's the data that counts — but it needs enough traffic, and it changes slowly.

Lab data comes from loading the page once under controlled conditions, as Lighthouse does. It's available instantly for any page and shows you why a metric is slow, which makes it the tool for diagnosis. But one lab run on a simulated phone won't match your visitors' real devices and networks, and a lab test can't measure INP at all, because nobody is interacting with the page. Total Blocking Time (TBT), the time the main thread is too busy to respond during loading, is the closest lab signal.

Use both: field data to know whether you have a problem and whether your fix worked; lab data to find the cause. To collect your own field data, the open-source web-vitals JavaScript library reports all three metrics from real visits to your analytics.

Improving LCP

LCP time splits into four parts: time to first byte, the delay before the browser starts loading the LCP resource, the time to download it, and the delay before it renders. Find which part is large, then:

• Speed up the server response with page caching and a CDN, so the HTML arrives quickly.
• Make the LCP image discoverable early: use a normal <img> in the HTML rather than a CSS background or an image injected by JavaScript, and never loading="lazy" on it.
• Prioritise it: add fetchpriority="high" to the LCP image, or preload it if it's referenced late.
• Make it smaller: serve it at its displayed size in WebP or AVIF — see how to reduce image size.
• Remove render-blocking resources: inline critical CSS, defer non-essential scripts, and avoid large client-side rendering before the main content appears.

Improving INP

INP is slow when the browser's main thread is busy — usually running JavaScript — at the moment someone interacts, or when the work triggered by the interaction takes long to paint.

• Ship less JavaScript. Remove unused libraries and plugins, split bundles, and don't hydrate parts of the page that don't need to be interactive.
• Break up long tasks. Split work over 50 ms into smaller chunks and yield to the browser between them, with setTimeout or scheduler.yield() where supported.
• Do less in event handlers. Update the UI first, then do the expensive work; debounce input handlers.
• Audit third-party scripts. Chat widgets, tag managers and A/B testing tools often run heavy code on every interaction. Load them later, or only when needed.
• Keep the DOM reasonably small, because large DOMs make every re-render slower.

Improving CLS

• Give images and videos dimensions with width and height attributes or CSS aspect-ratio, so space is reserved before they load.
• Reserve space for ads, embeds and banners. Give their containers a minimum height, and don't insert content above what the visitor is already reading.
• Tame web fonts. Use font-display: swap or optional, preload key fonts, and use a fallback font with matched metrics (size-adjust) to reduce the shift when the web font arrives.
• Animate with transform, not properties like top or height that move surrounding content.
• Let the back/forward cache work — avoid unload handlers — so returning visits restore instantly without shifts.

Where Rudra fits

The free website speed checker runs one Lighthouse lab test with its default mobile simulation. Each metric is shown with its measured value, labelled as a lab measurement from one run, and compared with the published thresholds — LCP 2.5 s / 4 s, CLS 0.1 / 0.25, TBT 200 / 600 ms. Failing audits list up to five of the files or elements responsible, with estimated savings, so you know where to start. It doesn't measure INP or include field data; check those in Search Console or PageSpeed Insights. For the reasons a page is slow overall, see why is my website slow.

A process that works

1. Check Search Console's Core Web Vitals report to find which metric fails and on which group of pages.
2. Pick a representative page from that group and run a lab test several times.
3. Fix the biggest cause first, deploy, and re-test in the lab.
4. Wait for field data to update (it's a 28-day window) before judging the result.