All articles · Performance

Website Speed Test: How to Check Your Site Speed and Read the Results

By PerfoMetrix Team·October 29, 2026·7 min read

Running a website speed test takes a minute. Understanding what it tells you takes a little longer, and that is where most people get stuck. The report shows a big score, a row of acronyms and a long list of suggestions, and it is not obvious which of them matter for your visitors.

This guide explains what a speed test actually measures, why two tests of the same page can disagree, and how to run one that gives you a result you can trust. It ends with a short order of work, so the first hour you spend on speed goes where it counts.

Quick answer

If you only have five minutes:

1. Test your most important page, usually the home page or a top landing page, on mobile.
2. Look for real-user data first. If it is there, it is the result Google and your visitors see.
3. Check three numbers against their limits: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less.
4. Treat the 0–100 score as a summary, not a target. A page in the 90s is fast; chasing 100 rarely pays off.
5. Fix the biggest item first, usually large images, slow server responses or too much JavaScript, then test again.

What a speed test measures

A speed test loads your page and records how long it takes before visitors see something, before they see the main content, and before the page responds to them. It reports those moments as separate metrics, because “fast” means different things at different points of a visit.

There are two kinds of data behind those numbers, and good tools show both:

• Lab data comes from a single, controlled page load. Tools such as Lighthouse (the engine behind Google’s PageSpeed Insights) load the page in a simulated environment, typically a mid-range phone on a slower mobile connection. Lab data is available for any public page, immediately, and is repeatable enough to check whether a change worked.
• Field data, also called real-user data, comes from actual visits. For Chrome users who share usage statistics, Google collects timings into the Chrome UX Report (CrUX) and publishes them for pages and sites with enough traffic, over a rolling 28-day window. It reflects your visitors’ real devices and networks, but small sites often have none, and changes take weeks to show.

When the two disagree, field data describes what people experienced; lab data helps explain why. Our guide to Core Web Vitals field data covers where the numbers come from, and the post on Lighthouse versus real-user data goes through the common reasons they differ.

The Core Web Vitals and their thresholds

Google groups three metrics as the Core Web Vitals. Each one has a “good” threshold, and a page passes when at least 75% of its visits (the 75th percentile) meet it:

The 75th percentile matters. It means a page that is fast on your office laptop but slow for a quarter of your visitors does not pass. It also means a few unlucky visits on a bad connection don’t fail you.

INP needs real interactions, so lab tools can’t measure it directly. They report Total Blocking Time instead, which estimates how long the page was too busy running scripts to respond. A high TBT in the lab usually means a weak INP in the field.

You will also see supporting metrics: Time to First Byte (how quickly the server starts answering), First Contentful Paint (when anything appears) and Speed Index (how quickly the visible area fills in). They are useful for diagnosis. Our guides on Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift explain each vital in more depth. Google’s own overview is on web.dev.

Mobile versus desktop results

Most speed tests offer both, and the mobile result is almost always worse. That is expected: the lab test simulates a slower processor and network for mobile, and phones really do take longer to run JavaScript and decode large images.

Start with mobile, for two reasons. On most sites the majority of visits come from phones, so it is where most people feel the delays. And Google uses the mobile version of a page for indexing, so the mobile experience is the one search evaluates. A page that only performs well on desktop has its problems in the place that matters most.

Field data is split the same way. A site can pass the Core Web Vitals on desktop and fail on mobile; look at the mobile figures before celebrating.

How to run a test you can trust

A single lab run is a sample, not a verdict. Network conditions, server load and third-party scripts all vary, so scores move a few points between runs even when nothing changed. A few habits make results comparable:

• Test the right pages. The home page is a start, but also test the pages that earn money or traffic: a product page, a service page, a popular article. Each template (home, category, product, post) can behave differently.
• Run it more than once. Take three runs and use the middle result. One very good or very bad run is usually noise.
• Test what visitors see. Log out first. A logged-in administrator often gets an uncached page with extra toolbars, which is slower than what the public gets. Equally, don’t test a page that only you can see.
• Use the public address. Test the exact URL people land on, including https:// and the right www or non-www form, so you don’t measure an extra redirect.
• Warm the cache once. If your site uses page caching, the first request after a change may be slower. A second run shows what most visitors get.
• Change one thing at a time. If you compress images and remove a plugin on the same day, you won’t know which one helped.

Keep a simple note of date, page, score and the three vitals. It makes the next test meaningful.

How to read the score without chasing 100

The 0–100 Lighthouse performance score is a weighted summary of the lab metrics. It is grouped into three bands: 90 and above is good, 50–89 needs improvement, below 50 is poor. Our Lighthouse performance score guide explains which metrics carry the most weight.

Three things to keep in mind:

• The score is not the ranking signal. Google’s page experience assessment uses Core Web Vitals from real users, not the Lighthouse lab score. A 78 with passing field data is in better shape than a 95 with failing field data.
• The last points are expensive. Going from 40 to 80 usually means fixing a few big problems. Going from 92 to 100 can mean removing features visitors use, such as chat, video or maps. Stop when the page is fast for people, not when the number is round.
• Suggestions are not equal. The list of opportunities is sorted by estimated savings. Something marked as saving several seconds is worth an afternoon; something saving 50 milliseconds may not be worth a meeting.

If a tool shows the score next to passed and failed checks, read the failed ones as a to-do list and the score as a progress bar.

What to fix first

Most slow pages have one or two dominant problems. Look at which metric is furthest from its limit, then start with the cause that usually goes with it:

• Slow LCP. Look at the main image: is it far larger than it is displayed, in an old format, or lazy-loaded even though it is at the top? Then check the server response time. If the HTML takes more than about a second to arrive, everything else waits for it.
• High TBT or poor INP. Count the scripts. Sliders, chat widgets, tracking tags, page-builder add-ons and plugins each add JavaScript that the phone has to run before it can react.
• High CLS. Look for images and embeds without set dimensions, ads or banners that push content down, and web fonts that swap in with a different size.
• Everything is slow. Then the page is probably simply heavy. Check the total download size and the number of requests before tuning details.

After each change, run the test again in the same way you ran the first one. Lab results show whether the fix worked within minutes; field data follows over the next few weeks as new visits replace old ones in the 28-day window.

Make speed a habit, not a project

Sites get slower over time. A new plugin, a larger banner, another marketing tag: each change is small, and together they undo last year’s work. Testing your key pages once a month, or after every noticeable change to the site, catches that drift while the cause is still easy to find.

If you want a starting point, you can run a free scan of any page. PerfoMetrix runs Lighthouse through PageSpeed Insights, shows Chrome’s real-user data when the page has enough traffic, and lists each finding with an explanation of what to change. Whichever tool you use, test the same pages the same way each time, and judge the result by what your visitors experience.

Tags:website speed testpage speedCore Web VitalsLighthousefield data