How to measure site speed, and why the PageSpeed score changes every time.

Site speed is measured in two separate ways: with the values real visitors experienced over the last 28 days (field data) and with a test run on a single simulated device (lab measurement). The 0–100 score in PageSpeed Insights comes from the lab test, and it changes every time because the network, the device and the measuring environment are slightly different on each run.

Testing the same page twice a few minutes apart and seeing two different scores is a common source of confusion. Most of the time it does not mean the site has changed; the measurement itself has changed. Google’s own documentation also says that most of the score’s fluctuation comes not from the measuring tool but from the environment. Reading it soundly starts with separating the two ways of measuring.

This article explains measurement from the point of view of the person who commissions the site: what each tool tells you, when to trust the score and when not to. We explain the technical difference between the two ways in detail in the field data and lab measurement guide. If you would like us to measure your site’s speed, the method is on the site speed optimization page.

How do you read a PageSpeed Insights result?

When you enter an address in PageSpeed Insights, the result comes in two layers. The upper layer is data collected from real Chrome users: according to PageSpeed’s documentation, the LCP, INP and CLS values from the previous 28-day collection period. The criterion, as web.dev defines it, is 75 percent of visits; if LCP is within 2.5 seconds, INP within 200 milliseconds and CLS within 0.1, the page passes Core Web Vitals. The Core Web Vitals report in Search Console is based on the same real-user data.

The lower layer is the lab test: PageSpeed opens the page with a tool called Lighthouse, on a single simulated device and a simulated network. The big colored score is the result of this test. Under the version 10 weights documented by Lighthouse, 30 percent of the score comes from Total Blocking Time, 25 percent from LCP, 25 percent from layout shift, and the remaining 20 percent equally from First Contentful Paint and Speed Index. In other words, the score is not a summary of real-user data but the weighted report card of a single test.

If the page has no field data of its own, PageSpeed falls back to origin-level data covering all pages of the site; if that is not enough either, the upper layer does not appear at all. This does not mean your site is bad; it only means not enough visits have been collected.

Why does the PageSpeed score change every time?

PageSpeed’s documentation lists the main sources of variability: the state of the local network at that moment, the hardware of the machine running the measurement and other tasks competing for resources on the same machine. Lighthouse’s documentation adds others to the list: A/B tests running on the site or changing ads, differences in how internet traffic is routed, test devices of different power, and browser extensions and antivirus software that inject code into the page. Your server’s load at that second also makes every run slightly different.

The practical consequence: a difference of a few points between two runs is not information but noise. To tell whether a change has worked, you need to do several runs with the same tool, at the same time of day, with the same device profile, and look at the median.

Lighthouse said 87, real Chrome 98: where did the difference come from?

We experienced this on our own site. Our lab score was stuck at 87; the threshold we had set ourselves was 88. We searched the site’s code for where the single point was lost and could not find it, because the loss was not in the site. Lighthouse opens Chrome with its own launcher, and the default flag list of that launcher turns off one of Chrome’s features. In that configuration, the first frame was presented on screen late even though the page was ready: on the live home page, the first paint came at 2.3–2.5 seconds instead of 0.4 seconds. When we removed only that one line from the list and touched nothing else, the same page scored 97–98; with the tool’s default it swung between 78–87. The difference arose without a single byte changing on the site.

The second half of the story is instructive too: our first diagnosis was wrong. We first thought the culprit was the transition effect between pages; when a minimal test page with no transition effect at all was held back in the same way, that reading collapsed. Today we report both numbers together: the binding one is the measurement in the configuration closest to the Chrome the visitor uses; the tool’s default number stays in the report under the name “jury view,” because a client or an award jury will most likely see that one. The full experiment and the steps to reproduce it: Why does Lighthouse say 87 and real Chrome 98?

The browser the measuring tool opens is not the visitor’s browser.

Why is a single test not enough?

Because a single run measures a moment, not a distribution. This site’s performance contract reads the lab score not from a single run but from the median of at least five runs. In the measurement of 23 September 2026, the median performance score was 99, the median Total Blocking Time 21 milliseconds and lab layout shift 0. The median prevents a single lucky or unlucky run from deciding the outcome.

The same rule works for your own measurement: before and after a change, do five runs each in the same time slot and compare the two medians. Comparing two single runs taken on different days is comparing two different weather reports.

Why does field data lag 28 days behind?

Real-user data comes from the Chrome User Experience Report (CrUX) and, as web.dev explains, shows the distribution of the last 28 days. A fix you make today enters that window with a little more weight every day; its effect shows up not in a day but gradually over weeks. The validation that starts when you tell Search Console you have fixed an issue is also a 28-day monitoring period.

The second limit is the traffic threshold. According to Chrome’s methodology documentation, a page must be publicly accessible and have a sufficient number of visitors to appear in this data; the exact threshold is not disclosed. On a new or low-traffic site, field data may never form. In that case the decision is made with lab measurement and with your own real-user measurement that can be added to your pages.

What does the Core Web Vitals report in Search Console tell you?

Search Console shows the same real-user data for the whole site. It sorts not individual addresses but groups of pages that deliver a similar experience into poor, needs improvement and good; a group’s status is set by the worst of the three measures. Mobile and desktop are reported separately. This report answers the question “in which page family, which measure, on which device is it failing?”; PageSpeed then shows the cause for a page in that family.

Speed’s place in search also needs to be weighed correctly. Google Search Central writes that Core Web Vitals align with what its core ranking systems seek to reward; the same documentation also says that Google tries to show the most relevant content even if the page experience is weak. Speed does not replace good content; it makes good content readable.

What are the most common mistakes when measuring?

• Looking at the desktop score and skipping the mobile result — a large share of visitors come from phones, and a phone’s processor is slower; details in the mobile performance gap guide.
• Deciding on a single run — a difference of a few points is noise; look at the median.
• Measuring in a browser with extensions installed or while logged in as an administrator — both add load to the page that the visitor does not see.
• Generalizing the home page’s score to the whole site — product and article pages can give completely different results.
• Making the score the goal — the score is a summary; what really matters is which underlying measure is failing.
• Expecting field data to improve the day after a fix — the window is 28 days.

What should you ask about a speed report?

When you are given a speed report, whether by your own team or from outside, check whether these five things are clearly stated: whether the numbers come from field data or the lab; if it is a lab result, how many runs it is the median of and with which device profile it was taken; which pages were measured; the date of the measurement; and whether the cause of slowness is based on a browser trace or on a guess. If one of these five is missing, the number may not be wrong, but it cannot be discussed.

The step after reading the measurement is finding the cause. We have collected the eight common causes of slowness and how to spot each one in the article why your website is slow to load, and the WordPress-specific breakdown in WordPress site loading slowly.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.