Why PageSpeed says 68 on mobile and 96 on desktop

Here is the fact that should change how you read every speed report you are ever sent. We measured our homepage from our own server, waited thirteen seconds, and measured it again. Same machine, same command, same URL. The first run scored 90. The second scored 85.

Five points is the width of the gap between a green report and an amber one when you are sitting near 90. And we did not do anything in those thirteen seconds except wait.

An hour earlier, Google's own infrastructure had given the same page a 68.

We do page speed optimisation for clients and we keep a free website speed test online, so we read these reports every day. The new Cittago site went live on 6 July 2026, the first article is from 12 July, and the serious content work started on the 27th. A young site with its flaws in daylight is a better subject for this than an invented example.

What the performance score actually is

Definition. The PageSpeed Insights performance score is the 0–100 grade Lighthouse gives to one load of one page, simulated on a cheap phone over a slow network, by combining five timing measurements into a weighted average.

Every clause matters. One load — not an average of the week. One page — not the site. Simulated — no human was involved. Cheap phone, slow network — it is a stress test, not your customer's Tuesday.

Google documents the colour bands: 0–49 red, 50–89 amber, 90–100 green (Lighthouse scoring documentation). A 68 lands in the middle of amber, which is the widest band and the most stressful, because it tells you neither that you are fine nor that you are in trouble.

Thirty per cent for a metric you never look at

The big number is not a measurement. It is a weighted average of five measurements, and the weights are public and worth learning, because they tell you where effort pays.

The top row surprises everyone. The single heaviest factor is not how fast the page appears — it is how long the page stays deaf to your taps. Thirty per cent of the grade for something almost nobody reads, because it sits at the bottom right of the report and is written in milliseconds.

It also has an uncomfortable practical edge. Compressing images is the easiest and most visible work available, and it touches 25% of the grade at best. The code that runs at start-up touches 30%, and it is usually not code you wrote.

Four numbers for one page, fifteen minutes

So that is the instrument. Here are the readings it gave us, on one page, inside a quarter of an hour.

Two runs on PageSpeed Insights at 13:32, mobile and desktop. Then four Lighthouse runs from our own server — the same engine PageSpeed Insights runs inside — between 13:42 and 13:45.

Twenty-two points between two mobile measurements of the same page, ten minutes apart, on the same version of the same tool. So when someone forwards you a screenshot with "your site is slow" in the subject line, the first useful question is not what to fix. It is who ran it, and from where.

Look at those other three columns for a second. Accessibility 100, best practices 100, SEO 100, identical across both runs. Those categories are checklists: the attribute is either there or it is not. Performance is not a checklist. Performance is a stopwatch, and a stopwatch depends on who is running.

Accessibility, SEO and best practices tell you what you built. Performance tells you how one particular load went, once.

Two runs, thirteen seconds apart: 90 and 85

Back to the two consecutive runs, because they are the cheapest lesson in this article.

Largest Contentful Paint went from 1.8 to 2.7 seconds. Blocking went from 340 to 420 milliseconds. Same container, same URL, same command, thirteen seconds apart.

Google lists traffic routing, device differences, browser extensions and even antivirus software among the causes of this variance. We would add a duller one that we see constantly: the machine doing the measuring is also doing other things.

Which gives the rule that saves the most time in this whole field: run it three times and take the middle one. Run it once and you are measuring the noise as well as the site, and then you spend an afternoon hunting the cause of five points that were never there.

Two machines, two different bottlenecks

The two mobile runs used the same configuration, and not approximately — it is written inside the reports. Emulated moto g power (2022), 412×823 screen, network simulated at 150 ms latency and roughly 1.6 Mbps, processor slowed four times. Lighthouse 13.4.1 on both.

The results still disagree, and the interesting part is that they are not contradicting each other. They are describing two different bottlenecks.

In plain terms: Google's machine chewed through the JavaScript faster than ours did, but the page arrived at it much more slowly in bytes. And because the largest element's arrival carries 25% of the grade, that delay eats the score.

Why does delivery vary that much? Because between the measurer and your server sit distance, a CDN and, almost always, some security checks. Those are the same three things that differ between a customer on a commuter train and a customer on office fibre. It is not a flaw in the test — it is the piece of reality the test includes and you do not control.

The row that says "No Data"

At the top of the report there is a box called Discover what your real users are experiencing. On ours, in both modes, it says No Data.

