How to check your website's Core Web Vitals

What the three metrics actually measure

Largest Contentful Paint (LCP) times how long the single biggest visible element on the page takes to render fully on screen - in practice this is usually a hero image, a large heading, or a background graphic sitting above the fold. It matters because it is the closest proxy Google has found for what a visitor experiences as "the page has loaded": not when every last background request finishes, but when the content someone actually came for is visibly there and readable. Interaction to Next Paint (INP) measures something different: the gap between a person clicking a button, opening a menu, or typing into a field, and the browser visibly responding. A slow INP is what makes a site feel broken even though it technically loaded fine - the tap registers, but nothing happens for half a second, so the visitor taps again or gives up. Cumulative Layout Shift (CLS) scores how much content jumps around unexpectedly as the page renders, the classic case being a button that shifts position just as a thumb goes to tap it, landing the tap on an ad instead.

Where to check them for free

PageSpeed Insights (pagespeed.web.dev) is the simplest starting point: paste in a URL and it returns two different reports on one page. The first is a lab test, run instantly on Google's own servers under a simulated connection. The second, shown only for sites with enough traffic, is real field data pulled from the Chrome User Experience Report (CrUX), the anonymised dataset Google builds from actual Chrome users who opted in to sharing performance data. Search Console's Core Web Vitals report works at a different scale: instead of testing one URL, it groups every page Google has field data for into pass or fail buckets by template. That matters more than any single-page score, because it shows the pattern across your whole site rather than one symptom of it.

Field data and lab data measure different things

Lab data is a single simulated test run on Google's servers under controlled conditions - useful for debugging because it is repeatable and instant, but easy to make look better than reality, since it usually runs over a fast, uncongested connection with nothing else competing for bandwidth. Field data is the opposite: the real, messy experience of your actual visitors, on whatever device and network they happen to be using, averaged over a rolling 28-day window and typically assessed at the 75th percentile, meaning three out of four real visits need to meet a threshold before a page counts as good. Google's ranking systems use field data, not lab data, for exactly this reason - it reflects what real people encounter, not what a developer sees on office fibre. If your lab score looks excellent but the field data for the same page is poor, trust the field data; the gap usually means real visitors are on slower connections or older phones your test never simulated.

What counts as good

Google's published thresholds are: LCP under 2.5 seconds is good, up to 4 seconds needs improvement, and beyond that is poor. INP under 200 milliseconds is good, up to 500 milliseconds needs improvement, and beyond that is poor. CLS under 0.1 is good, up to 0.25 needs improvement, and beyond that is poor. The part people miss is that a page needs all three metrics in the good range at once to pass the overall assessment - there is no averaging and no partial credit. A page with an excellent 1.8 second LCP and a near-perfect CLS of 0.05 still fails overall if its INP sits at 350 milliseconds, because one metric in the needs-improvement or poor range drags the whole page down regardless of how strong the other two are. That all-or-nothing structure is deliberate: a page that loads fast but responds slowly to clicks is still a bad experience.

The fixes that move the needle most

For LCP, the two most common culprits are an oversized, uncompressed hero image and render-blocking scripts that delay the browser from starting to paint the page at all - compressing that image and making sure nothing critical sits behind a script that has to load and execute first typically produces the biggest single improvement. For INP, the usual offenders are third-party scripts that attach listeners across the whole page and then run expensive code on the main thread every time someone clicks anything: chat widgets, heatmap trackers, and analytics tags are frequent culprits, and removing or deferring the ones you don't strictly need often fixes INP faster than any code optimisation. For CLS, the fix is usually mechanical: set explicit width and height on every image and ad slot so the browser reserves the space before the file loads, instead of the layout jumping once it arrives.

Checking it across your whole site, not one page

A single-page test only tells you about the one URL you pasted in, and most real sites don't fail Core Web Vitals uniformly - they fail on specific templates. A common pattern is a homepage that scores well because someone optimised it once, sitting alongside product pages loaded with third-party embeds, or a blog template full of unoptimised images uploaded straight from a phone, each dragging down a different metric for a different reason. Testing only the homepage and assuming the rest of the site follows is one of the most common ways a genuine vitals problem goes unnoticed for months. AuditHQ's Technical suite pulls real Core Web Vitals field data as part of the free scan and breaks it down by page and by metric, so instead of a single pass or fail verdict you see exactly which template is failing and which of the three metrics is responsible.

Frequently asked questions