You ran your home page through a speed tool on Monday and got a score in the thirties on mobile. Your web designer ran it on Tuesday and sent you a screenshot in the seventies. A friend tried another tool and told you the page “loads in 1.2 seconds”. All three of you are looking at the same website, and none of you is lying.
That is the usual starting point, and it is why learning how to test website speed properly matters more than picking the “right” tool. A speed test is a measurement. Like any measurement, it only means something when you know what was measured, under which conditions, and whether you would get the same answer tomorrow. This post sets out a method you can repeat, so that the numbers you collect actually tell you whether the site got faster or slower.
If you want the wider picture first (what makes sites slow and how the fixes fit together), our website speed guide is the starting point for the whole topic. Here we stay with the measuring.
What “properly” means before you open any tool
A proper test has four qualities. It answers a specific question. It is repeatable, so the same page under the same conditions gives roughly the same result. It records the conditions alongside the number. And it compares like with like: mobile with mobile, the same page with the same page, before with after.
Most confusion comes from breaking the last one. A desktop result from one tool compared with a mobile result from another is not a comparison. Neither is a test run while you were logged in to WordPress compared with one run from an incognito window. The page you see as an administrator is often a different page: the cache is skipped, an admin bar loads, and extra scripts may run.
Choose which pages to test
Testing only the home page is the most common shortcut, and it gives a lopsided view. Visitors often land elsewhere: a blog post from Google, a product page from an ad, a service page from a link a customer shared. Pick a small fixed set, usually four to six pages, and keep using the same set every time.
- The home page, because it usually carries the heaviest design.
- Your most visited landing page, which you can find in your analytics.
- One page of each template: a blog post, a service page, a product or category page if you sell online.
- The page that makes you money: the contact page with the enquiry form, or the cart and checkout on a store.
Write the exact URLs down. A URL with a tracking parameter, or with and without the trailing slash, can be treated as a separate page by caches and by some tools.
Match the tool to the question
Each common tool is good at a different job. You do not need all of them, but you should know which one answers the question you are asking.
| Your question | A tool that answers it |
|---|---|
| How do real visitors experience this page, and does it pass Core Web Vitals? | PageSpeed Insights, field data section (only if the site has enough traffic) |
| What is slowing the page down in a controlled test? | PageSpeed Insights lab section, or Lighthouse |
| Which single file or server is holding everything up? | A waterfall chart in GTmetrix, WebPageTest or Chrome DevTools |
| How does the page load for someone in another country or on a slow phone network? | WebPageTest, where you choose the location and connection |
| What exactly does my browser download, and how big is each file? | The Network tab in Chrome DevTools |
Each of these has its own walkthrough in this section. Start with reading a PageSpeed Insights report from top to bottom, since that is the tool most owners open first. If a developer has sent you a Lighthouse result that does not match, why Lighthouse and PageSpeed Insights disagree explains the gap. For the bar-chart view of every request, see how to read a GTmetrix waterfall; for testing from chosen locations and devices, our beginner’s guide to WebPageTest; and for checking a page from your own browser, using the Chrome DevTools Network tab.
If you just want a quick first reading before learning any of these, our free website speed test will give you one. Treat it as exactly that: a rough starting point, not a full diagnosis, and something to repeat rather than trust from a single run.
How to test website speed properly, step by step
This is the routine we would follow on any site before touching anything. It takes longer than one click, but you only build the habit once.
- Log out, or use a private window. You want the page an ordinary visitor gets, including the cached version if the site has page caching.
- Load each page once before you start measuring. On a cached site, the first request after a cache clear builds the page and is slower than normal. A single warm-up visit means your tests measure the usual state, not the rare one. (If the first visit is what you are investigating, test it deliberately and label it.)
- Test mobile and desktop separately. Most tools test one or the other, or show them on separate tabs. Mobile tests usually emulate a slower phone on a throttled connection, so expect lower numbers. Record both, and do not average them together.
- Run each test several times. Three runs is a sensible minimum, five is better for pages with ads or many outside scripts. Use the middle result (the median), not the best one and not the average.
- Keep the location and connection the same. If a tool lets you pick a test server, pick one and stick to it. Changing from a server near your host to one on another continent changes the result for reasons that have nothing to do with your site.
- Test at similar times. On shared hosting, the server can be busier in the evening than at dawn. If you tested before a change at 7 a.m., test after it at roughly 7 a.m. too.
- Write everything down, including the things that seem obvious today.
Numbers moving between runs is normal and does not mean the tool is broken. Large swings are worth understanding, though, because they can point to an unstable server or a third-party script that behaves differently on each load.
What to write down each time
A plain spreadsheet does the job. One row per test, with these columns:
- Date and time
- Exact URL
- Tool and, if shown, the test location
- Mobile or desktop
- The median score from your runs
- Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time from the lab test
- Field data result (pass, fail or “not enough data”) if the tool shows it
- Page weight and number of requests, if the tool reports them
- A notes column: “after plugin update”, “sale banner live”, “new chat widget added”
The notes column ends up being the most useful one. Six months from now, when someone asks why the product pages got slower, a line saying “added review widget, 14 May” saves hours of guessing.
Keep the score, but do not let it be the only figure. The individual metrics tell you what changed. A score can stay the same while LCP gets worse and blocking time gets better, and those point to completely different causes.
Testing before and after a change
The real value of a careful method shows up when you change something: a new caching plugin, compressed images, a different theme, a host move. Without a clean “before”, you cannot say whether the change helped.
Run your full set of tests before the change, ideally on more than one day. Make one change at a time where you can. Then repeat exactly the same tests: same URLs, same tools, same locations, same number of runs, similar time of day. If you change three things at once and the page gets slower, you will not know which one did it.
Field data needs patience. The real-user figures in PageSpeed Insights and Search Console are collected over a rolling window of several weeks, so a fix you make today shows up gradually. Lab tests give you the quick answer; field data confirms, later, whether real visitors noticed.
Mistakes that make results meaningless
Testing while logged in
Already mentioned, but it catches almost everyone. A logged-in WordPress session usually bypasses the page cache, so you are measuring a slower page than visitors get, and then fixing a problem they never see.
Testing from your own office connection and calling it “real”
Your fibre line and recent laptop are not what a customer on a budget phone has. Desktop checks on your own machine are fine for spotting changes; they are not a stand-in for mobile visitors.
Keeping only the best run
It is tempting to rerun until you get a nice number and screenshot that one. It feels good and tells you nothing. The median is the honest figure.
Comparing different tools’ scores
A grade in one tool and a score in another are calculated differently. Compare a tool only with itself.
Testing straight after clearing the cache
Unless you are deliberately measuring the uncached page, warm the cache first. Otherwise the “after” result can look worse than the “before” for no real reason.
Ignoring the pages that earn money
A fast home page and a slow checkout is still a slow shop. Checkout and cart pages are normally excluded from caching on purpose, so they need their own tests.
When the testing itself points to the answer
Sometimes a careful round of tests is enough to see the cause. A slow first response on every page points at the server or caching. A fast response followed by a long wait for one large image points at images. Lots of requests to other companies’ domains point at third-party scripts. A page that is fine in one country and slow in another points at distance. Writing results down consistently is what lets you see those patterns, and it gives anyone you bring in later, whether a developer or us, evidence to start from instead of a hunch.
Frequently asked questions
Which website speed test tool is the most accurate?
None of them is accurate in the sense of giving the one true number, because each measures under its own conditions. Field data from real Chrome users, where your site has enough traffic, is the closest to what visitors experience. For diagnosing causes, pick one lab tool, keep its settings fixed, and compare it only with itself.
How often should I test my website’s speed?
Test your fixed set of pages before and after any significant change, such as a theme or plugin update, a new script or a host move. Beyond that, a monthly round of tests is enough for most small business sites, with the same pages and settings each time so the results can be compared.
Should I test on my own phone as well as with online tools?
Yes, it is a useful extra check, especially on an older or mid-range phone using mobile data rather than office Wi-Fi. It shows you how the page feels, including things tools score poorly, such as a menu that responds late. Just do not treat one phone visit as a measurement to compare later.
Why does my site feel fast to me but test slowly?
Usually because your browser has already stored many of the site’s files from earlier visits, and you are on a fast connection and a capable device. Speed tools typically load the page as a first-time visitor on a throttled mobile connection, which is closer to what many new customers get.
If you collect a few rounds of results and still cannot tell what is holding the site back, our website speed optimisation service starts from exactly that kind of evidence and reports before-and-after tests run the same way, so you can see what changed.
All guides in this section
- How to Read a PageSpeed Insights Report, Section by Section
- Why Your PageSpeed Score Changes Every Time You Test
- Is a 100 PageSpeed Score Necessary for Your Website?
- GTmetrix Waterfall Chart Explained, Row by Row
- Lighthouse vs PageSpeed Insights: Why Scores Differ
- How to Use WebPageTest: A Beginner’s Guide
- Check Page Load in Chrome DevTools: The Network Tab
- How to Monitor Website Speed Over Time
- What Is Page Size? Page Weight Explained Simply
- Reduce HTTP Requests: Which Ones Actually Matter
Next in this series: How to Read a PageSpeed Insights Report, Section by Section
