Somebody has sent you a report with a number on it, and the number is red. Maybe your developer mentioned Core Web Vitals, or an SEO tool emailed a warning. Most of the alarm those reports cause is misplaced, because the number people react to usually isn’t the one Google actually uses.
Three questions about one page load
Core Web Vitals are Google’s attempt to score what a page feels like to use rather than what it weighs. There are three, and each marks a moment a real person notices.
LCP, or Largest Contentful Paint, asks when the page looked ready. It times the moment the biggest thing in view, usually a headline or a hero image, finished drawing. That’s roughly when a visitor stops staring at a blank rectangle. Google calls 2.5 seconds or less good, and worse than 4 seconds poor.
INP, or Interaction to Next Paint, asks how long the page took to react when you tapped something. Not how long it took to finish the job, just how long before it acknowledged you at all. If you’ve ever tapped a menu button twice because the first tap seemed to do nothing, that’s this. Google puts good at 200 milliseconds or less, poor beyond 500.
CLS, or Cumulative Layout Shift, asks how much the page moved around while it loaded. The classic offender is an ad or image that turns up late and shoves the paragraph you were reading down the screen. That’s how people end up tapping the wrong thing. Google calls 0.1 or less good, and worse than 0.25 poor. It’s a ratio rather than a length of time, so it isn’t measured in seconds.
The number you were sent is probably the wrong number
There are two ways to measure a site and they disagree constantly. Lab data comes from a tool loading your page once, on demand, on a simulated device and connection; Lighthouse and the score out of 100 in your browser are lab data. Field data comes from real Chrome users visiting your real site, collected over the preceding month. Google uses field data for the assessment, so that’s what any search-related effect rests on.
Which means the round score out of 100 that everybody screenshots isn’t your Core Web Vitals at all. It’s a weighted composite of lab measurements, handy for diagnosis and a poor thing to manage toward, and it moves several points between runs on a site nobody has touched. Budgets get spent pushing it to 100. No visitor ever experiences the difference.
Field data also gets reported at the 75th percentile, so three quarters of your visits were at least that good. An average would let one fast visit cancel out a slow one; this deliberately doesn’t. A page can feel quick on your phone on office wifi and still fail, because a quarter of your customers are on worse connections than yours.
How much does this matter for search?
Some, though less than the tools sending you warnings would like you to believe. Page experience is a real ranking input, and Google has been open that it’s a modest one. Shaving 200 milliseconds won’t lift you above a better answer.
Where it counts is between pages that are otherwise comparable, and in the part no ranking report will show you: people give up on slow pages and go elsewhere. That second effect is the stronger argument for doing the work, and it doesn’t require guessing at an algorithm. Unless the numbers are dramatic, a failing assessment is something to schedule.
Reading the report
Look at mobile first. Most reports default to it, most of your visitors are on it, and it’s where sites fail. A desktop pass with a mobile failure is a failure.
Check your top few pages, not just the home page. Metrics are per-page. Landing and product pages often carry more scripts and images than the home page, and they’re frequently where people actually arrive from search.
Read the three metrics separately. They have different causes and different fixes. Bad CLS usually traces to images and embeds given no reserved space, often a small job; bad LCP tends to mean server response times and heavy media, usually a larger one. A single pass-or-fail verdict throws that distinction away.
Ignore the audit list until someone technical is looking at it. The wall of suggestions underneath the score is generated advice, sorted by estimated savings, written without any knowledge of your site. Some of it is good. Some of it will break a page if followed literally, and the report gives you no way to tell which is which.
What the work looks like
Once you know which metric is failing and where, the job itself is ordinary: image sizes, what has to load before the page can draw anything, how long the server takes to start answering. We run Lighthouse-based audits with an in-house analyzer, which returns a short prioritized list rather than the full wall, and we’ve written about the causes that come up most often. Availability is a separate question from speed, and monitoring answers that one.
Performance audits are part of the hosting and site care we run: sites we look after get audited, and the fixes land as maintenance instead of a crisis project.