Core Web Vitals are the three measurements Google uses to judge whether a page feels fast, responsive and stable to the people who actually use it. As of 2026 they are Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. INP replaced First Input Delay (FID) in March 2024, and a surprising amount of advice online still describes the old set. This guide covers the current metrics, the official thresholds, the difference between the lab numbers you see in PageSpeed Insights and the field numbers Google actually uses, what to fix for each metric, and a before-and-after from our own website that shows what progress looks like when the numbers are read honestly.
What Core Web Vitals are, and why they matter for a business website
Google introduced Core Web Vitals in 2020 as a small, stable set of user-experience metrics, and folded them into search ranking with the page experience update in 2021. They are not a speed score; they are three specific measurements of what a visitor experiences: how long until the main content is visible, how quickly the page reacts when they tap or click, and whether things jump around while they are trying to read or press a button.
Two things are worth stating plainly. First, Core Web Vitals are a ranking signal, but a light one. Google has been consistent that relevant, helpful content outweighs page experience, so a fast page with weak content does not outrank a slower page with the right answer. Second, they matter more for conversion than for ranking. A clinic's booking page that shifts as the patient reaches for the "call" button, or a form that takes half a second to respond to each tap, loses contacts regardless of where it ranks. That is why we treat them as part of any clinic SEO work rather than as a separate technical exercise. The official definitions are maintained by Google on web.dev.
The three metrics explained
LCP depends on server response time, render-blocking CSS and JavaScript, and the size and format of the main image. INP replaced FID, which only measured the delay before the first interaction was processed and had become too easy to pass; long tasks from heavy scripts, third-party tags and complex page builders are the usual cause of poor scores. CLS is unitless and its typical causes are images without defined dimensions, fonts that swap after rendering, ads or embeds injected above existing content, and cookie banners that push the page down.
A short historical note for anyone reading older material: First Input Delay (FID) was a Core Web Vital from 2020 until 12 March 2024, when INP took its place. FID no longer appears in Search Console or PageSpeed Insights and does not need to be measured.
Core Web Vitals thresholds: what "good" means
Google assesses each metric at the 75th percentile of page loads, meaning that at least three out of four visits must fall within the "good" range for the page to pass. The thresholds are the same on mobile and desktop, but they are assessed separately, and mobile is where most sites fail.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 – 4.0 s | > 4.0 s |
| INP | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
A page "passes" Core Web Vitals only when all three metrics are in the good range at the 75th percentile. The performance score out of 100 that PageSpeed Insights shows at the top of its report is a separate thing: a Lighthouse lab score that weighs several metrics, including some that are not Core Web Vitals. A site can have a score of 90 and still fail LCP in the field, or a score of 60 and pass everything. Read the three metrics, not the number.
Lab data versus field data, and why Google only uses one of them
This is the distinction that most articles skip and most site owners get wrong. There are two ways to measure Core Web Vitals, and they answer different questions.
Lighthouse, the engine behind PageSpeed Insights and Chrome DevTools, loads your page once on a simulated mid-range phone with a throttled connection.
Reproducible, available for any page immediately, and gives you a diagnosis: which script blocked rendering, which image was too large, which element shifted.
Not what Google ranks on. Cannot measure INP at all, because INP needs real interactions; Lighthouse reports Total Blocking Time as a proxy.
The Chrome User Experience Report (CrUX) aggregates anonymised data from Chrome users who opted in, over a rolling 28-day window, at the 75th percentile.
Appears at the top of PageSpeed Insights, powers the Core Web Vitals report in Search Console, and is what Google uses as the ranking signal. Often worse than the lab number for the same page.
Only reported for pages and sites with enough traffic. Below that threshold there is no field data and no assessment at all.
The practical consequence is that a small clinic website, or a new site, will usually have no Core Web Vitals assessment for ranking purposes. The work still matters for visitors, but it is measured with lab tools, and any claims about it should say so.
A real case: our own site, and what the numbers do and do not show
In September 2026 we ran a performance pass on wonder-ads.com, our own website. The figures below are lab data from PageSpeed Insights on mobile, before and after. Our site does not have enough traffic for CrUX field data, so there is no real-user assessment to report; these are simulated loads on a throttled device, and they should be read as diagnostics, not as what visitors experienced.
wonder-ads.com, mobile, September 2026
Source: PageSpeed Insights, lab data (Lighthouse). No CrUX field data available for this site.
| Metric | Before | After |
|---|---|---|
| Performance score | 71 | 77 |
| Largest Contentful Paint | 4.9 s | 4.1 s |
| First Contentful Paint | 3.9 s | 3.6 s |
| Long tasks on the main thread | 5 | 1 |
| Cumulative Layout Shift | 0.002 | 0 |
Three changes: unused CSS removed with WP Rocket; animated GIFs resized and converted to WebP; the rest of the image library converted to WebP.
Where our LCP sits against the thresholds
Progress, not a pass: 4.1 s is still in the "poor" band. The remaining LCP lives in server response time and the render path of the hero section.
The honest reading is that this is progress, not a pass. LCP went from 4.9 seconds, which is in the "poor" band, to 4.1 seconds, which is still above the 4.0-second poor threshold and well above the 2.5-second "good" threshold. CLS was already excellent and is now perfect, which is good but was never the problem. The reduction in long tasks from five to one is the most useful change, because main-thread blocking is what drives INP in the field, but we cannot measure INP in the lab and cannot measure it in the field without traffic, so we do not know its real value. We publish this because a before-and-after that says "we fixed it" with a 4.1-second LCP would be false, and because reading your own numbers this way is exactly the skill the metric is meant to build.
How to improve Core Web Vitals, metric by metric
Because each metric has different causes, generic "speed up your site" advice wastes effort. Start with the metric that is failing.
To improve LCP, find the LCP element first; PageSpeed Insights names it. If it is an image, serve it in WebP or AVIF at the size it is displayed, do not lazy-load it, and consider preloading it. Then reduce what stands between the browser and that element: server response time (hosting and caching), render-blocking CSS and JavaScript, and web fonts loaded before the content. On WordPress sites built with page builders, unused CSS from the builder is frequently the largest single blocker, which is what we found on our own site.
To improve INP, reduce JavaScript work on the main thread. Audit third-party tags (chat widgets, tracking scripts, embedded maps and videos) and remove or defer the ones that are not essential; break long tasks into smaller ones; and check that interactions like opening a menu or submitting a form do not trigger heavy scripts. INP can only be verified with real users, so if you lack field data, use Total Blocking Time in the lab as the proxy and test interactions manually in Chrome DevTools.
To improve CLS, give every image, video and embed explicit width and height attributes, reserve space for ads, banners and cookie notices before they load, and use font-display settings that avoid a visible swap after text has rendered. CLS problems are usually cheap to fix once identified, which is why it is often the first metric to pass.
Tools for measuring Core Web Vitals
For a diagnosis of a single page, PageSpeed Insights is the starting point: it shows field data at the top when available and lab data below, with the specific elements and scripts responsible. Chrome DevTools, through the Performance and Lighthouse panels, allows deeper investigation and lets you test interactions for INP by hand.
For monitoring across a whole site, the Core Web Vitals report in Google Search Console groups URLs by status (good, needs improvement, poor) using CrUX field data, and is the closest thing to "what Google sees". It is only populated for sites with enough traffic. For sites that want their own real-user data regardless of traffic, the open-source web-vitals JavaScript library can send LCP, INP and CLS measurements to Google Analytics 4 or another tool, which gives field data for pages CrUX will never report on.
Frequently asked questions about Core Web Vitals
What are the Core Web Vitals in 2026?
Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). INP replaced First Input Delay (FID) on 12 March 2024.
What are the Core Web Vitals thresholds?
At the 75th percentile: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. Between those values and 4.0 s, 500 ms and 0.25 respectively is "needs improvement"; beyond is "poor".
Are Core Web Vitals a ranking factor?
Yes, as part of Google's page experience signals, but a light one. Content relevance and quality carry far more weight. They matter at least as much for conversion as for ranking.
What is the difference between lab and field data?
Lab data (Lighthouse, PageSpeed Insights) is a simulated single load, useful for diagnosis and available for any page. Field data (CrUX) is aggregated from real Chrome users over 28 days and is what Google uses for ranking. Small sites often have no field data.
Why does PageSpeed Insights show no field data for my site?
Because CrUX needs a minimum sample of real visits to report, and your site or page does not have enough traffic. Use lab data to find and fix problems, and consider collecting your own real-user data with the web-vitals library.
How do I improve Core Web Vitals on a WordPress site?
Convert images to WebP at display size, remove unused CSS and defer non-critical JavaScript (a caching plugin such as WP Rocket handles much of this), reduce third-party scripts, set dimensions on all media, and check hosting response time. Then measure again on the specific metric that was failing.
Fix what is measured, and measure what you fix
A slow, jumpy page loses patients and customers before it loses rankings, and Core Web Vitals are simply the agreed way to measure that. If your site is on an ageing theme or a page builder that cannot get under the thresholds without a fight, our web development team builds sites designed to pass them, with the measurements to show it. If you would rather know where you stand first, we will run the report on your pages, show you which metric is failing and why, and tell you, as honestly as we did about our own site, what fixing it would take.
