Is PageSpeed Insights accurate? One unchanged page of mine scored 77, 83 and 90 in about four minutes. Here is which number moved, and what to do with a score.

PageSpeed Insights gave the home page of cryptowl.io, a site of mine, three scores in about four minutes on 3 October 2026: 77, then 83, then 90, on the Desktop tab, with nothing on the page changed between runs. The Mobile tab did the same: 85, 93, 95. The question in the title is what I typed afterwards, and the pages that answer it split between yes and no. Both are the wrong shape of answer.

Here is the right shape. The score is exact arithmetic: a weighted average of five measurements from one simulated load, Google’s estimate of how one real load would go on a slow phone or a desktop. I put the five numbers from each screen that showed them through the public formula of Lighthouse, the test engine inside PageSpeed, and every score came back. What is not fixed is the five numbers. On my page one of them did nearly all of the moving between runs: Total Blocking Time, which happens to carry the largest weight. The time until the headline was drawn held at 2.9 s on every mobile run; on the desktop it crept the wrong way, 0.8 to 0.9 s, as the score rose. Google’s own notes on score variability say the score will change “even if there hasn’t been a code change” and tell you to take the median of several runs. The circle is a sample, not a reading.

What to do with the number in the circle

Three steps, each needing only the report on your screen and the Analyze button.

Run it again. Then again. Same address, same tab. The same notes on score variability give one figure for repeated runs:

Google’s notes on score variability, on repeated runs

The median Lighthouse score of 5 runs is twice as stable as 1 run.

The same notes say to “use aggregate values like the median, 90th percentile, or even min/max instead of single test results.” The median is the middle one once you sort them. Not the best, not the latest.

Read the five numbers under the circle, not the circle. First Contentful Paint (FCP, when any content first shows), Largest Contentful Paint (LCP, when the biggest block of the first view, on my page the headline, is drawn), Total Blocking Time (TBT, more on it below), Cumulative Layout Shift (CLS, how far content moves while loading), Speed Index (how quickly the visible screen fills in). Across your runs, see which moved and which held. The ones that hold are the test’s steady reading of your page. The one that jumps is the one it cannot pin down: read it as a range, and if it is high on every run, the problem is still on your page. On my page it was Total Blocking Time in every step I could check but the last mobile one; the next section has the arithmetic. The small print under the circle says as much on every run: “Values are estimated and may vary.” Beneath the metrics, “Single page session” and “Initial page load”: one visit, from an empty cache, on Google’s machine.

Judge what your visitors get by the box above the circle, not the circle. On my three runs the circle climbed thirteen points and the panel under “Discover what your real users are experiencing” did not change; the article on that box is about reading it. Google’s page on the measuring tools says where the circle stands: “the Performance Score of Lighthouse is a broad measure of that lab test and often does not correlate with field Core Web Vitals.” On a small site that box may say there is not enough real-user data; then the middle of several runs is all you have, never a single one.

If the low score came from someone else, in an agency’s email for example, do the same: run the address yourself several times and keep the middle one. One score in an email is one sample. If your middle run is still red, the test is pointing at something on your page, and the five numbers say where. Whether the score itself matters to Google is further down.

Several runs, the middle one, the metric that moved, the box for your visitors: that is the method. The rest of this article is the evidence for it.

Which number moved on my page, and which did not

The three runs as the screens showed them. On the first desktop run I captured only the circle; the numbers in that row are reconstructed: the four steady ones close to what the next runs showed, and the Total Blocking Time that makes Lighthouse’s formula give 77.

Google’s scoring page says “The Performance score is a weighted average of the metric scores.” and gives the weights: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%. Each measurement is first turned into a score of its own on a curve, then the five are weighted and added. The formula is public, in Lighthouse’s code, and I ran the five numbers from each screen that showed them through it. Every score comes back within rounding. That is what “accurate” means here, and it is all it means.

