How to Test Website Speed, and Why One Page Scored Both 82 and 93 With No Changes

Key takeaways

• Start with PageSpeed Insights. It is free, needs no account, and gives both a simulated test and, when your site has enough visitors, real user data.
• One run proves very little. Our home page scored 97, 98 and 100 on mobile and 82 and 93 on desktop, on the same morning, with no change to the page.
• Trust real visitor data over the score. web.dev says field data is what to use when setting priorities. The lab score is for finding causes.
• Many small sites have no field data. Google needs enough visits to report it. Then use the median of several lab runs.
• Test the page people land on, not only the home page, and write down the date, device and result each time.

The short answer

To test your website speed, open PageSpeed Insights, paste the full address of the page, and run it. Read the top section first: if it shows real user data, that is your answer. If it says there is not enough data, run the test three times and take the middle score. Then look at the specific metrics below the score and the suggested fixes.

Once you know what is slow, our guide to website speed optimization for small sites gives the fixes in order. This post only covers the testing.

What the search results do not show

On 3 November 2026 we searched Google (United States, English) for "website speed test" and "how to test website speed". Nearly every result is a tool: Pingdom, PageSpeed Insights, GTmetrix, WebPageTest, Uptrends, KeyCDN, Calibre, plus a Cloudflare explainer and a Webflow list.

The roundups list tools and features. Rank Math's list, for example, advises testing more than once, yet it does not name a test page or show results to back that up. None of the pages we read shows one page tested repeatedly, so a reader cannot see how much the score moves by itself. A popular comment in an r/TechSEO thread shown in the results made a similar point: decide what to fix from the waterfall and diagnostics, not the composite score.

So we measured it.

We tested one page five times

The page was the amariq.com home page, tested on 3 November 2026 at about 11:20 Bangladesh time. PageSpeed Insights ran Lighthouse 13.6.0 for each result. We added a harmless query string to the address for each new run, so that the tool produced a new analysis rather than showing a recent one.

Five runs on one page is a small sample, and it is a snapshot of our own site, not a benchmark. Still, it teaches four things.

1. The score moved by 11 points on desktop with no edit. A change of that size after a redesign would look like a clear result. Here it was noise.
2. Speed Index ranged from 1.7 to 4.6 seconds on mobile. That is the widest swing in the table.
3. Desktop scored below mobile. Most people assume the reverse. Blocking time was the cause: 400 ms and 210 ms on desktop against 70 to 130 ms on mobile. We read that as a sign that the score weighs each device against its own expectations, so the two numbers should not be compared.
4. LCP stayed well inside the target on every run. Google's limit for good is 2.5 seconds. So the most useful answer from this test was steady across all five runs, while the headline score was not.

Google's PageSpeed Insights documentation expects this. It blames run-to-run change on local network availability, client hardware availability and client resource contention.

Lab data and field data, in plain terms

This is the idea that makes every speed test easier to read.

• Lab data is one simulated visit, on one device and connection, at one moment. It is repeatable enough to debug with. It cannot tell you what real people felt.
• Field data is what real Chrome users experienced over the previous 28 days, reported at the 75th percentile. It is the truth about your visitors, but it arrives slowly and only if you have enough of them.

They can disagree. web.dev's article on lab and field differences lists reasons: visitors arrive with cached files, screens of different sizes change which element counts as largest, and lab layout shift covers only the load, while real visitors keep scrolling. It says to set priorities from field data, and to use lab data to look for gains for visitors on slower networks and older phones.

A good lab score does not guarantee a good real experience either. Google's documentation says so directly, and it treats any score of 90 or more as good.

The targets to compare against

From the same Google documentation, read on 3 November 2026. These apply to real user data. The first three are the Core Web Vitals, and the Search Console report uses the same ranges for them.

The lab score has its own scale: 90 or above is good, 50 to 89 needs improvement, and below 50 is poor. Lab tests cannot measure INP because nobody is tapping, so they report Total Blocking Time as a stand-in. Our run shows why that matters: a blocking time of 400 ms says the page was busy during that simulated load, and it does not tell you how real taps went.

