Core Web Vitals Explained: How to Test and Improve Them (2026)

Page speed stopped being a vague aspiration when Google turned it into three concrete, measurable metrics called Core Web Vitals. They quantify how a page actually feels to a real user — how fast it loads, how quickly it responds, and how stable it stays — and they feed into Google's ranking signals. This guide explains each metric, what counts as a good score, how to test your site with free tools, and the highest-impact ways to improve every one of them.

What Core Web Vitals are

Core Web Vitals are three user-centric performance metrics that Google selected to represent the essentials of a good page experience. Largest Contentful Paint (LCP) measures loading: how long until the largest visible element (often a hero image or heading) has rendered. Interaction to Next Paint (INP) measures responsiveness: how quickly the page reacts to user interactions across the whole visit. Cumulative Layout Shift (CLS) measures visual stability: how much the layout jumps around unexpectedly while loading. Each captures a distinct, common frustration — slow loads, laggy taps, and content that shifts just as you go to click it.

The thresholds: what counts as good

Google defines three bands per metric, assessed at the 75th percentile of page loads (so you must be good for most of your users, not just on average):

Metric	Good	Needs improvement	Poor
LCP (loading)	≤ 2.5s	2.5s - 4.0s	> 4.0s
INP (responsiveness)	≤ 200ms	200ms - 500ms	> 500ms
CLS (stability)	≤ 0.1	0.1 - 0.25	> 0.25

Hitting "good" on all three at the 75th percentile is the bar to aim for. It is a meaningful target, because the 75th-percentile rule means a fast experience for your median user is not enough — your slower-device, slower-network users count too.

A note on INP replacing FID

If you learned Core Web Vitals a couple of years ago, note an important change: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed, which was easy to pass and did not reflect the whole experience. INP is stricter and more representative: it considers interactions throughout the visit and reports a value close to the worst, so it captures the laggy taps and clicks users actually feel. Many sites that comfortably passed FID now have INP work to do, which is why responsiveness has become the metric to watch. We cover it in depth in INP explained.

Largest Contentful Paint (LCP)

LCP is usually the most tractable metric, because it has a small number of common causes. The largest element is typically a hero image, a background image, a large text block or a video poster, and LCP is slow when that resource is slow to arrive or slow to render. The highest-impact fixes are: optimise and properly size the LCP image (modern formats like WebP/AVIF, correct dimensions, compression); preload the LCP resource so the browser fetches it early; serve from a fast host/CDN; eliminate render-blocking CSS and JavaScript that delay rendering; and avoid lazy-loading the LCP image (a frequent self-inflicted wound). Because LCP is dominated by one element, finding and fixing that element often moves the metric dramatically.

Interaction to Next Paint (INP)

INP is about the main thread. When a user taps or clicks, the browser needs to run the associated JavaScript and then paint the result; if the main thread is busy with long tasks, that response is delayed and the page feels sluggish. Poor INP almost always traces back to too much JavaScript and long tasks that monopolise the main thread. The fixes: break up long tasks and yield to the main thread, reduce and defer non-critical JavaScript, minimise third-party scripts, keep event handlers light, and avoid forcing expensive layout work during interactions. Because INP reflects the whole visit, it rewards a consistently responsive page rather than a fast first impression — see the dedicated INP guide for the detail.

Cumulative Layout Shift (CLS)

CLS is often the easiest to fix once you know the causes. Layout shifts happen when content moves after it has already rendered, usually because the browser did not know how much space something would take. The classic culprits are images and videos without width/height attributes, ads and embeds that inject space, web fonts that swap and reflow text, and content injected above existing content. The remedies are direct: always set dimensions (or use CSS aspect-ratio) on media, reserve space for ads and embeds, use font-display and preload key fonts to limit reflow, and avoid inserting content above what the user is already looking at. A little discipline here usually takes CLS comfortably under 0.1.

Field data vs lab data

A crucial distinction shapes how you work with Core Web Vitals. Field data is collected from real users (Google's source is the Chrome UX Report, CrUX) and is what Google actually uses for ranking — it reflects your real mix of devices, networks and behaviour. Lab data comes from a single controlled test (Lighthouse) on a fixed device and connection; it is reproducible and perfect for diagnosing problems, but it is a simulation, not reality. The practical workflow: diagnose and iterate with lab data because it is fast and repeatable, but judge success by field data because that is what counts. A page can look great in Lighthouse and still fail in the field if real users are on slower devices than the test assumes.

How to test your Core Web Vitals

Several free tools cover the bases. PageSpeed Insights shows both field data (if available) and a lab test for any URL, with specific recommendations. Google Search Console has a Core Web Vitals report that groups your site's URLs by status using field data — the best view of site-wide health. Lighthouse in Chrome DevTools runs a local lab audit for deep diagnosis. For ongoing, real-user measurement, the open-source web-vitals JavaScript library reports the metrics from your actual visitors into your analytics. Broader site audits — StackOptic among them — also surface Core Web Vitals alongside SEO, security and AI-readiness, which is handy when you want the whole picture in one place.

How to improve them, in priority order

When everything needs work, sequence matters. Start with the metric that is failing and affects the most pages, but as a general order of impact: fix the LCP element first (it is usually one resource and gives a big, visible win), then tackle INP by cutting and deferring JavaScript (the hardest but increasingly the most important), then eliminate CLS (often quick once you set dimensions and reserve space). Re-measure after each change with field data, and resist the temptation to chase a perfect lab score at the expense of the real-user numbers that actually count.

The business case beyond rankings

It is easy to frame Core Web Vitals as an SEO chore, but the stronger argument is commercial. Speed and stability directly affect behaviour: slow pages lose visitors before they ever see the content, laggy interactions erode trust during the moments that matter most (adding to cart, submitting a form), and unexpected layout shifts cause mis-clicks that frustrate users and convert poorly. Case studies across retail, media and SaaS have repeatedly linked faster pages to lower bounce rates and higher conversions — the exact outcomes a business cares about regardless of Google. That reframing matters for prioritisation: when performance work competes with feature work for engineering time, "it lifts conversion and reduces abandonment" is a more persuasive case than "it might help rankings", and both happen to be true. Treat Core Web Vitals as a user-experience and revenue lever that also pays an SEO dividend, rather than the other way around.

Keep them from regressing

Hitting good scores once is not the finish line. Every new feature, third-party tag, font or image is a chance to regress, and performance quietly decays as a site grows. Build a habit of checking field data regularly, set a performance budget your team agrees not to exceed, and re-test important pages whenever you ship significant changes — so a regression is caught in days, not discovered months later in a ranking dip or a drop in conversions.

Common mistakes

• Optimising for the lab score while field data stays poor.
• Lazy-loading the LCP image, which delays the very thing LCP measures.
• Ignoring INP because the site passed the old FID metric.
• Forgetting media dimensions, the most common cause of layout shift.
• Treating it as one-and-done — performance regresses as you add features, so monitor continuously.

Go deeper

• The responsiveness metric in depth: INP (Interaction to Next Paint) explained.
• Performance and AI: how to check if your site is ready for AI search.
• Fonts and performance: how to find what fonts and colours a website uses.

Want your Core Web Vitals scored alongside SEO, security and AI-readiness? Analyse any URL with StackOptic — one report, free, no sign-up.