Guide
How to test website speed and read the results
To test website speed, run your key pages through a free tool such as PageSpeed Insights or WebPageTest, test on a mobile profile, repeat the test several times and record the same numbers before and after every change. Look at real-visitor field data where it exists, and focus on loading, responsiveness and stability rather than a single score.
Quick method
A reliable test in six steps
Pick your pages
Test the homepage, one typical content page and your most important page, such as a product or contact page.
Choose a tool
Start with PageSpeed Insights, and use WebPageTest or browser developer tools for detail.
Test mobile first
Most visitors use phones, which are slower than your computer.
Run it three times
Take the middle result, because single runs vary.
Record the numbers
Write down LCP, INP or total blocking time, CLS, page size and requests, with the date.
Change one thing, then retest
That is the only way to know what helped.
Why test
What you are really trying to find out
Speed testing answers three questions. Is the site fast enough for visitors? If not, what is slowing it? And did the last change help? A good test gives you evidence for all three, so you stop guessing and stop paying for fixes that do nothing.
Speed matters commercially. Visitors on a slow page leave before they read, and search engines treat page experience as one signal among many. But a tidy score is not the goal. The goal is a page that appears quickly, responds when tapped and stays still, which is exactly what Core Web Vitals describe.
Start with a baseline before changing anything. Without a before, an after means nothing.
Tools
Free tools and what each is best for
| Tool | Best for | Data type | Watch out for |
|---|---|---|---|
| PageSpeed Insights | A quick overall check with advice | Lab and real-visitor field data | Score is a guide, not a goal |
| WebPageTest | Detailed waterfalls and test locations | Lab | Choose a UK location and a mobile profile |
| Lighthouse in Chrome | Testing pages behind a login or on staging | Lab | Results depend on your computer |
| Search Console Core Web Vitals report | Site-wide field data by page group | Field | Needs enough traffic |
| Browser developer tools network tab | Seeing each file and its size | Lab | Needs some technical comfort |
| Uptime and response monitors | Spotting slow server response over time | Continuous | Does not show page rendering |
Test your site on fast hosting
Try a plan with the 15-day money-back guarantee on your first order.
Reading results
The numbers worth looking at
Ignore the single headline score at first. Look at the individual measurements. Largest Contentful Paint says when the main content appeared. Total Blocking Time, in lab tests, hints at how well the page will respond, while Interaction to Next Paint comes from real visitors. Cumulative Layout Shift tells you whether things jump around. Time to First Byte shows how quickly your server began to answer.
Then look at the opportunities list the tool provides. It usually names the biggest culprits: images that are too large, scripts that block rendering, unused code, or a slow server. Work down from the largest estimated saving. Be wary of advice that is technically correct but trivial, such as saving a few kilobytes of CSS on a page that carries a 3 MB hero photo.
Finally, look at the waterfall chart in WebPageTest or developer tools. It shows each file in the order it loaded and how long it took. The longest bars are the best targets.
Reference
What a good page looks like
The published Core Web Vitals thresholds for a good rating.
Bar lengths are scaled for display only. The numbers are Google's published good thresholds.
Pitfalls
Why your results keep changing
Time of day
Server and network load differ across the day, so compare tests taken at similar times.
Test location
A test from Sydney will look slower than one from London. Choose a location near your visitors.
Cached versus cold
The first load builds the cache. Run a test twice and note both results.
Device profile
Mobile tests throttle the processor and network on purpose, so they look worse than desktop.
Plugins and extensions
Browser extensions slow local tests. Use a private window.
Third parties
Adverts, chat widgets and trackers vary run to run.
Lab and field
Lab data versus real visitors
A lab test loads your page once under fixed conditions, so it is great for finding causes and for comparing before and after. Field data summarises what real visitors experienced over the previous 28 days. PageSpeed Insights shows both if your page has enough traffic.
If the two disagree, trust the field data for how visitors feel and the lab data for what to fix. A site with little traffic may have no field data, in which case lab tests are your main evidence, ideally backed by tests on a real mid-range phone.
Cause
Is it the server or the page?
Signs of a slow server
- High Time to First Byte on every page
- Slow even on a very simple page
- Slowness at busy times
- Slow admin dashboard as well
- Fix: caching, a lighter plugin set, better hosting
Signs of a heavy page
- Fast first byte but late content
- Very large images or video
- Dozens of scripts and fonts
- Poor results mostly on mobile
- Fix: optimise images, trim scripts, simplify design
Next
Turning findings into fixes
Fix server response first, because everything else waits for it. Page caching and a quick web server help most, and our plans use LiteSpeed with caching and Redis object caching on servers in London. For WordPress, follow the steps in our WordPress speed guide.
Then tackle images, which are usually the largest files on a page. See how to optimise images. After that, remove scripts and plugins you do not need, and test again. Keep a simple log with the date, the change and the result, so you can undo anything that made things worse.
Habit
A testing routine to keep
- Record a baseline before any change
- Test mobile and desktop
- Run each test three times
- Use the same tool and location each time
- Retest after every major change
- Check Search Console monthly
- Keep a log of changes and results
- Retest after theme or plugin updates
Worked example
Keeping a simple before and after log
A tidy log makes testing useful. Create a short table with one row per change: the date, what you changed, and the LCP, CLS and page weight afterwards. For instance, row one is your baseline. Row two records the day you compressed images, and shows page weight dropping and LCP improving. Row three records installing a new plugin, and shows the opposite.
That record tells you in seconds which change helped and which hurt, and it protects you when a developer or an agency suggests something expensive. If a change did not move the numbers, you can decide with evidence whether to keep paying for it.
Resist testing too many things in one go. Changing the theme, the caching setup and the images on the same day makes the result impossible to interpret.
FAQ
Common questions
What is a good PageSpeed score?
Higher is better, but the individual measurements matter more. Aim for good ratings on LCP, INP and CLS rather than chasing 100.
Why is my mobile score lower than desktop?
Mobile tests simulate a slower phone and network, so the same page scores lower.
Does hosting affect speed test results?
Yes, mainly through server response time. Quick hosting with caching improves it.
How often should I test?
Monthly, and after any significant change to the theme, plugins or content.
Which tool should I start with?
PageSpeed Insights. It is free and shows both lab and real-visitor data.
Keep reading
Related pages
Start with hosting that is quick by default
LiteSpeed, Redis and free SSL on every plan.