No, the PageSpeed Insights score does not affect SEO directly. Google does not use the 0 to 100 performance score as a ranking signal. What it does use is the Core Web Vitals field data shown at the top of the same report, and that is where most people look last.
This guide is for site owners who have run PageSpeed Insights, seen a number they did not like, and want to know what it actually means for their rankings. It explains what the tool measures, why the score and the Core Web Vitals assessment can disagree, and which one deserves your attention.
Key takeaways
- The performance score is a lab simulation. It is generated by Lighthouse on a simulated device and connection, in a single run.
- The Core Web Vitals assessment is field data. It comes from real Chrome users over the last 28 days and is the only part of the report tied to rankings.
- A score of 67 can pass Core Web Vitals, and a score of 95 can fail. The two measure different things under different conditions.
- Fix in this order: the failing field metric first, then whatever the lab diagnostics say is causing it.
- Small sites often have no field data at all. That is not a fail, it is a gap you fill by testing yourself.
What PageSpeed Insights actually reports
Open any PageSpeed Insights report and you will see two distinct sections. Most people scroll past the first one to get to the big coloured number, which is the wrong way round.
At the top: “Discover what your real users are experiencing.” This is the Core Web Vitals assessment. It shows a pass or fail banner and the values for Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS), plus a few supporting metrics. The data comes from the Chrome User Experience Report (CrUX), which aggregates anonymised measurements from real Chrome users visiting your page. The figure shown is the 75th percentile over a rolling 28-day window, meaning three quarters of your visitors had an experience at least that good.
Below it: “Diagnose performance issues.” This is the Lighthouse audit. It loads your page once, in a simulated environment, and produces the performance score along with a list of opportunities and diagnostics. The simulation uses a mid-range mobile device profile and a throttled mobile connection when you select the Mobile tab, which is why the mobile score is almost always lower than desktop.
The two sections are answering different questions. The first asks “how fast is this page for the people who actually visit it?” The second asks “how fast would this page be for a hypothetical visitor on a slow phone, right now, once?”
Which part does Google use for rankings?
Google’s page experience guidance is explicit that Core Web Vitals are assessed using field data. The Google Search Central documentation on page experience describes Core Web Vitals as a set of metrics measured from real-world usage, and Search Console’s Core Web Vitals report is built entirely on CrUX data.
The Lighthouse performance score is not mentioned anywhere in Google’s ranking documentation. It is a diagnostic tool built by the Chrome team to help developers find problems. It was never designed as a ranking input, and it would be a poor one: a single synthetic run on one device profile tells Google nothing about what your visitors experience on their own phones and networks.
So the answer to “does PageSpeed Insights affect SEO?” splits cleanly in two. The field data section reflects the same metrics Google uses in ranking. The performance score does not, and no amount of chasing it will move your rankings on its own. For the broader picture of how much speed matters against content and links, see does page speed affect SEO.
Why a score of 67 can pass and a 95 can fail
This is the part that confuses most people, so it is worth being precise about it.
A 67 that passes. Imagine a WordPress site whose visitors are mostly on desktop, on decent broadband, in the UK. Their real LCP might be 1.9 seconds, INP 120 milliseconds, CLS 0.02. All three are inside the thresholds that web.dev defines as “good”: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. The page passes. Meanwhile the Lighthouse mobile run, simulating a slow phone on a throttled connection, measures a 3.8 second LCP and heavy JavaScript execution, and produces a score of 67. Both are correct. They just describe different visitors.
A 95 that fails. Now imagine a lightweight page that loads beautifully in the lab, but embeds a third-party chat widget that only fires after a real user scrolls, and injects a cookie banner that pushes the layout down once consent scripts load. Lighthouse’s single run finishes before the widget does anything and records almost no layout shift. Real users on real sessions get an INP of 350 milliseconds when they tap the menu and a CLS of 0.18 from the banner. The field assessment fails on two metrics while the score sits comfortably in the green.
The general pattern:
- Lab is harsher on loading. The throttled simulation punishes heavy images, render-blocking CSS and large JavaScript bundles more than most real UK connections do.
- Lab is blind to interaction. INP needs real taps and clicks over a whole session. Lighthouse estimates it with Total Blocking Time, which is a proxy, not the metric.
- Lab sees one moment; field sees a month. Layout shifts caused by late scripts, ads, fonts swapping in, or content injected after consent are routinely missed in a single synthetic load.
How the performance score is calculated
Understanding the score’s composition explains why it swings so much between runs. Since Lighthouse version 10, the performance score is a weighted blend of five lab metrics:
| Metric | Weight | What it measures |
|---|---|---|
| Total Blocking Time (TBT) | 30% | How long the main thread was blocked by long JavaScript tasks |
| Largest Contentful Paint (LCP) | 25% | When the largest visible element finished rendering |
| Cumulative Layout Shift (CLS) | 25% | How much the layout moved during load |
| First Contentful Paint (FCP) | 10% | When the first text or image appeared |
| Speed Index | 10% | How quickly the visible content filled in |
Nearly a third of the score rides on Total Blocking Time, which is why a page with a lot of JavaScript can score badly even when it looks fast. The score bands are 0 to 49 (red), 50 to 89 (orange) and 90 to 100 (green). None of these five lab values are used for ranking. LCP and CLS matter, but only their field versions count, and INP is not in the score at all.
What “no field data” means for a small site
If your page shows “The Chrome User Experience Report does not have sufficient real-world speed data for this page,” you are not failing. CrUX needs a minimum volume of eligible Chrome visits over the 28-day window before it will publish numbers, and many small business sites never reach it for individual pages.
PageSpeed Insights will sometimes fall back to origin-level data, which pools every page on the domain. If even that is missing, you have no field assessment at all, and Search Console’s Core Web Vitals report will show few or no URLs.
In that situation the lab data is the only signal you have, so it becomes more useful, not less. Treat the Lighthouse LCP and CLS values as a rough proxy, run the test several times on both Mobile and Desktop, and test a handful of real pages rather than just the homepage. Our free website speed test runs the same checks and reports the results in plain language if you want a quicker view.
How to read a PageSpeed Insights report properly
Work through the report in this order and you will make better decisions than most agencies.
- Read the assessment banner first. “Passed Core Web Vitals assessment” or “Failed” is the headline. If it says passed, your speed is not holding back your rankings and you can move on to content and links.
- If it failed, identify which metric. LCP, INP and CLS need different fixes. A failing LCP is usually images, fonts, server response or render-blocking CSS. A failing INP is almost always JavaScript. A failing CLS is images without dimensions, late-loading ads or embeds, or fonts swapping.
- Now use the Lighthouse diagnostics. Scroll to the “Opportunities” and “Diagnostics” lists and look for the items that map to your failing field metric. Ignore the rest for now.
- Do not fix things purely to raise the score. Removing a 0.5 second saving that only appears in a throttled simulation, at the cost of a feature your visitors use, is a bad trade.
- Re-test after changes, then wait. Lab results update instantly. Field data takes up to 28 days to fully reflect a fix, so check Search Console a month later rather than the day after.
For an explanation of what score ranges mean in practice, and what “good” looks like at each band, read what is a good website speed score.
What to fix, and in what order
The right priority is the failing field metric, then the lab diagnostics that explain it. In practice, the fixes that move field data on typical small business sites are:
- For LCP: compress and resize the hero image, serve it in WebP or AVIF, preload it, and cut server response time with caching or better hosting.
- For INP: remove or defer third-party scripts, split large JavaScript bundles, and stop heavy work from running on every page load.
- For CLS: give every image and embed explicit width and height, reserve space for banners and ads, and load web fonts with a fallback that matches their metrics.
If you would rather have someone look at the specifics, we offer a free speed check that reviews your real report and sends back a plain-English list of what is actually causing each failing metric, usually within one working day. We have sped up more than 50 websites through One Blue Pixel and the pattern is almost always the same: two or three root causes account for most of the problem. Our Core Web Vitals optimisation service then fixes those causes on your live site.
Frequently asked questions
Does a low PageSpeed Insights score hurt my rankings?
Not on its own. The score is a Lighthouse lab number and Google does not use it as a ranking signal. What can hurt rankings is failing the Core Web Vitals assessment shown above the score, because that is real user data. Check the assessment banner before worrying about the number.
Is a PageSpeed Insights score of 67 good?
It sits in the orange band (50 to 89), which Lighthouse labels as needing improvement. Whether it is a problem depends on your field data. A 67 with a passed Core Web Vitals assessment is fine for SEO. A 67 with failing field metrics means there is real work to do.
Why is my mobile score so much lower than desktop?
The mobile test simulates a mid-range phone on a throttled connection, so heavy images and JavaScript cost far more time than on a desktop simulation. Google indexes the mobile version of your site, so the mobile report is the one to focus on, but remember the score is still a simulation.
Why does my score change every time I run the test?
Each run is a single synthetic load, and it is sensitive to server response time at that moment, third-party scripts, and background load on the test infrastructure. Variation of five to ten points between runs is normal. Run the test three times and look at the pattern rather than a single result.
How long until fixes show in the Core Web Vitals assessment?
Field data is a rolling 28-day window at the 75th percentile, so improvements phase in gradually and can take a full month to be fully reflected. Search Console’s Core Web Vitals report updates on the same cycle. Lab results in PageSpeed Insights change immediately, which is useful for confirming a fix worked.
The bottom line
PageSpeed Insights does not affect SEO through its score. It affects SEO only in the sense that it displays the same Core Web Vitals field data Google uses, and that data is what you should read first. Use the score and its diagnostics as a map to the causes, not as the destination.
If your assessment says passed, stop optimising for the number. If it says failed, fix the failing metric and give the field data a month to catch up. And if there is no field data at all, test real pages yourself and treat the lab numbers as the best guide you have.
Want us to check your site speed?
Get a free, no-obligation speed report for your website. We will tell you exactly what is slowing it down and what to do about it.