What Core Web Vitals are and why field data matters

Core Web Vitals (CWV) are Google's official ranking signals for page experience. Three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP, replaced FID in March 2024), and Cumulative Layout Shift (CLS). All three come from the Chrome User Experience Report (CrUX), which aggregates real-user data from Chrome users who opted into syncing browsing history.

Lab metrics (Lighthouse, PageSpeed) are useful as a starting point but Google ranks based on field data only. This checker fetches CrUX data via the Web Vitals API and reports the 75th percentile, the threshold Google uses to grade your site.

The three core metrics and their thresholds

LCP measures loading speed via when the largest visible element renders. Good is under 2.5 seconds at p75. Needs improvement is 2.5 to 4 seconds. Poor is over 4 seconds. The largest element is usually a hero image, video poster, or H1.

INP measures interactivity. Good is under 200ms at p75. Needs improvement is 200ms to 500ms. Poor is over 500ms. INP captures the worst-case interaction delay across the page session, not just the first interaction. Heavy JavaScript handlers, layout thrashing, and main-thread blocks all hurt INP.

CLS measures visual stability. Good is under 0.1 at p75. Needs improvement is 0.1 to 0.25. Poor is over 0.25. CLS spikes from images and ads loading without reserved space, web fonts triggering reflows, and dynamically inserted content above existing content.

Why p75 instead of average

Google uses the 75th percentile because averages hide the long tail. Your p50 (median) might be 1.8 seconds LCP, your p75 might be 4.2 seconds. The latter is what matters because it represents the worse 25% of users; ignoring them pushes you into the "poor" bucket even though most of your users are fine.

This means optimizing for the slowest users matters most. A 5% improvement on the worst-performing 25% of page loads moves your p75 more than a 30% improvement on the median.

Core Web Vitals and AI search

Core Web Vitals started as a page-experience ranking signal, but their relevance has widened as search has shifted toward AI-generated answers. The same engineering that produces good vitals, content delivered fast in the initial response, a stable layout, and a main thread that is not jammed with JavaScript, also produces a page that AI crawlers can fetch, render, and extract cleanly. A page with poor LCP because its content arrives late via client-side rendering is the same page an AI parser may read as nearly empty.

You will not find an "Core Web Vitals" knob inside AI Overviews, and Google has not claimed vitals decide AI citations. But the pages that get cited tend to be the ones that ship real, structured content quickly and stably, which is exactly what passing these three metrics forces you to do. Optimize the vitals for users and you incidentally build the kind of page AI systems prefer to quote.

When CrUX has no data

CrUX requires enough real-user traffic to produce reliable data. Low-traffic pages, new sites, and pages behind authentication will show "no data" or fall back to origin-level data (the average across all URLs on the domain).

For pre-launch testing or low-traffic pages, use lab metrics from the PageSpeed Test and INP simulation tools. Lab and field data diverge by design (lab is one device on one network; field is thousands of real users on varied conditions), so do not panic if they show different numbers. Optimize the lab metrics with the understanding that field data will follow over weeks.

Common fixes for each metric

For LCP: preload the hero image, serve modern image formats (WebP, AVIF), reduce server response time, eliminate render- blocking resources in the critical path. Specifically the priority=high attribute on hero images often takes a second off LCP for content-heavy pages.

For INP: reduce the size and complexity of event handlers, avoid layout-triggering operations during interactions, debounce or throttle expensive callbacks, move heavy work into Web Workers. Long tasks (over 50ms) on the main thread are the prime suspect.

For CLS: always specify width and height on images and videos, reserve space for ads and embeds with min-height, use font- display: swap or optional with size-adjust descriptors, avoid injecting content above existing content (dialogs, banners, toolbars).

How to read what this checker returns

The checker reports each metric at the 75th percentile alongside a verdict of good, needs improvement, or poor. Read the verdict, but also read which level of data it came from. CrUX serves data at two granularities: URL-level (the exact page you tested) and origin-level (every page on the domain blended together). If you see origin-level data, the number describes your whole site's average experience, not this specific page. A fast page on a slow domain can still show poor origin numbers.

You may also see a separate distribution: the share of loads that were good, needs-improvement, and poor. This is more useful than the single p75 figure because it shows the shape of the problem. If 70% of LCP loads are good but 20% are poor, you have a specific slow segment (a heavy template, a slow region, a particular device class) dragging the p75 over the line rather than a uniformly slow site. Fixing a segment is a different job than fixing everything.

Do not confuse this with the lab numbers from a PageSpeed or Lighthouse run. Lab CLS is measured over the page load only; field CLS accumulates across the entire time a real user has the page open, including shifts triggered by scrolling and interaction. That is why a page can show 0.00 CLS in the lab and still fail in the field. The field number is the one Google ranks on; treat the lab number as a debugging aid, not a verdict.

INP is the metric people underestimate

INP replaced First Input Delay in March 2024, and it is a much harder test. FID only measured the delay before the browser started processing your first interaction. INP measures the full time from interaction to the next visual update, across every interaction in the session, and reports near the worst one. A page that felt fine under FID can quietly fail INP because FID never looked at how long your handlers actually took to run and repaint.

The usual cause is too much JavaScript executing on the main thread when the user taps or types. Hydration of large client-side frameworks, expensive React re-renders, synchronous analytics calls fired on click, and layout reads that force the browser to recalculate styles mid-interaction all push INP up. Because INP is a field-only metric, the only honest way to know your score is data like this from real users; a local test on a fast laptop will almost always look better than reality.

Common mistakes when acting on the data

The most common mistake is reacting to a single bad reading. CrUX is a 28-day rolling window, so today's number already reflects the last four weeks averaged together. A deploy you shipped yesterday is barely represented yet. Make a change and wait; do not pull it because the number has not moved in two days.

The second mistake is optimizing the median instead of the tail. Because Google grades at p75, the slowest quarter of your loads decides your fate. Developers test on fast devices and fast networks, see good numbers, and never experience what their p75 users feel. Throttle your own browser to a mid-tier mobile device and a slow network before you decide a page is fine.

The third mistake is treating the three metrics as one problem. LCP, INP, and CLS have almost nothing in common: LCP is about how fast the main content paints, INP is about how responsive the page is to input, and CLS is about whether things move around unexpectedly. A fix for one rarely helps another, and you must pass all three to count as a good URL. Diagnose and fix them separately.

Tracking improvements over time

CrUX data has a 28-day rolling window. Improvements take weeks to show up. Make a fix, then check back at weeks 2, 4, and 8 to see the trend. Search Console's Core Web Vitals report shows the same data with URL-grouping by template, which helps identify which page types need attention.

Page experience is a weak ranking signal but a real one. More importantly, slow pages have higher bounce rates and lower engagement, which are stronger ranking signals indirectly. Fast sites just rank better, even if you cannot point to one single algorithm change as the reason.

When you report progress to stakeholders, frame it around the good-URL percentage rather than the raw metric values. Google's own reporting groups URLs into good, needs-improvement, and poor buckets, and the metric that matters commercially is what share of your important pages sit in the good bucket and stay there. A single p75 number going from 2.6s to 2.4s is hard to celebrate; moving from 40% to 80% of your product pages passing all three vitals is a story everyone understands, and it maps directly to the experience real customers are having. Set that percentage as the goal, track it monthly, and treat the individual metrics as the levers you pull to move it.