Core Web Vitals

Core Web Vitals are Google's attempt to put a number on something fuzzy: how a page actually feels when a human loads it. Instead of asking whether your page is technically valid, they ask whether it loads fast, responds quickly to a tap, and holds still while it draws. After 20 years of watching Google tighten the screws on quality, I can tell you this is the cleanest set of performance signals they have ever shipped, because every one of them maps to a frustration a real person feels with their own eyes and thumb. What makes them different from the old speed metrics is that they are user-centric by design. Google did not pick them because they are easy to measure. It picked them because each one correlates with whether a visitor stays or bounces. You can no longer wave around a single load-time number and call it a day. You have to think about three distinct moments in the page lifecycle and earn a passing grade on all of them.

The three metrics that count

There are three Core Web Vitals, and each one targets a different way a page can frustrate a visitor. You will see them everywhere in PageSpeed Insights, Search Console, and Chrome's own tooling, so it pays to know what each one is actually measuring. Think of them as three separate questions about the same page: did it load, did it respond, and did it stay put? Each question has its own metric, its own typical causes, and its own set of fixes, which is why I treat them as three projects rather than one.

• Largest Contentful Paint (LCP) measures loading. It marks the moment the biggest visible element, usually a hero image or headline, finishes painting.
• Interaction to Next Paint (INP) measures responsiveness. It watches how quickly the page reacts after you tap, click, or type.
• Cumulative Layout Shift (CLS) measures visual stability. It tracks how much the layout jumps around while content loads in.

This brings up the distinction that trips up most people: field data versus lab data. Lab data is a single synthetic run in a controlled environment, useful for debugging. Field data is what Google actually counts for ranking, pulled from real Chrome users in the Chrome User Experience Report. Your lab score can look great while your field data quietly fails, because real users are on older phones and worse networks than your laptop. I have watched teams celebrate a green lab score for weeks while their actual visitors, on mid-range Android phones over spotty connections, had a completely different experience. The practical takeaway is to trust the field data for decisions and use the lab data for diagnosis. When Search Console says a group of URLs is failing, that judgment comes from real visitors and it is the one that affects you. When you open PageSpeed Insights to figure out why, the lab diagnostics point you at the specific elements and scripts to fix.

1. 1Open Search Console and find the Core Web Vitals report to see which URL groups are failing on mobile and desktop.
2. 2Pull the failing template into PageSpeed Insights and read the field data section first, then the lab diagnostics.
3. 3Fix the single worst metric for that template, deploy, and wait for the field data window to refresh before judging the result.