Core Web Vitals

Google's three-metric report card for how a page feels to real users: load speed, tap responsiveness, and visual stability.

the Google speed scorethe metrics Google grades you onweb vitalscore web vitelspage experience signalsthe green scores in PageSpeed InsightsLCP INP CLSthe three numbers Google cares about

See it

Live demo coming soon

What it is

Core Web Vitals are three metrics Google measures on real visits and grades: LCP (how fast the main content paints), INP (how fast the page answers a tap), and CLS (how much the layout jumps around). Pass marks are LCP under 2.5s, INP under 200ms, CLS under 0.1.

The scoring rule is the part people miss: you are judged at the 75th percentile of real Chrome visits over a rolling 28 day window, split by phone and desktop. Not your average, not your laptop on office wifi. That gap is why Lighthouse can show all green while Search Console still reports a failing URL group.

Gotcha: the lineup changes. FID was retired and replaced by INP in March 2024, and Google has swapped members before that. Treat the three current vitals as the scoreboard, not the diagnosis. TTFB, FCP, and long tasks are the numbers that tell you why a vital is red.

Ask AI for it

Audit this page against Core Web Vitals and fix only what the measurements blame. Measure LCP, INP, and CLS first, from field data if you have it and a throttled lab run if you do not, and name which of the three is failing and why. For LCP: split the number into TTFB, resource load delay, resource load duration, and render delay, then attack the largest phase. Preload only a candidate the browser discovers late (a CSS background image, an element injected after hydration) and leave anything already sitting in the initial HTML alone; put fetchpriority='high' on an eager LCP image and never lazy-load it. For INP: profile the slowest real interactions and split each into input delay, processing time, and presentation delay before touching a handler. For CLS: read the actual layout-shift entries and their sources rather than guessing, then reserve space for whatever is arriving late. Apply only evidence-backed changes, target LCP under 2.5s, INP under 200ms, and CLS under 0.1 at the 75th percentile on a mid-range Android, and report the before and after value for every metric you touched.

You might have meant

largest contentful paintinteraction to next paintcumulative layout shifttime to first bytereal user monitoring

Go deeper