Website Speed Test

A website speed test is excellent for isolating technical bottlenecks in a controlled environment. I rely on it most when I have made a change – switching to WebP images, deferring a JavaScript file, enabling compression – and need to know whether the change actually moved the needle. The last time I did this for an ecommerce product page, LCP dropped from 4.2 seconds to 2.1 seconds after I optimised the hero image using [TinyPNG](/tinypng/). That number told me the fix worked and I could move on.

It is also good for comparing the impact of a new theme or plugin before you deploy it to production. I stage the candidate version, run a WebPageTest from the same location as the live site, and compare the waterfall charts side by side. This catches things like a bloated stylesheet that adds 300 KB to the critical path before any real user sees the slowdown.

Core Web Vitals measurement is the other strong suit. Tools like PageSpeed Insights give you a clear LCP, CLS and INP score, along with a pass/fail verdict. I use this as a quick check for compliance with Google's thresholds, but I never stop there. The diagnostic suggestions – 'eliminate render-blocking resources', 'serve images in next-gen formats' – are genuinely actionable, even if they sometimes point you toward a CDN change you cannot make without your hosting provider.

For bulk analysis, combining a crawler like [Screaming Frog](/screaming-frog/) with the PageSpeed Insights API lets me scan an entire site in one go. That is how I discovered that our blog section had a median LCP of 3.8 seconds while the rest of the site sat at 1.9. Without a speed test tool, I would have optimised the wrong pages for weeks.

Where it shines is validation. A speed test gives you a before-and-after pair that is hard to argue with. If the number improves, you know your change worked in that lab environment. That confidence is worth a lot when you are pushing a deployment through a risk-averse team.

Speed tests are awkward at capturing what real users experience. A synthetic test from a single data centre in Virginia tells you nothing about a visitor in Bangkok on a 3G connection with a two-year-old device. I learned this the hard way: our tests all showed green for a client's site, but users in Southeast Asia kept complaining about slow loads. The CDN edge node was not configured for that region, and my synthetic test never hit it because it ran from Europe.

They are also awkward for measuring perceived performance. The technical metrics – load event, DOMContentLoaded – do not always align with when a user feels the page is ready. I have seen a page with a 6-second load event that nevertheless rendered the main content in under 2 seconds. Speed test tools will flag that page as slow, but real users would not complain. Tools like [Hotjar](/hotjar/) or [Microsoft Clarity](/microsoft-clarity/) show you what users actually see and interact with, which is a far better indicator of perceived speed than any synthetic score.

Pages behind a login are another blind spot. Most speed test tools cannot authenticate, so you end up testing the public cached version or a staging clone that may not match the actual authenticated experience. I once spent a day optimising a dashboard page only to discover the bottleneck was in the authentication handshake, which my tool never triggered.

Single-run results are essentially noise. Network conditions fluctuate, the server may have had a brief spike, or a third-party script may have failed to load. I now run every test at least three times from two different locations and take the median. Even then, I treat the numbers as directional, not absolute.

Finally, speed tests struggle with transactional flows. A single URL test cannot measure how a multi-step checkout performs. You would need a tool that scripts user actions – WebPageTest can do this with its 'scripted testing' feature – but the regular free tools do not. That gap means you can have a fast landing page and a slow purchase journey without ever noticing.

If I want more than a point-in-time snapshot, Lighthouse CI is where I go next. It runs Lighthouse as part of your deployment pipeline and surfaces regressions before they hit production. I integrated it into a client's GitHub Actions workflow, and it caught a 0.8-second LCP regression the same day a developer merged a heavy font file. The alternative would have been a frantic Friday afternoon debug after users complained.

For ongoing monitoring, I have used Calibre and Request Metrics. Calibre gives you synthetic checks from multiple locations with team dashboards. Request Metrics is a real-user monitoring (RUM) service that collects actual performance data from your visitors. The RUM perspective often contradicts the synthetic one: your lab test might show a fast page, but RUM reveals that 30% of users on slow networks are having a terrible experience. That shift in perspective changed how I prioritise performance work.

If you want to stay free and still get useful site-wide data, [Bing Webmaster Tools](/bing-webmaster-tools/) offers a speed report that covers your entire site. It is not as detailed as dedicated tools, but it is good for spotting which pages need attention first. I combine that with the Screaming Frog + PageSpeed Insights bulk workflow I mentioned earlier to audit the worst offenders.

Another alternative I keep coming back to is WebPageTest's scripted testing. It is not a separate tool, but using its advanced features – injecting cookies, filling forms, emulating video playback – turns a simple speed test into something that can mimic real user behaviour. That has saved me in cases where the critical path depended on a logged-in state.

For teams that already use a suite like [Semrush](/semrush/) or [Ahrefs](/ahrefs/), their site audit modules include page speed data. It is not as deep as a dedicated tool, but the advantage is you see speed alongside backlinks, keywords, and technical issues in one report. I find that useful for quick triage, though I always double-check with a specialised tool before making a change.