Run the test on the pages people actually land on, configured for a phone on a mobile connection, and read the diagnostics rather than the score. The score is a weighted summary that can move without the experience changing, while the diagnostics name specific files and specific problems you can act on.
Before running anything
Do the free test first, because it takes a minute and frequently makes the tools unnecessary.
Open your site in a private browsing window, on an actual phone, with wifi turned off. That removes the two advantages you have over a first-time visitor, which are a cached copy and a strong connection. If it feels slow, it is slow, and no tool is needed to establish that.
The tools tell you why, which is the next question rather than the first one.
Which pages to test
Not just the homepage, which is the default assumption and usually the wrong page.
Test the pages people actually land on, which for most small business sites means the main service pages arriving from search. Check your analytics for the top three landing pages and test those. A homepage optimised while the busiest service page is slow is a common and entirely avoidable mismatch.
Configuring the test
- Choose the mobile result, which most tools present alongside desktop. Mobile is where most visitors are and where problems concentrate.
- Check the test location where the tool allows it. A test run from another continent tells you little about local visitors.
- Run it more than once. Individual runs vary, sometimes substantially. Three runs and a middle value is more honest than one.
- Test after clearing any cache, since a page served warm from a caching layer is not what a first visitor gets.
What the score is and is not
A weighted composite of several measurements, presented as one number out of a hundred.
It is useful as a rough direction and it is not the objective. A score can improve while the experience does not, because the composite can be shifted by deferring things the test measures. Equally a site with a mediocre score can be perfectly pleasant to use.
The reason to look past it is practical rather than philosophical: the score tells you there is a problem, and the diagnostics below it tell you what to do, which is the part that changes anything.
The measurements worth understanding
| What it measures | Why it matters |
|---|---|
| When the largest visible element appears | The closest match to when a visitor feels the page has arrived |
| How much the layout shifts while loading | Why people tap the wrong thing. Caused by images and embeds without reserved space |
| How long the page is unresponsive | The page looks ready and taps do nothing, usually because scripts are still running |
| When anything appears at all | How long the visitor stares at a blank screen, which feels longer than it is |
Reading the diagnostics
The list below the score is where the value is, and it is ordered by estimated saving.
For a small business site the same items appear repeatedly: images larger than the size they display at, images in older formats, unused code, and third-party scripts. The tool names the specific files, which turns a vague performance problem into a list.
Two cautions. The estimated savings are theoretical maximums rather than promises. And some recommendations require a rebuild rather than a tweak, so it is worth separating what is a twenty-minute fix from what is a project.
What to ignore
- Chasing a perfect score, which produces diminishing returns quickly and occasionally makes the experience worse.
- Recommendations about third-party code you cannot change, such as the internals of an embedded map. The action there is whether to keep the embed, not how to optimise it.
- Single alarming runs. Variability is normal; a pattern across several runs is not.
- Desktop scores, unless your audience is genuinely desktop.
What to do with the first result
Write down the numbers with the date, before changing anything. Not to celebrate, but so the next test has something to compare against.
Then work the diagnostics in order of estimated saving, doing the image work first, since on most small business sites images account for the large majority of the weight and resizing them changes nothing visible.
Retest after each change rather than making six at once, so you learn which one mattered. And check the field data over the following weeks if your site has enough traffic for it, since that reports what real visitors experienced rather than what a simulated one did. Why the experience matters more than the number is set out in what makes a website feel fast.
Frequently asked questions
How do I test my website speed?
Run a speed tool on the pages people actually land on, choosing the mobile result. Before that, open the site in a private window on a real phone with wifi off, which takes a minute and often answers the question.
Which pages should I test?
The top three landing pages from your analytics, which for most small business sites are service pages rather than the homepage. Optimising the homepage while the busiest service page is slow is a common mismatch.
Should I aim for a perfect score?
No. The score is a weighted composite that can improve without the experience changing, and chasing the last points produces diminishing returns and occasionally a worse page.
Why do I get different results each time I test?
Individual runs vary, sometimes substantially, depending on network conditions and server load. Run it three times and take a middle value rather than acting on a single alarming result.
What part of the report should I act on?
The diagnostics below the score, which name specific files and are ordered by estimated saving. For most small business sites that means oversized images, old formats, unused code, and third-party scripts.
What should I fix first?
Images, in nearly every case. They usually account for the large majority of page weight, and resizing and compressing them changes nothing visible on the page.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Never run a speed test on your own site?
We test the pages people actually land on, separate the quick fixes from the rebuild items, and record a baseline you can measure against.
Start a Conversation