How to Read PageSpeed Insights: Which Part Google Actually Uses

Have you ever had your blood pressure taken at a check-up and seen a number that made the nurse raise an eyebrow, even though you feel perfectly fine at home? Usually she just smiles and asks you to sit quietly for ten minutes before trying again. You have just climbed the stairs, you could not find a parking spot, your heart is still racing. The second reading comes back normal. And if the doctor really wants to know what your blood pressure is like, she will ask to see the log you kept at home every morning for a month, rather than trust one reading taken in the exam room.

Google's PageSpeed Insights report works exactly the same way. On one page it stacks two very different kinds of numbers. One is a single measurement taken in a lab. The other is a log of what real visitors experienced over several weeks. Many business owners I talk to see a big red or orange circle in the middle of the screen, panic, and hire someone for "speed optimisation" straight away, before they know whether that number is the monthly log or the blood pressure reading taken right after the stairs.

In this article I will walk you through the report one layer at a time: which part Google actually uses, which part swings every time you press the button, what you can judge for yourself, and what to ask your web team before you spend anything. If you first want to know what Core Web Vitals are and why they matter, I covered that separately in our article on Core Web Vitals for business websites. Here we focus only on reading the report.

Open Your Own Report Alongside Me for Five Minutes

Go to pagespeed.web.dev, paste in your homepage address, press Analyze and wait about a minute. While it runs, get ready to answer three questions from your own screen.

First, does the top box, the one headed "Discover what your real users are experiencing", show numbers, or does it say there is not enough data? Second, if there are numbers, does the "Core Web Vitals Assessment" line say Passed or Failed? Third, what does the Performance score circle further down say?

Then press Analyze once more and see which answers changed and which stayed the same.

If you do this, you will see for yourself that the first two answers barely move while the third can jump by tens of points. That difference is the key to reading the whole report.

One PageSpeed Insights Report, Two Layers Telling Different Stories

Google says it plainly in its documentation about PageSpeed Insights: the report contains two kinds of data. Field data comes from real users on a variety of devices and network conditions. Lab data comes from a simulated page load on a single device with a fixed set of network conditions. The same page notes that the values from the two may differ.

The Top Layer Is the Real-User Log

The top box is field data. Its numbers come from the Chrome User Experience Report, or CrUX, which Chrome's documentation describes as a dataset reflecting how real-world Chrome users experience popular destinations on the web. These numbers cover the previous 28 days. They are not measured when you press the button, which is why you get the same numbers no matter how many times you run it. It is the monthly log.

Inside that box are the three metrics grouped together as Core Web Vitals: LCP (how quickly the main content finishes appearing), INP (how quickly the page responds when someone taps or clicks) and CLS (how much the page jumps around while loading). The thresholds set out in web.dev's Web Vitals article are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile, separately for mobile and desktop.

"75th percentile" sounds academic, but in plain terms it means this: take 100 visits to your site, sort them from fastest to slowest, and look at visit number 75. If that visit is still within the good range, most people are having a good experience. The PageSpeed Insights documentation states that a site passes the Core Web Vitals assessment only if the 75th percentiles of all three metrics are good. If any one of them slips, the assessment says Failed (if there is too little INP data, it is judged on LCP and CLS alone).

This is the layer that reflects what your customers actually experience, and it is the one to weight most heavily when money is involved.

The Bottom Layer Is a Single Lab Reading

The 0 to 100 Performance circle everyone stares at comes from a tool called Lighthouse, which loads your page once on a simulated device. The report says so in small print. On the mobile tab, when I tested, it said it was emulating a Moto G Power over slow 4G, a mid-range phone on a slow connection that may be noticeably slower than what your own customers carry.

Google's documentation groups the score as 90 and above for good, 50 to 89 for needs improvement, and below 50 for poor. The score itself is a weighted blend of five metrics. According to Lighthouse's scoring documentation, Total Blocking Time carries the most weight at 30%, followed by LCP and CLS at 25% each, with First Contentful Paint and Speed Index at 10% each.

Notice that INP is not among those five. The Web Vitals article explains why: tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP, because there is no user input. Put simply, one of the three metrics Google actually judges you on is not in the score circle at all.

