What Core Web Vitals actually measure
Core Web Vitals are three measurements Google uses to describe how a page feels to use: how quickly the main content appears, how quickly the page responds when someone clicks or taps something, and how much the layout jumps around while it loads. Each has a name and a threshold Google treats as "good".
- Largest Contentful Paint (LCP): the time it takes for the biggest visible element, usually a hero image or heading, to render. Google's threshold for "good" is 2.5 seconds or less.
- Interaction to Next Paint (INP): how long the browser takes to respond after someone interacts with the page, measured across the whole visit. This replaced First Input Delay (FID) in March 2024, and it catches sluggishness that FID often missed.
- Cumulative Layout Shift (CLS): a score for how much visible content moves around unexpectedly, usually caused by images or ads loading without reserved space.
A Core Web Vitals checker runs a page against these three thresholds and tells you which ones it clears and which it does not. That is the whole job of the tool: turn a page load into three numbers you can act on.
Why these numbers matter beyond a Lighthouse score
Google has confirmed Core Web Vitals as part of its page experience signals, though their weight in rankings is small compared with content relevance and links. The more immediate effect is on the reader in front of the page: a slow LCP means people wait and some leave before they see anything, and a high CLS means someone taps a button just as it shifts and hits the wrong thing instead.
That distinction matters when you are deciding how much effort to put into fixing a score. A page ranking well on relevant terms with a poor CLS is probably losing conversions or engagement it would otherwise keep, which is a business reason to fix it independent of any ranking effect.
How a Core Web Vitals checker gets its numbers
There are two different sources behind any Core Web Vitals result, and mixing them up is where most confusion starts.
Field data
Field data comes from real Chrome users who have visited the page, aggregated by Google into the Chrome UX Report (CrUX). It reflects actual devices, actual connections, and actual browsing conditions, but it only exists for pages with enough Chrome traffic to be statistically meaningful. A new page or a low-traffic page will not have any.
Lab data
Lab data comes from a single simulated page load under controlled conditions, which is what most on-demand checkers, including this one, produce. It is useful for diagnosing a specific page quickly and consistently, but a lab test is one snapshot on one connection profile. It can score a page as good or fail one that real users experience differently on their own network and device, so the result from any checker is a reading.
Use our Core Web Vitals checker to see how this applies to your situation. Running the same URL more than once, and on both mobile and desktop settings, gives a better sense of whether a result is stable or a one-off.
Common mistakes when reading the results
- Testing only the homepage. A blog post with a hero image, an embedded video, and third-party comments code will usually score worse than the homepage and is far more likely to be what a searcher actually lands on.
- Chasing a perfect lab score. A page can pass every Core Web Vitals threshold in the lab and still feel sluggish to real users on a mid-range Android phone over 4G, because the lab test rarely matches that exact combination of device and connection.
- Fixing CLS by removing everything that moves. Stripping ads or embeds to kill layout shift often costs more in revenue or content value than the shift itself was costing in user experience. Reserving space for the element with a fixed width and height usually solves it without removing anything.
- Treating the three metrics as equally urgent. A page failing LCP by a wide margin needs attention before a page marginally over the INP threshold; not every red number deserves the same response time.
- Ignoring third-party scripts. Analytics tags, chat widgets, and ad scripts are a common cause of poor INP, and they are often invisible in a quick look at the page's own code because they load from someone else's server.
Practical steps for improving each metric
Improving LCP
Find the specific element the checker flags as the largest contentful item, because optimising the wrong image or block does nothing for the score. Serving that image in a modern format at the size it is actually displayed, and loading it early, accounts for most of the gain in practice.
Improving INP
Break up long JavaScript tasks so the browser can respond to a click in between them, and audit third-party scripts for ones doing more work than the page needs. Removing or deferring a single unnecessary tracking script is often the single biggest INP improvement available on a page.
Improving CLS
Set explicit width and height attributes on images and embeds so the browser reserves the right amount of space before the content arrives. Web fonts that load late and shift text are a common overlooked cause, and specifying a fallback font that matches the final font's size avoids the jump.
When to reach for a Core Web Vitals checker, and when to reach for something else
A checker is the right tool for a quick diagnosis on a specific URL, particularly after a template change or before a launch. For checking Core Web Vitals across an entire site at once, a crawler that can visit every URL and report performance data in bulk is a better fit; see how the options compare on Technical SEO Crawlers Compared.
Performance sits alongside the other technical checks worth running on a page, including whether it is indexable and how it is described in search results. Pairing a Core Web Vitals result with a look at the page's meta tags gives a fuller picture of how the page is likely to perform in search.
Whichever tool produces the numbers, treat the result as a reading taken at one moment: connections, devices, and third-party scripts all change what a real visitor experiences, and no single test captures all of that at once.