Now the movement. Desktop 83 to 90 is Total Blocking Time 360 to 240 ms and nothing else worth a point; LCP, the time until the headline was drawn, went from 0.8 to 0.9 s, the wrong direction for a rising score. On the curve, 360 ms earns 14.4 of Total Blocking Time’s 30 points and 240 ms earns 21.3. There are the seven points. Mobile 85 to 93 is the same metric, 360 to 80 ms, with LCP at 2.9 s in all three runs; the last mobile step, 93 to 95, came mostly from Speed Index, 3.4 to 1.9 s, with Total Blocking Time already near full marks.

Total Blocking Time, in plain words, is how long during the load the browser was too busy, mostly running scripts, to respond: for every stretch of such work longer than 50 milliseconds, the part beyond the first 50 is added up; Lighthouse’s page on the metric has the definition. It carries the largest weight, and how long that work takes depends on the machine running it as well as on the page.

Also on the screens: the same 360 ms carried an orange square on the Mobile tab and a red triangle on Desktop, and mobile scored higher than desktop in all three runs. Not an error: Google’s scoring page says Lighthouse 6 moved desktop onto “specific desktop scoring” because the mobile curves had been giving “artificially inflated desktop scores”. Desktop is tested as a faster device and marked against a stricter curve. Compare a run with a run on the same tab, never across the two.

Why the inputs move, in Google’s words

Google’s page about PageSpeed Insights asks the question for you, as a heading in its FAQ:

Google’s page about PageSpeed Insights, a heading in its FAQ

Why does the performance score change from run to run? I didn’t change anything on my page!

Its answer: “Several common sources of metric variability are local network availability, client hardware availability, and client resource contention.” The same page says the test “runs in a Google datacenter that can vary based on network conditions”.

The variability notes have a table of causes with a column for PageSpeed Insights. Of the high-impact causes, it rates only two as likely or possible on PageSpeed: your page doing something different on each load, and Google’s test machine being busy with other work. Your server is on the list too, rated low impact.

Why Total Blocking Time moved on Google’s machine between 12:09 and 12:13 I cannot prove; the report does not say what else that machine was doing. My reading, from that list: a page that gives the test machine script work gets a different answer depending on how busy that machine is, and the metric that counts that work is the one that swings.

The other half of the evidence is a page with no such work. kovalseo.com, the site this blog is on, had no script of its own on its home page that day. In PageSpeed it read Total Blocking Time 0 ms, desktop 100 and mobile 99, one run each. On my own laptop, with the Lighthouse version PageSpeed was using that day and ten runs per site and tab, its blocking time was 0 in all twenty runs and its score held at 99 or 100, apart from two dips my laptop caused by stalling before it drew anything. cryptowl.io on the same laptop had a blocking time that changed from run to run and a score that followed it, while its LCP barely moved. My laptop’s numbers are not PageSpeed’s; the pattern is the point. A page with nothing to block has far less to swing.

A timing the simulation got early, on every run

Unstable is one thing. In one metric the lab was also wrong in a consistent direction on my page, and Google’s documentation warns the method can be. Lighthouse’s throttling document says the default mode, which PageSpeed uses, “uses a simulation of a page load, based on the data observed in the initial unthrottled load”, and that “due to the imperfect nature of predicting alternate execution paths, there is inherent inaccuracy”. The report loads your page once, for real, then works out what that load would have taken on a slow phone or a desktop.

Each run also keeps, in its full report data, what the real load did at full speed, so the two can be compared. In my ten desktop runs on cryptowl.io, the simulation reported the headline drawn at 0.83–0.92 s; the real load at full speed inside the same runs showed it at 1.61–3.13 s, median 1.68 s, never before 1.6 s. On kovalseo.com’s desktop runs, the control, the two figures were within 0.02–0.31 s of each other, leaving out the run where my laptop stalled. That much is measured, on my laptop, on two pages. On cryptowl.io, then, the report’s headline time was earlier than any real load it watched. Why the simulation runs early on one page and not on the other, the report does not say, and I can only guess. “Values are estimated and may vary.” is the most accurate line on the report.

