Core Web Vitals: how to speed up your site and what affects the score

Core Web Vitals are three Google metrics: how fast users see the main content (LCP), how quickly the page responds to input (INP) and whether the layout jumps while loading (CLS). Good means LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 for 75% of visits. Images, fonts, JavaScript size and server speed move them most.

Here is what each metric means, where to see real data and what to fix first.

What are Core Web Vitals and why do they matter?

Core Web Vitals are user experience metrics that Google uses as one of its ranking signals and publishes from real Chrome visits. More important than rankings, a slow and unstable page loses visitors and conversions: people leave before it loads and mis-tap buttons that shift.

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Time to render the largest above-the-fold element	up to 2.5 s	2.5–4 s	over 4 s
INP (Interaction to Next Paint)	Delay between a user action and the page's response	up to 200 ms	200–500 ms	over 500 ms
CLS (Cumulative Layout Shift)	How much the layout shifts during loading	up to 0.1	0.1–0.25	over 0.25

Google publishes the thresholds on web.dev. The 75th percentile is assessed: a page passes if three quarters of visits have good values. In 2024 INP replaced the earlier FID metric and judges responsiveness more strictly.

Where do you see real rather than lab data?

Real data comes from reports built on actual user visits: Search Console, the field data section of PageSpeed Insights, the Chrome UX Report or your own metrics collection. A Lighthouse lab test is useful for debugging but does not show how your site behaves on your visitors' slow phones.

The difference:

• field data — real devices, networks and journeys; updated with a delay and needs traffic;
• lab data — a single simulation; handy for checking fixes before deploying;
• INP can barely be measured in the lab — it depends on real user interactions.

Google's web-vitals library works well for collecting your own data:

import { onLCP, onINP, onCLS } from 'web-vitals'

function send(metric) {
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    page: location.pathname,
  }))
}

onLCP(send)
onINP(send)
onCLS(send)

How do you improve LCP?

Improve LCP by speeding up the largest above-the-fold element — usually the hero image or headline. Heavy images, a slow server response and render-blocking resources are the usual culprits.

What to do:

1. Serve the hero image in a modern format (WebP or AVIF) at the right size for each screen.
2. Do not lazy-load the above-the-fold image, and give it high fetch priority.
3. Cut server response time: page caching, a CDN, fast database queries — see caching in web applications.
4. Serve HTML from the server so the largest element does not wait for JavaScript.
5. Preload critical fonts and use font-display: swap.

Photo: Unsplash

How do you improve INP and CLS?

Improve INP by reducing JavaScript work on the browser's main thread, and CLS by reserving space in advance for anything that loads later. Both problems most often come from third-party scripts and careless layout.

Responsiveness: INP

• ship less JavaScript: split code by page and remove unused libraries;
• break long tasks into chunks so the browser can respond to clicks;
• defer chat widgets, analytics and ads until interaction or idle time;
• avoid heavy computation in click and input handlers.

Stability: CLS

• set dimensions on images and video (width and height, or aspect-ratio);
• reserve space for banners, ads and embeds;
• do not insert content above what is already shown, except in response to user action;
• choose a fallback font with metrics close to the main one so text does not jump on swap.

Where should optimisation start?

Start with the most visited page templates and the metric that is worst in field data. One fix in the product page template improves thousands of pages at once, while optimising a rarely visited page achieves almost nothing.

The workflow:

1. Open the Core Web Vitals report in Search Console and find page groups with poor values.
2. Reproduce the problem in Lighthouse or browser developer tools on a typical template.
3. Fix the main cause and verify it in the lab.
4. Deploy and wait for field data to update — this takes a few weeks.

Speed checks also belong in your pre-launch checklist — see our technical SEO checklist.

In short

• Core Web Vitals: LCP under 2.5 s, INP under 200 ms, CLS under 0.1 for 75% of visits.
• Rely on field data from real users; use lab data for debugging.
• LCP: a light hero image without lazy loading, a fast server, server-rendered HTML.
• INP: less JavaScript and deferred third-party scripts; CLS: media dimensions and reserved space.
• Start with the most visited templates and the worst metric.