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.

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).

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.