Website Speed Testing Tools Compared: Which Numbers Matter
Run the same URL through three different speed tools and you'll get three different scores. That alone tells you something important, the numbers are not gospel. Each tool measures different things at different moments under different conditions. Knowing which figures to trust, which to ignore, and what a bad result actually looks like in practice is where the real work begins.
On this page
Why Every Tool Returns a Different Score
Run the same URL through PageSpeed Insights, GTmetrix and WebPageTest within five minutes of each other and you will get three different numbers. Not a bug. It is what happens when each tool makes different assumptions before it even loads your page.
The biggest variable is throttling. PageSpeed Insights simulates a mid-range Android device on a throttled mobile connection, which is why its mobile scores tend to look alarming even on a reasonably fast site. GTmetrix, by default, tests from a Canadian data centre on a desktop connection with no throttling applied unless you configure it otherwise. WebPageTest lets you pick your own server location and connection profile, so a test from London on a cable connection will return a materially different result than one from Sydney on 3G.
Caching state adds another layer. A first-view test hits a cold server with no cached assets, while a repeat-view test loads resources the browser already has. A freshly deployed site tested cold will score worse than the same page after a warm-up crawl, even if nothing changed in the code. Real user data from the Chrome User Experience Report, which feeds into the Core Web Vitals section of PageSpeed Insights, introduces a different dimension altogether. Those figures come from actual visitors on their own devices and connections, not a controlled lab environment.
The practical upshot is to stop hunting for the tool that gives the best score and start understanding what each one is measuring. The page speed metrics Google scores you on are rooted in real user experience data, not lab simulations, so a polished GTmetrix result with throttling switched off tells you very little about how Google sees the same page.
PageSpeed Insights
PageSpeed Insights pulls from two completely different sources, and mixing them up is where most people get confused.
The lab data is generated by Lighthouse running in a controlled environment, a simulated mid-range device on a throttled connection. The field data, labelled as Core Web Vitals, comes from the Chrome User Experience Report (CrUX), which is real anonymous browsing data collected from actual Chrome users visiting your site. A well-cached site with a returning audience can show strong field data while the lab score sits in the forties. That gap is not a contradiction. It reflects the difference between a cold synthetic test and how people load your pages day to day.
The lab score is still useful for spotting specific technical problems, but do not be alarmed if it looks worse than expected, particularly on sites where most visitors arrive with cached assets already in their browser.
The section that deserves the most attention is the field data panel at the top of the report. If you have enough traffic for CrUX data to appear, those numbers are what Google’s ranking systems see. For a detailed look at the page speed metrics Google scores you on, the distinction between LCP, INP and CLS matters far more than chasing a higher lab score.
Thin-traffic sites often show no field data at all, which leaves only the lab results to work from. In that case, treat Lighthouse as a diagnostic checklist rather than a report card.
GTmetrix
The waterfall chart is the reason to use it
GTmetrix earns its place in any serious diagnostic workflow because of the waterfall chart. Where Lighthouse gives you a score and a checklist, GTmetrix shows you exactly which request fired at what millisecond, how long it hung, and what came after it. That granularity matters when you are chasing a specific render-blocking resource or trying to work out why a third-party script is dragging your Time to First Byte up by 400ms. The waterfall is where a slow site stops being a mystery and becomes a solvable problem with a sequence you can follow.
Test location matters more than people realise
The default test location is Vancouver, Canada. If your site serves a British audience, those numbers will look worse than reality, and occasionally better, depending on where your CDN edge nodes sit. Always switch the test region to match your actual visitors before reading anything into the figures.
GTmetrix is the right tool when you already know something is slow and you need to find what specifically is causing it. For a broad first pass on the page speed metrics Google scores you on, something closer to real Chrome User Experience data serves you better. But for dissecting a stubborn performance issue, request by request, GTmetrix is hard to beat. Use it as a surgical instrument rather than a health check, and it pays back the time you put into reading it.
WebPageTest, the Tool Most Site Owners Never Touch
WebPageTest sits in a different category from the tools most people reach for first. Where PageSpeed Insights hands you a score and a colour, WebPageTest hands you the raw test conditions and lets you decide what matters.
The repeat view feature is a good example of why that matters in practice. The first view loads every asset cold, no cache. The second view runs the same request again immediately, with the browser cache populated. If your first view takes 4.2 seconds and your repeat view still takes 3.8, something is wrong with your caching configuration, and a single-run tool would never surface that gap.
The filmstrip view goes further still. It renders a second-by-second screenshot strip of what the page looked like to a visitor as it loaded, which is far more telling than a single number when you are trying to understand why something feels slow even if the total load time looks acceptable.
Connection throttling is where the diagnostic honesty gets serious. You can test over a simulated cable connection, a 4G mobile network, or a slow 3G signal, and the results shift considerably. Testing only on fast connections is one of the most common ways to miss a performance problem that is obvious to half your audience.
For a grounded read on the specific page speed metrics Google uses to score your site, the filmstrip and waterfall views in WebPageTest give you the evidence to act on, not just a number to worry about.
Which Metrics to Fix and Which to Ignore
The three numbers that feed directly into rankings
Not every number in a speed report carries the same weight. Some will tank your rankings. Others are noise dressed up as urgency.
Google’s Core Web Vitals are the three figures that feed directly into search ranking signals. Largest Contentful Paint (LCP) measures how quickly your main content appears. Interaction to Next Paint (INP) captures how fast the page responds to a click or tap. Cumulative Layout Shift (CLS) tracks whether elements jump around as the page loads. Fail any of those and you have a genuine problem.
Most of the websites we have worked on came in failing at least one Core Web Vital on mobile, and getting them to a pass required real investigation rather than a surface-level fix. A poor LCP almost always points to unoptimised images, slow server response, or render-blocking resources. CLS problems tend to come from images without declared dimensions, or fonts that swap in late and push everything down the page. These are solvable, but they take time to diagnose properly.
Scores that are useful diagnostics but nothing more
Figures like Time to First Byte shown in isolation, or the raw performance number from Lighthouse, are useful diagnostics but carry no direct ranking weight on their own. A page can sit at 68 in Lighthouse and still pass every Core Web Vital that matters. Chasing a round number is a distraction. Fix LCP, INP and CLS first, then look at everything else.
How to Test Fairly
A single test run tells you almost nothing useful. Network conditions vary, server responses fluctuate, and a cold cache behaves completely differently from a warm one.
Before you run any tool, clear the cache on both your server and your caching plugin, then run the same URL three times in a row and average the results. That averaged figure is far more honest than the outlier score you happened to screenshot. Test mobile and desktop as separate exercises too, not as a footnote, because the performance gap between them is often 20 or 30 points and the fixes for each can pull in opposite directions.
Geography matters as well. If your customers are in the UK, test from a UK location rather than letting the tool default to a US data centre, because the extra round-trip latency will skew your numbers and mislead you about what needs fixing.
PageSpeed Insights is the obvious starting point because it uses real-world Chrome User Experience Report data alongside the lab result. For a deeper look at the specific metrics Google scores you on, it pays to know which numbers feed into Core Web Vitals and which are diagnostic only.
The score is a prompt, not a goal. Chase the underlying metric, not the badge.