A good website speed means a page passes all three of Google’s Core Web Vitals for real visitors: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) within 200 milliseconds, and Cumulative Layout Shift (CLS) of 0.1 or less. Google judges each threshold at the 75th percentile of visits, so at least three out of four page loads have to meet it.
That answer replaced the older rule of thumb, which treated speed as a single load time in seconds. One load-time number can’t tell you whether a page appeared quickly, responded quickly when someone tapped a button, or stayed still while it loaded. Core Web Vitals measure those three things separately, because visitors notice each of them separately.
The three Core Web Vitals thresholds
Google publishes three bands for each metric. A page needs to reach “good” on all three to pass.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: how long the largest visible element takes to appear | 2.5 s or less | 2.5 s to 4.0 s | More than 4.0 s |
| Interaction to Next Paint (INP) | Responsiveness: how quickly the page reacts to clicks, taps and typing | 200 ms or less | 200 ms to 500 ms | More than 500 ms |
| Cumulative Layout Shift (CLS) | Visual stability: how much visible content moves unexpectedly | 0.1 or less | 0.1 to 0.25 | More than 0.25 |
LCP is the closest thing to the old idea of load time. It marks the moment the main content, usually a hero image or headline block, finishes rendering. It answers the visitor’s first question: has the page actually arrived?
INP covers what happens after the page appears. It records how long the page takes to respond to interactions across the whole visit and reports one of the slowest. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it’s stricter, because FID only measured the first interaction.
CLS scores how much content jumps around. It’s the reason a visitor taps the wrong link when an image or banner loads late and pushes the text down.
Why the 75th percentile matters
Real visitors arrive on different devices, networks and locations, so the same page loads differently for each of them. Google assesses each metric at the 75th percentile so a page can’t pass on its fastest visits alone. If a quarter of your visitors are on older phones or slow connections, those visits decide whether you pass. That’s also why a page can feel fast on your office laptop and still fail.
Lab scores versus field data
Many teams treat a Lighthouse score as their speed target. Lighthouse runs a lab test, loading the page once on a simulated device and connection, and turns the results into a score from 0 to 100. Under Lighthouse’s scoring bands, 90 to 100 is good, 50 to 89 needs improvement and 0 to 49 is poor.
A lab score is useful for debugging because it’s repeatable and shows what’s slowing the page down. It isn’t what Google uses to assess page experience in Search. That assessment comes from field data, collected from real Chrome users in the Chrome UX Report (CrUX). The two can disagree. A page can score 95 in Lighthouse and still fail INP in the field, because a lab run doesn’t click through the page the way people do. Use lab scores to find problems and field data to judge whether you’ve fixed them.
How to measure your website speed
Three free sources cover most needs:
- PageSpeed Insights shows field data for a URL or the whole origin where enough real-user data exists, plus a Lighthouse lab test, for mobile and desktop.
- Search Console’s Core Web Vitals report groups similar URLs together and shows which groups pass or fail on each metric.
- The Chrome UX Report provides the underlying field data for deeper analysis and trend tracking.
On a large site, measure templates rather than individual pages. Pages built on the same template usually share the same speed problems, so one product page, article page or landing page template tells you more than a hundred spot checks. Check mobile results first, since slower devices and networks are where most pages fail.
Does website speed affect rankings?
Yes, but less than the attention it gets suggests. Core Web Vitals are part of how Google’s ranking systems assess page experience. Google’s guidance on page experience in Google Search is explicit that good Core Web Vitals results don’t guarantee top rankings, and that relevant content comes first. Speed tends to matter most when several pages answer a query equally well.
The larger payoff is what happens after the click. A page that appears quickly, responds instantly and stays still is easier to read, easier to use and less likely to lose the visitor before they act.
What to do if your website is too slow
Find the metric that fails, then fix its causes. Slow LCP usually traces to images and server response, poor INP to JavaScript, and high CLS to missing image dimensions and late-loading content. The step-by-step fixes for each are in our guide on how to increase website speed. Once a site passes, continuous performance monitoring keeps new releases and scripts from pulling it back under the thresholds. Teams running accessibility programs can manage both together, an approach covered in treating Core Web Vitals and WCAG as one system.