So why does the bottom layer swing? The Lighthouse documentation lists causes such as A/B tests or changes in the ads being served, internet traffic routing changes and testing on different devices. The PageSpeed Insights documentation adds local network availability, client hardware availability and client resource contention. It is the blood pressure reading taken while your heart is still racing.

When the Report Says There Is Not Enough Real-User Data

Plenty of small business sites see this message in the top box, and many owners assume something is wrong. All it means is that CrUX has not collected enough data for that page. Chrome's documentation says pages and origins must be publicly discoverable and have enough visitors to form a statistically significant dataset.

When a single page does not have enough data, PageSpeed Insights falls back to origin-level data, which covers all user experiences across every page of the site. If the whole origin still lacks data, the box stays empty. For a smaller business site without heavy traffic this is completely normal. It says nothing about whether your site is fast or slow. It just means the log does not have enough pages in it yet.

In that case the bottom layer is all you have, and that is fine. Just use it knowingly: run it several times and look at the overall picture rather than judging from a single run.

The Diagnostics at the Very Bottom

Scroll below the score circle and you will find a long list under Insights and Diagnostics, with items such as "Reduce unused JavaScript", "Improve image delivery" and "Render-blocking requests", each with an estimate of how many KiB or milliseconds could be saved.

This section is a toolbox for the people who build the site, not a verdict. The report itself notes that some of these numbers do not directly affect the Performance score. You do not need to understand every line. Note down the top two or three items with the biggest estimated savings and pass them to your web team to interpret. Anything that only saves a few KiB can safely wait.

Here is an example from our own mobile report on the day I tested. The top item was render-blocking requests, with an estimated saving of about 340 milliseconds, followed by improve image delivery, with an estimated saving of about 122 KiB. Those two lines are what I would hand to the team first. The cache lifetime item, which would only save 4 KiB, can comfortably go to the back of the queue.

Real Numbers From Our Own Site, on the Afternoon of 28 September 2026

Enough theory. Let me open the report for tumwebsme.com itself, uncut. Today I analysed our homepage twice, about five minutes apart, and nobody changed anything on the site in between.

On the first run, at 13:39, the Performance score was 68 on mobile and 65 on desktop. A typical owner seeing those numbers would feel their stomach drop.

On the second run, at 13:44, mobile rose to 89 and desktop to 94. Same site, same page, five minutes apart.

Looking inside, the metric that swung most was desktop Total Blocking Time: 1,700 milliseconds on the first run and 190 milliseconds on the second. Because that metric carries 30% of the score, the whole score jumped with it.

Now look at the top layer. On both runs the real-user box showed exactly the same numbers, because it is 28 days of accumulated data (collected from 30 August to 26 September 2026). Our homepage did not have enough URL-level data on its own, so the report fell back to data for the whole site (the origin), exactly as described above.

On desktop, the Core Web Vitals assessment passed: LCP 1.4 seconds, INP 87 milliseconds, CLS 0.01. In other words, that first-run score of 65 did not reflect what customers on computers actually experience at all.

If you press Expand view in that box, you will also see a colour bar splitting visits into three bands. For our desktop LCP it showed 94% good, 4% needs improvement and 1% poor. That bar is often easier to read than a single number, because it tells you what share of customers had which kind of experience. In this case only a very small share waited more than 4 seconds for the page.

On mobile, the assessment failed, and I will not gloss over that. LCP was 3.2 seconds, over the 2.5-second threshold, in the needs-improvement band, and INP was 550 milliseconds, well over the 200-millisecond threshold. CLS was 0, which is fine.

The lesson I want you to take from these numbers is this: our second mobile run scored 89, almost green. Looking only at the circle, we might think the site is nearly perfect. But our real mobile problem is INP, which the score circle cannot measure in the first place. If we paid someone today to push the circle to 100, the problem our mobile customers actually experience might still be sitting right where it is. So our team's next job is tracking down which buttons or scripts make the page slow to respond on mobile.

"But a Red Score Still Means the Site Is Slow, Doesn't It?"

That is the question I hear most, and there is real truth in it. I am not going to argue with that. If the circle is red every time you run it and never climbs above 50 no matter how many times you try, that is a signal worth paying attention to. Lab scores are also genuinely useful, because they point developers toward where a problem is likely to be. Field data can tell you what customers experienced, but it cannot tell you why.