That box is the only part of the report about actual people. It holds what Chrome collected from real visitors to your site over the last 28 days, and it only appears when there is enough traffic to make the sample trustworthy. Our site is a month old. There is not.

So all four of our numbers are simulations. They are useful — a repeated simulation tells you whether a change helped or hurt — but not one of them is a customer's experience.

If you have traffic and the box is populated, your work is there. If the box is empty like ours, the lab score is what you have, and you use it for what it is good at: comparing one page against itself, always measured the same way.

Half our homepage is measurement tags

So far this has been about how much the score depends on who measures. Now the part that depends on us, with the bytes counted.

In the 13:42 run, our homepage downloaded 950,782 bytes across 28 requests. Here is where they came from.

More than half the weight of our homepage is tooling that measures rather than shows. The three largest files on the page are, in order, the Analytics tag (191 KB), the Google Ads tag (181 KB) and the Tag Manager container (119 KB). The HTML document, for comparison, is 56 KB.

What happens if you take them out? We did that at 13:45, same machine, same command plus one line that blocks the domain.

Five points of score and three seconds off the moment the page starts answering taps. And here is the unheroic part: we are keeping the tags. They tell us which pages produce enquiries and which do not, and that is worth more to us than five points on a simulated stopwatch.

It is a choice, not an oversight. But it should be a choice made with the number in front of you rather than out of habit. The right question is not how to reach 100. It is what you are buying with the points you are spending. If you have three remarketing tags still firing for campaigns that ended last year, you are paying for them on every phone that opens your site.

What the score does not tell you

That last row applies to us too, which is why the ugliest number in this article — 68 — is Google's and not ours. Publishing only the 90 we measured in-house would have made for a more comfortable article and a less true one.

What you need to run this yourself

Everything above is reproducible today, on your own site, with nothing to install. You need:

• The exact address of the page that earns money. Not the homepage out of habit: the product page, the service page, the contact form.
• Two minutes to run it three times instead of once, and take the middle result.
• Somewhere to write the five numbers down, with the date. A spreadsheet is plenty. Without a history, every measurement is day one.
• The same source every time. If you start with PageSpeed Insights, stay with PageSpeed Insights.
• Chrome on your own machine, if you also want the local version: the Lighthouse panel lives in the developer tools and measures from your network.

If you would rather have the summary pre-chewed, our free website speed test runs the check and hands back the numbers with the explanation beside them, no sign-up.

How to read a report in ten minutes

1. Look at the top box first, the real-user one. If it has numbers in it, the rest of the report is secondary — work on those.
2. Run it three times, take the middle. One run is not a measurement, it is an impression.
3. Ignore the circle, read the five rows. The big number does not tell you what to do; the metrics do.
4. Start with blocking time. It carries 30% and it is nearly always third-party code: tags, chat widgets, cookie banners, review embeds.
5. Then the largest element. Nine times out of ten it is the image at the top. If it is a video or a carousel, you have found your afternoon.
6. Watch the filmstrip. Two blank frames at the start means waiting for delivery; a page that assembles in jerks means code.
7. Measure the page that earns money, not the homepage, and re-measure after every change — one change at a time, or you will not know which one counted.

The words, in a table

Where you stand, in three thresholds

If the real-user box is populated and your values are green, you are done. The lab score is trivia. Go back to selling what you sell.

If the box is populated and the values are red, you have a real problem, and you have it with people rather than with a simulator. Start with the worst metric and do not look at the score until you have moved it.

If the box is empty like ours, you are in the lab. That is fine: pick one source, run three times, write down the five numbers with the date, and repeat after every change. In a month you will have a line, and a line is worth ten screenshots.

Our box will fill up when there is enough traffic. On that day we will publish the real numbers next to these ones and see how wrong we were. Let's talk again in three to six months 😉

Questions

Questions nobody has actually asked us

Nobody has written in to ask: the article went up today. These are the questions a reader would have, plus the ones that come up in client conversations whenever the amber screenshot lands.

Last updated: 7 August 2026. The figures come from two PageSpeed Insights reports for https://cittago.com/ run on 7 August 2026 at 13:32 (GMT+3) and from four Lighthouse 13.4.1 reports generated in a container on our own server between 13:42 and 13:45 the same day. Metric weights are those in the Lighthouse documentation as read on that date. We update this page when the weights change, or when our own report stops saying "No Data".