The main content of a page should appear within 2.5 seconds, and that should hold for at least 75% of real visits, measured separately on mobile and desktop. That is Google's "good" threshold for Largest Contentful Paint (LCP). Below are the other thresholds Google publishes, what the most quoted speed studies measured, and where to start when a page misses the target.
Google's speed thresholds
Google doesn't publish one "load time" target. It uses separate metrics for loading, responsiveness and visual stability, each with a published threshold from web.dev:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the main content is visible | 2.5 s or less | 2.5 to 4.0 s | Over 4.0 s |
| INP | How fast the page reacts to clicks, taps and keys | 200 ms or less | 200 to 500 ms | Over 500 ms |
| CLS | How much the layout jumps while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
| FCP | When the first text or image appears | 1.8 s or less | 1.8 to 3.0 s | Over 3.0 s |
| TTFB | When the first byte of HTML arrives | 0.8 s or less | 0.8 to 1.8 s | Over 1.8 s |
LCP, INP and CLS are the three Core Web Vitals. A page passes when it meets all three at the 75th percentile of page loads. Our guide to how Google scores Core Web Vitals explains that rule and which visits it counts. FCP and TTFB are supporting metrics. web.dev states that TTFB isn't a Core Web Vitals metric, so a slow TTFB matters mainly because it pushes LCP back.
Does page speed affect Google rankings?
Yes, within limits. Google's page experience documentation says "Core Web Vitals are used by our ranking systems." The same page says good scores don't guarantee top rankings, and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."
In practice, a faster page won't outrank a more useful one. Speed helps most when several results answer the query equally well. If a page is missing from Google altogether, check crawling and indexing before speed; an audit of crawling, indexing and rendering covers both.
What the speed studies measured
Here is what four widely quoted studies found, in their own terms:
- Akamai's 2017 State of Online Retail Performance report covered roughly 10 billion visits to retail sites. A 100-millisecond delay hurt conversion rates by up to 7%: 7.1% on smartphones, 3.8% on tablets and 2.4% on desktop. Conversion rates peaked at a median load time of 1.8 s on desktop, 1.9 s on tablets and 2.7 s on mobile.
- Google/SOASTA research from 2017, as reported in Google's Milliseconds Make Millions report, found that the probability of a bounce on mobile rises 32% as load time goes from 1 s to 3 s, 90% at 5 s, 106% at 6 s and 123% at 10 s.
- Milliseconds Make Millions itself (Google, Deloitte Digital and Fifty-Five, 2020) analysed mobile data from 37 brands over four weeks. A 0.1 s speed improvement went with 8.4% more conversions on retail sites and 10.1% more on travel sites.
- In a 2021 Vodafone A/B test published on web.dev, a 31% improvement in LCP increased sales by 8%.
The first three are observational, so they show how speed and conversions moved together, not how much revenue your own site would gain. The Vodafone result comes from a controlled test, which makes it the strongest of the four. Use these figures as direction, not as a forecast.
Where to start on a slow page
Start with LCP, the loading metric. web.dev's LCP guide splits LCP into four parts and suggests a rough share for each. Measure which part is out of proportion and fix that one first.
| LCP part | Rough target share | What usually fixes it |
|---|---|---|
| Time to first byte | About 40% | Page caching, a CDN in front of HTML, faster database queries |
| Resource load delay | Under 10% | Put the LCP image in the HTML, never lazy-load it, add fetchpriority="high" |
| Resource load duration | About 40% | Right-sized images, modern formats such as WebP or AVIF, compression |
| Element render delay | Under 10% | Smaller CSS, async or defer on scripts in the head, shorter main-thread tasks |
The guide also notes that an image loaded from a CSS background, injected by JavaScript or hidden behind a data-src attribute can't be found early by the browser, so it starts downloading late.
For the other two Core Web Vitals:
- For INP, break long JavaScript tasks into smaller ones so the browser can respond to input between them.
- For CLS, set
widthandheighton images and reserve space for ads and embeds before they load.
When TTFB is the problem, look at the server first: missing database indexes, N+1 queries or a CDN that isn't caching your pages. Our post on the server-side bottlenecks behind a slow site covers how to find each one.
How to test your site
- Run your URL through PageSpeed Insights. It shows field data from real Chrome users over the previous 28 days, plus a Lighthouse lab test.
- Read the field data first. That is what your visitors experienced, and it's the data Google's thresholds apply to. New or low-traffic pages may not have enough visits for field data, so you'll only see the lab result.
- Use the lab result and the Chrome DevTools Performance panel to find the cause. WebPageTest gives a detailed request waterfall if you need one.
- Once the page passes, add Lighthouse CI, an open-source tool that runs Lighthouse on every commit and flags regressions.
For a metric-by-metric walkthrough of fixes, see how to improve Core Web Vitals.
If your pages miss these thresholds and you'd rather hand the work over, Acefina has optimized 500+ websites. Start with a free review through our speed optimization service.