What I would urge caution about is using a single run as the reason to spend money, especially when the top layer of the report already says you pass. The Lighthouse documentation has a line I like a lot: taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94. The closer you get to 100, the harder every point becomes, and the people visiting your site may never feel the difference.

If you want to understand how much site speed affects SEO and sales, and what the options are for making a site faster, I covered that in detail in our guide to website speed and SEO.

Why Learning to Read It Now Pays Off Before There Is a Problem

Field data covers the previous 28 days. That means if your web team fixes something today, the numbers in the top box will shift gradually over the following weeks, not overnight. If you did not note your starting numbers before the fix, you will have no way of knowing whether the work you paid for actually made a difference.

There is another benefit too. An owner who can read the report gets through conversations with their web team much faster. Instead of sending a screenshot of a red circle with "please make it faster", you can say "INP fails on mobile, desktop already passes". The team knows immediately where to look. The job gets shorter, and the cost usually narrows with it.

What You Can Judge Yourself in Three Lines

If you have no time to read the whole report, these three things are enough. Always start with the top box. If it has data and says Passed on both mobile and desktop, your site is within the range Google considers good, and the circle below is nothing to panic about.

If that box says Failed, see which metric is orange or red and write down its name and value. That is the clearest brief you can give your web team.

And if there is no real-user data at all, run the lab test three to five times, write down every score, and use the middle value as your baseline. Do not use the single worst or single best run.

Other Tools That Use the Same Data

The same real-user data behind the top box of PageSpeed Insights shows up in other places you may already use. The closest is the Core Web Vitals report in Google Search Console, which groups URLs with similar issues so you can see the whole site on one screen instead of testing page by page. If you have never opened Search Console, our beginner's guide to Google Search Console is a good companion to this article.

The same Lighthouse that powers the bottom layer is built into Chrome DevTools on every computer. Most web teams run it from there while they work, and its score can differ from PageSpeed Insights again, because the machine and network doing the measuring are different. That is normal.

One more thing worth knowing: if the top box shows that TTFB, the time it takes the server to send its first response, is slow, the cause may lie with your hosting rather than the page itself. I wrote about the questions to ask before signing a hosting contract in our article on reading a hosting quote.

A Five-Step Plan Before Paying for Speed Optimisation

1. Record a baseline: Run PageSpeed Insights on your homepage and the pages customers visit most, on both the mobile and desktop tabs. Save a screenshot of the top box, including the collection date range.

2. Run the lab test several times: Analyse three to five times and write every score into a table, so you can see how widely your site swings.

3. Turn the problem into one sentence: For example, "INP fails on mobile, LCP passes", rather than "the site is slow".

4. Send it to your web team with questions: Ask what they think the cause is, which metric they will fix, how far they expect the numbers in the top box to move, and within how many weeks.

5. Agree on how success is measured before work starts: Judge the result on real-user data after at least 28 days, not on a single score circle on handover day.

How to Tell Whether the Work You Paid For Worked

Once your web team has finished, come back to the top box after roughly 28 days and compare it with your baseline screenshot. Any metric that used to fail should have moved closer to, or into, the good range. Check the Core Web Vitals report in Search Console as well, to see whether the number of URLs in the good group has gone up.

As for the score circle, if repeated runs after the fix give a higher middle value, that is a good sign. Treat it as supporting evidence, not the verdict.

If you are planning a new website and want to know how each of our packages looks after site performance, you can find the details on the TumWebSME website packages page.

Closing

Back to the exam room one last time. The blood pressure reading taken right after the stairs was not lying to you. It was simply telling the story of those five minutes. The month-long log is what the doctor uses to decide what, if anything, to treat. PageSpeed Insights is the same. The score circle is the five-minute reading. The top box is your customers' log. Read the log first, then use the five-minute reading to help find the cause.

If you open your own report and are still not sure where to start, send us a screenshot and let's talk it through. We will help you work out what those numbers are telling you and what is worth doing first.

Follow TumWebSME

Stay up to date on web development and online marketing:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

Contact and Service Enquiries

• 088-983-9386 (Khun Ploy)

• 099-856-3198 (Khun Saennan)