90, 100 and the colours

The legend under the circle gives the bands: 0–49 red, 50–89 orange, 90–100 green. A page crossing from 89 to 90 changes colour and nothing else; on mine the crossing took one more run and no work. Google’s scoring page says what 100 is:

Google’s Lighthouse scoring page, on a score of 100

A “perfect” score of 100 is extremely challenging to achieve and not expected.

and, in the next sentence, “taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94.” kovalseo.com’s Desktop tab read 100 in its one run, so it is reachable, by a page that did almost nothing on arrival. For one that does something, the last points are the most expensive and the least informative; past 90 they do not even change the colour.

Why another tool gives another number

Run Lighthouse inside Chrome’s DevTools, or from the command line, and the same page usually gets a different score. Google’s page on the DevTools Lighthouse panel says the test there is influenced by “other load happening on your device, Chrome extensions, and any device settings you’ve stored in cookies, local storage, or similar”, and draws the line: “This also means you cannot directly compare two Lighthouse audits completed on different machines.” PageSpeed, the same page says, runs on separate servers and “may produce a ‘cleaner’ and more consistent Lighthouse audits that are easier to compare over different runs.”

The gap is widest on the Mobile tab. Run on your own computer, the mobile test slows the processor “4x from your machine’s default speed”, in the words of Lighthouse’s readme. PageSpeed’s release notes say its own factor “has been adjusted to account for the low CPU performance benchmarks typical in PageSpeed Insights production environments.” So the two imitate the same phone with a differently slowed processor, and the metric that takes the hit is Total Blocking Time; on my laptop the same page’s mobile score sat well below what PageSpeed had given it that day, with the same Lighthouse version, while the LCP figures came out close. The same release notes put it in one line: “different environments (hardware & connectivity) will influence measurement, so cross-environment consistency is near impossible.” A different number from a different tool is not one of them lying. Compare within one tool, on one tab.

Does page speed affect SEO?

Only Google’s own words here, with dates, because many pages on this question claim more than Google has said.

Google’s page on page experience, updated 22 September 2026, says that Core Web Vitals, the real-visitor measurements in the box above the circle, are used in ranking; the article linked earlier quotes that sentence. The lines around it fence it in. On page experience, “There is no single signal.” Getting good results in “third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results”. And:

Google’s page on page experience, on chasing a score

trying to get a perfect score just for SEO reasons may not be the best use of your time.

Google’s blog post of January 2018, announcing speed as a mobile ranking factor, said “a slow page may still rank highly if it has great, relevant content.” and that “there is no tool that directly indicates whether a page is affected by this new ranking factor”. Its post of April 2023 said of the page experience update that “It was not a separate ranking system”.

Then the gap. No Google page I read names the Lighthouse or PageSpeed score as something ranking uses, and none says it is not used. The pages I read for this question fill that silence three ways: no effect, it helps, nobody knows. Google’s nearest statements are that ranking uses Core Web Vitals, measured on real visitors, and that the score “often does not correlate with field Core Web Vitals”. That leaves the score where Google’s page on the tools puts it: “Use field data for measuring real-world performance, and lab-based tools like Lighthouse for diagnostics of how to improve it.”

So, is it accurate?

The score was right every time I could check it: each was the correct sum of the five numbers under it, and those five numbers were the test’s estimate from one load on one machine at that minute. What the question wants is something the score was never built to be: a property of the page. About four minutes, three samples, thirteen points, and, where I had the numbers, one metric doing nearly all of the moving while the headline time held or went the wrong way.

So read the report the way it is built. The circle says how that load went; the five numbers say which part of it to doubt; the box above says what your visitors got. A run lower than the last is a reason to run again, not to act. After you change the page, do the same: one higher circle is one more sample; a timing under it that stays lower across several runs is your change showing.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.