PageSpeed, Lighthouse, GTmetrix and WebPageTest: what each actually measures

Lighthouse is an open-source audit that loads your page in a controlled browser and scores what it finds. PageSpeed Insights runs Lighthouse for you and adds the other half: field data, the experience of real Chrome users, drawn from the Chrome User Experience Report. GTmetrix and WebPageTest are independent services that test your page from locations you choose, with their own options and presentations. The four names get used interchangeably and measure related but different things, which is why their scores disagree, sometimes loudly. Used in the right order, they answer two questions: is there a problem real visitors can feel, and if so, what in the page causes it.

Lab data and field data are different measurements

Lab data comes from a controlled run: a defined device profile, a defined connection, one location, one moment. It is reproducible, which makes it the right instrument for diagnosis and for before-and-after comparisons. Same conditions, one change, re-run, and any movement in the numbers is yours.

Field data comes from the Chrome User Experience Report, which aggregates what real Chrome visitors actually experienced on the page: their devices, their networks, their distance from your server. It cannot be re-run on demand, it lags by weeks, and it needs enough traffic to report at all. It is also the only measurement that counts when the question is whether visitors are having a bad time. Lab data finds causes; field data confirms they matter.

What each tool actually is

Lighthouse loads the page in Chrome, simulating a mobile device and a throttled connection by default, and produces scores on a 0 to 100 scale across performance and other categories, with named audits underneath each score saying what dragged it down. It is the engine, and you can run it yourself from Chrome's developer tools on any page.

PageSpeed Insights is Google's web front end for two things at once: a Lighthouse run from Google's servers, and field data for the same URL when enough real Chrome traffic exists. The two halves answer different questions, and the page shows both, which reads confusingly until you see it as two reports stapled together.

GTmetrix runs Lighthouse-based tests from server locations you pick, on a schedule if you want, and keeps history so you can see when a change landed. Useful for watching a page over time from one consistent vantage.

WebPageTest is the configurable one: location, browser, connection speed, first versus repeat view, multi-step scripts that log in or walk a checkout, then waterfalls and filmstrips for forensics. When you need to see what the browser was doing in a given second, this is the microscope.

None of them know the page is WordPress. They audit the delivered page; they cannot name the plugin behind a slow query or a blocking script. For that layer, pair the lab result with server-side profiling, Query Monitor on a staging copy is the usual first move, and the WordPress speed guide covers the causes these tools point at.

Why the scores disagree

Location: a test from Virginia and a test from London disagree on any site with one origin, legitimately. Device and connection profiles differ between tools and between settings. Cache state: a first view on a cold cache is a different test from a repeat view, and the tools differ in which one they show you. Single runs carry noise. And the tools are often aimed at different pages, since homepages get tested and post templates do not. Treat disagreement as information about conditions, once you know the conditions, and as noise when you do not. The comparison that means something is the same tool, same settings, same page, before and after a change you made.

Why chasing a perfect score wastes the afternoon

The performance score is a weighted composite of underlying timings, and as it rises, the remaining deductions map to progressively smaller real-world differences while the work to clear them grows. Somewhere in the high range you are optimising for the grader. Visitors never experience a score; they experience how long the page took, whether it jumped around, and when they could start reading. Lab-pleasing changes can also misfire in the field, so a change worth making is worth confirming in field data afterwards.

The workflow that works

Start in the field. PageSpeed Insights or the Core Web Vitals report in Search Console tells you whether real visitors on real devices are having the problem, and on which URL groups. If field data says no, your evening is free; a mediocre lab score alongside healthy field data deserves a note and little else. If field data says yes, take the affected templates into the lab: Lighthouse or GTmetrix for the score and the audit list, WebPageTest when you need the filmstrip to see the sequence. Change one thing, re-run the lab test, then leave it alone long enough for the field data to catch up, which takes weeks. For the first-byte part of the picture, what it means and when to stop caring about it, the TTFB guide picks up from here.