--- title: "What are Core Web Vitals?" id: "534" type: "post" slug: "what-are-core-web-vitals" published_at: "2026-10-06T20:00:48+00:00" modified_at: "2026-10-06T20:00:48+00:00" url: "https://danielpazwp.com/what-are-core-web-vitals/" markdown_url: "https://danielpazwp.com/what-are-core-web-vitals.md" excerpt: "LCP, INP and CLS explained: what each metric measures, the p75 thresholds, where Google gets the field data and how to check your own site properly." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/category/performance/) 8 min read # What are Core Web Vitals? LCP, INP and CLS explained: what each metric measures, the p75 thresholds, where Google gets the field data and how to check your own site properly. Published **06/10/2026**8 min read [Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/) Core Web Vitals are three metrics Google uses to describe how a page feels to real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. Google measures them from real Chrome users and judges each one at the 75th percentile of page visits. A page is good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. INP replaced First Input Delay as the responsiveness metric in March 2024. That is the short answer. The longer one matters more, because most of the confusion I see in audits comes from people reading the right numbers from the wrong tool, or fixing a metric that was never the problem. This page explains what each metric measures, where the numbers come from and how to read them. If you run WordPress and want the fix order, go to [the complete guide to Core Web Vitals for WordPress](https://danielpazwp.com/core-web-vitals-wordpress/) after this. ## What are Core Web Vitals measuring, one by one? Each metric answers one question a visitor would ask without knowing the vocabulary. - LCP: when did the main content show up? It is the render time of the largest image or text block in the viewport. - INP: when I tapped or clicked, how long did the page take to respond on screen? It looks at the latency of interactions across the whole visit and reports one of the slowest. - CLS: did things jump around while I was reading? It adds up unexpected layout shifts, grouped into windows, and reports the largest burst. Notice what is missing. Total page weight, number of requests and the Lighthouse score are not Core Web Vitals. They can explain a bad metric, but Google does not assess them. ## What are the thresholds for good, needs improvement and poor? Google publishes three bands for each metric. The value that counts is the 75th percentile of real visits, so three out of four visits need to be at or below the good line for the page to pass that metric. | Metric | What it measures | Good | Needs improvement | Poor | | --- | --- | --- | --- | --- | | LCP | Loading of the main content | 2.5 s or less | Above 2.5 s up to 4 s | Above 4 s | | INP | Responsiveness to input | 200 ms or less | Above 200 ms up to 500 ms | Above 500 ms | | CLS | Visual stability | 0.1 or less | Above 0.1 up to 0.25 | Above 0.25 | The 75th percentile choice is deliberate. An average hides the visitors on slow phones and bad connections. The p75 forces you to care about a big slice of them without letting a handful of extreme outliers decide the result. ## Where does Google get Core Web Vitals data? From the Chrome User Experience Report, usually called CrUX. It collects performance data from Chrome users who have opted in to sharing usage statistics, then aggregates it by URL and by origin over a rolling 28-day window. This is field data: real devices, real networks, real people scrolling and tapping. You see CrUX numbers in a few places: - PageSpeed Insights, in the section at the top labeled with the Core Web Vitals assessment. - The Core Web Vitals report in Google Search Console, which groups similar URLs together. - The CrUX API and the public CrUX dataset in BigQuery, for anyone who wants raw numbers. When a page does not get enough Chrome traffic, CrUX has no URL-level data for it. PageSpeed Insights then falls back to the origin, meaning the whole site, and Search Console groups the URL with similar pages. Small sites often have origin data only. That is normal and it still tells you a lot. The 28-day window has one practical effect people forget: after you deploy a fix, the field numbers move gradually over about four weeks. Nothing is broken if the report looks the same the next morning. ## Field data vs lab data: which one counts? Field data counts for the assessment. Lab data is what you get when a tool like Lighthouse loads the page once, on one emulated device, with one simulated network. Lab runs are repeatable and great for debugging, but they are a single synthetic visit, not your audience. INP shows the gap clearly. A lab test has no real user clicking, so Lighthouse cannot report INP during a normal page load. It reports Total Blocking Time instead, which points at the same problem (long JavaScript tasks on the main thread) without being the same number. I wrote more about this split in [field data vs lab data for Core Web Vitals](https://danielpazwp.com/core-web-vitals-field-data-vs-lab-data/) , and the two Google tools that show each kind are compared in [PageSpeed Insights vs Lighthouse](https://danielpazwp.com/pagespeed-insights-vs-lighthouse/) . My rule in audits: field data tells you whether there is a problem and on which templates. Lab data and DevTools tell you why. ## Why did INP replace FID? First Input Delay measured only the delay before the browser started handling the first interaction. It ignored how long the handler itself ran, ignored the time to paint the result and ignored every interaction after the first. Most sites passed it easily, which made it a weak signal. INP covers the full cycle of an interaction (input delay, processing time and the delay until the next frame is painted) and it looks at interactions throughout the visit. Google made it a Core Web Vital in March 2024 and retired FID. On WordPress, this is the metric that exposes heavy page builders, plugin scripts that run on every click and third-party tags. The details are in [fixing INP in WordPress](https://danielpazwp.com/inp-wordpress/) . ## Are Core Web Vitals the same on mobile and desktop? The thresholds are the same. The data is separate. CrUX reports phone and desktop visits independently, and both PageSpeed Insights and Search Console show them on separate tabs. In practice the mobile numbers are almost always worse, because phones have slower CPUs and the network varies more. A WordPress site can pass on desktop and fail on mobile with the same HTML. When a client tells me “our Core Web Vitals are fine”, the first thing I check is which tab they were looking at. ## What usually breaks each metric? I see the same patterns over and over. They are not the only causes, but they are where I look first. - LCP: slow server response because there is no page cache, a hero or featured image that is lazy-loaded, images served at desktop size to phones, and render-blocking CSS and JavaScript. See [LCP in WordPress](https://danielpazwp.com/lcp-wordpress/) . - INP: too much JavaScript on the main thread, from builders, sliders, chat widgets, analytics and ad tags, plus very large DOMs. - CLS: images and embeds without width and height, web fonts that swap with different metrics, cookie banners and promo bars injected above the content, and ads with no reserved space. See [CLS in WordPress](https://danielpazwp.com/cls-wordpress/) . TTFB deserves a mention even though it is not a Core Web Vital. A slow first byte delays everything after it, so it drags LCP down directly. Google’s guidance treats 0.8 seconds or less as good. If your server response is slow, start there. ## How do I check my own site’s Core Web Vitals? A simple order that works on any site: 1. Open PageSpeed Insights, enter a key URL and read the field data section first. Check both the URL and the origin view, on mobile and desktop. 2. Open Search Console, go to the Core Web Vitals report and see which URL groups fail and on which metric. 3. Pick the worst template, open it in Chrome DevTools and use the Performance panel to find the cause. 4. Only then run Lighthouse to confirm a fix in the lab before you deploy it. If the site has little traffic and no CrUX data, add real user monitoring. The web-vitals JavaScript library from Google reports the same metrics from your own visitors, and its attribution build tells you which element or interaction caused the number. ## Frequently asked questions ### How many Core Web Vitals are there? Three: LCP, INP and CLS. Google can change the set over time, and it did once when INP replaced FID in March 2024. Other metrics such as TTFB and First Contentful Paint are useful for diagnosis but are not Core Web Vitals. ### Do I need a perfect PageSpeed score to pass? No. The Lighthouse performance score is a lab number and is not part of the assessment. A page can score in the 60s and pass on field data, or score 95 and fail because real visitors on slow phones see a late LCP. ### How long until a fix shows up in the data? CrUX uses a 28-day rolling window, so expect the field numbers to shift over roughly four weeks after the change goes live. Lab tools show the effect immediately, which is why I use them to confirm fixes and field data to confirm results. If you want someone to read your field data, find the templates that fail and tell you what to fix first, that is the work I do as a [Core Web Vitals expert](https://danielpazwp.com/core-web-vitals-expert/) . [Work with Daniel](https://danielpazwp.com/#book) [More in Performance](https://danielpazwp.com/category/performance/) [About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/) ## Related articles [All articles](https://danielpazwp.com/blog/) [Performance Oct 2026PageSpeed Insights vs Lighthouse: field vs lab data](https://danielpazwp.com/pagespeed-insights-vs-lighthouse/) [Performance Oct 2026How to speed up WordPress: an engineer’s guide](https://danielpazwp.com/speed-up-wordpress/) [Performance Oct 2026Core Web Vitals assessment failed: what to do](https://danielpazwp.com/core-web-vitals-assessment-failed/)