Which tool answers which question

We ran only PageSpeed Insights for this post. The rest of the table comes from each maker's own page, read on 3 November 2026, not from our testing.

Two details to watch. GTmetrix's default of an unthrottled connection is far kinder than a phone on mobile data, so do not compare its number with a PageSpeed mobile result. And its home page gives both 25 and 28 as its count of test regions, so check the list if a certain city matters to you.

The documentation can lag as well. Google's page says Lighthouse simulates a Moto G4, while the report we got on 3 November 2026 named an emulated Moto G Power on slow 4G. Trust the report's own environment notes, which also show the date of the test.

A testing routine that avoids the noise

1. Pick three pages: the home page, your main service or product page, and a popular blog post. Different templates load differently.
2. Use the final address. Include https and www if your site uses them, so you are not timing a redirect as well.
3. Check the real user section first. If it says the page lacks data, look for the origin summary, which covers the whole site. If that is missing too, you only have lab numbers.
4. Run the lab test three times on each page and record the middle score, per device. Three is our suggestion, not Google's.
5. Note the metrics, not only the score. LCP and blocking time tell you what to fix. The score tells you nothing about the cause.
6. Keep a dated spreadsheet. After a change, wait, retest the same way, and only believe a shift that is larger than your usual spread. For real user data, allow for the 28-day window, because a fix takes weeks to show fully.
7. Then test by hand. Open the page on an ordinary phone on mobile data. Our mobile website design guide has a short checklist. A page can score well and still feel awkward under a thumb.

You can also run our free website audit, which includes a speed reading along with other checks, and turn the results into a plan with the small business audit checklist.

When speed is not your real problem

Check these before you pay for speed work.

• Your field data is already good. Chasing a lab score from 92 to 100 will not help real visitors much.
• Few people visit at all. Then the bigger gap is usually being found on Google.
• People visit and do not get in touch. Look at the message and the page structure first.

On the other hand, slow pages on every template, with poor field data, can point to the build or the hosting rather than one large image. Our notes on hosting costs can help you judge whether a move would be worth it.

How we help at Amariq

If your results point to images, scripts, fonts or a heavy template, we can fix the cause on Webflow, Framer, WordPress, Shopify, Wix, Squarespace or a custom build. We quote from the scope, never by the hour, with 40% to start, 30% at design approval and 30% before launch. See our website optimization service.

Frequently asked questions

What is the best free website speed test?

For most owners, PageSpeed Insights, because it is free, needs no account and is the one place that combines lab results with Google's real user data. Add GTmetrix, Pingdom or WebPageTest when you want a detailed file-by-file view.

What is a good PageSpeed score?

Google counts 90 or above as good, 50 to 89 as needing improvement and below 50 as poor. A good score does not guarantee a good experience for real visitors, so check LCP, INP and CLS field data as well, when you have it.

Why does my speed test score change every time?

Network conditions and the state of the test machine change between runs. Our own home page moved from 82 to 93 on desktop with no edit. Run several tests and use the middle one, rather than reacting to a single number.

Why is my desktop score lower than my mobile score?

It can happen, as it did for us. Our desktop runs had higher blocking time than our mobile runs. Treat the two scores as separate tests and look at which metric is pulling the score down.

Why does PageSpeed Insights show no real user data?

The page or the site does not have enough visits from Chrome users in the dataset, or it has only just gone live. PageSpeed Insights falls back to the whole-site figure when it can. Otherwise, rely on repeated lab tests.

How long until a speed fix shows up?

Lab tests change at once. Field data covers a trailing 28 days, so it improves gradually over about four weeks. The Search Console validation works on the same 28-day period.

Which page should I test?

The pages people land on most, which you can find in your analytics or the Search Console Performance report. Test one page of each template rather than only the home page, because a clean home page can hide a slow blog or product template.