You'll hear that a slow site will sink your rankings, and that speed barely matters for SEO. Both claims usually come without a source. This guide sticks to what Google has published, explains which speed numbers Search actually looks at, and shows where to start if yours are poor.
Does page speed affect SEO?
Yes, but modestly. Google has used speed as a ranking signal since 2010 on desktop and 2018 on mobile, and its ranking systems now use Core Web Vitals measured from real Chrome users. Google is equally clear that relevance comes first: a slow page with the best answer can still rank, and page experience matters most when several pages offer similar content.
What has Google said about speed and rankings?
Every row below comes from Google's Search Central blog.
| When | What Google announced | What it said about weight |
|---|---|---|
| April 2010 | Site speed added as a ranking signal | Less weight than relevance; fewer than 1% of queries affected (English searches on Google.com at the time) |
| January 2018, live July 2018 | The "Speed Update": page speed becomes a ranking factor for mobile searches | Only the slowest pages; a small percentage of queries |
| May 2020, rolled out June–August 2021 | Page experience update: Core Web Vitals combined with mobile-friendliness, HTTPS and interstitial signals | Great, relevant content still wins over a sub-par experience |
| March 2024 | Interaction to Next Paint (INP) replaces First Input Delay as a Core Web Vital | Good Core Web Vitals stats "don't guarantee good rankings" |
The message is consistent. In 2010, Google said the new signal "doesn't carry as much weight as the relevance of a page." In 2018, it said a slow page may still rank highly with great, relevant content. The 2020 post added the key nuance: when multiple pages have similar content, page experience becomes much more important. Before the 2021 rollout, Google told site owners not to expect drastic changes. Core Web Vitals explained covers what each metric measures.
How much does website speed matter for SEO compared with content?
Google's current page experience documentation is its plainest statement on this:
- There is no single "page experience signal," but Core Web Vitals are used by Google's ranking systems.
- Good Core Web Vitals results don't guarantee top rankings, and chasing a perfect score just for SEO may not be the best use of your time.
- Search always tries to show the most relevant content, even if the page experience is sub-par. Where lots of helpful content exists, a great page experience can contribute to success.
Our reading: speed is more tie-breaker than trump card. If you're on page three because your page doesn't answer the query, a faster server won't move you. If you're on page one next to competitors with similar content, a poor experience can separate you.
Which speed data does Google Search actually use?
Field data comes from the Chrome User Experience Report (CrUX), which collects performance data from real Chrome users. Chrome's documentation says CrUX data is used by Google Search to inform the page experience ranking factor. Search Console's Core Web Vitals report is built from the same real-user data.
Lab data comes from Lighthouse, which loads your page once in a controlled environment. Google's PageSpeed Insights documentation says the mobile test simulates a mid-tier phone on a mobile network.
| Field data (CrUX) | Lab data (Lighthouse) | |
|---|---|---|
| Source | Real Chrome users visiting your pages | One simulated page load |
| Time window | Previous 28 days | The moment you run the test |
| Reported as | 75th percentile, rated good / needs improvement / poor | 0–100 Performance score plus metrics |
| Responsiveness metric | INP | Total Blocking Time |
| Available for | Pages or sites with enough real traffic | Any public URL |
| Best used for | Knowing what visitors (and Search) experience | Diagnosing why a page is slow |
None of Google's pages cited here names the 0–100 Lighthouse score as a ranking input; what they tie to ranking is Core Web Vitals from real users. If a page lacks traffic, PageSpeed Insights falls back to your whole site's data. If there's none, the lab test is your best guide.
PageSpeed Insights vs Lighthouse: what's the difference?
Lighthouse is Google's open-source auditing tool, run from Chrome DevTools or the command line. It produces lab data only. PageSpeed Insights runs Lighthouse on Google's servers and adds CrUX field data on top, so its report has two halves: what real users experienced over the last 28 days, and a fresh lab run that helps explain why.
Running Lighthouse yourself means your machine is part of the test. Chrome's scoring documentation lists browser extensions, antivirus software and different devices among the reasons scores fluctuate. The same page shows the score is a weighted blend: in the latest weighting it lists (Lighthouse 10), Total Blocking Time counts for 30%, LCP and CLS for 25% each, and First Contentful Paint and Speed Index for 10% each. 90 or above is good, 50–89 needs improvement and below 50 is poor.
The PageSpeed Insights FAQ adds that good lab data doesn't necessarily mean real users are having a good experience. For how it compares with GTmetrix, Pingdom and WebPageTest, see our speed test tools comparison.
How do you read a speed report? A worked example
For this example, assume a mobile PageSpeed Insights report for a service business's homepage shows these numbers. They're illustrative, not from a real site.
| Metric | Field (real users, 75th percentile) | Lab (one simulated load) |
|---|---|---|
| Largest Contentful Paint | 3.4s | 6.1s |
| Interaction to Next Paint | 150ms | not measured |
| Cumulative Layout Shift | 0.04 | 0.05 |
| Total Blocking Time | not reported | 450ms |
| Performance score | — | 52 |
- The page fails the Core Web Vitals assessment. PageSpeed Insights only passes a page when all three metrics are good at the 75th percentile. LCP is above Google's 2.5-second threshold.
- LCP is the SEO problem, not the score of 52. The lab LCP of 6.1s simulates a slower phone. Real visitors see 3.4s, and that's the number to bring under 2.5s.
- Interactivity can wait. The lab's 450ms of blocking time looks bad, but real users' INP of 150ms is already under the 200ms "good" mark.
- Put a rough price on it. Our site speed audit applies Portent's 2019 finding (conversion rates dropped an average of 4.42% per additional second of load time, between 0 and 5 seconds) to the time over 2.5s: 0.9s × 4.42% ≈ 4.0%, shown as a 2.8%–5.2% range. Assuming $20,000 a month in online revenue, that's roughly $560–$1,040 a month. It's an illustrative range, not a forecast.
What should you fix first?
- Check your field data first. Use the top half of PageSpeed Insights or Search Console's Core Web Vitals report.
- Fix the failing metric, worst first. All three must pass, so one good metric doesn't offset a poor one.
- For slow LCP, start with the server. Web.dev's LCP guide warns that a high Time to First Byte can make a 2.5-second LCP challenging or even impossible. Page caching, better hosting and a CDN help; see signs you need to switch hosting and whether you need a CDN. Then tackle oversized hero images and render-blocking files.
- For CLS and INP, reserve space for images and embeds, and trim third-party scripts. Why is my website so slow? covers the common causes.
- Don't chase 100, and give it a month. Field data covers a trailing 28 days, so improvements show up gradually.
Why does speed matter even if rankings barely move?
The ranking effect is modest, but visitors feel every second. Back in 2010, Google said its internal studies showed visitors spend less time on slow sites. The bigger payoff is usually conversions, not positions. We cover that research in does website speed affect conversions? and what slow load times are costing your business.
