NEWProduction-ready HTML & CSS templates, live nowBrowse the catalog →
Code & dev

PageSpeed Insights vs GTmetrix vs Lighthouse: which should you use?

27 April 2026 · 7 min read · By TM Team
TL;DR

PageSpeed Insights, GTmetrix and Lighthouse can all disagree on the same page because they use different test locations, connection speeds, and sometimes different data sources entirely. PageSpeed Insights is the one to trust for how Google actually sees your site, since it includes real-user field data. GTmetrix gives the most configurable lab test. Lighthouse is the underlying engine both are partly built on, and the one to use for local, repeatable debugging.

Test the same page on PageSpeed Insights, GTmetrix, and Lighthouse and you'll often get three different scores, sometimes wildly different ones. That's not one of the tools being wrong. They test from different locations, on different simulated connections, and at least one of them mixes in real-world data the others don't have access to at all.

Once you know what each tool is actually doing, the disagreement stops being confusing and starts being useful — each one answers a slightly different question.

Lab data vs field data: the core distinction

This is the single most important concept for making sense of any speed tool. Lab data is a simulated test run once, under controlled conditions, on a specific device and connection speed profile. Field data is aggregated from real visitors actually loading your site, on their real devices and real connections, over a rolling time window.

Lab data is reproducible and great for debugging a specific change. Field data is messier but reflects what your actual visitors experience, which is also what Google uses for ranking purposes. A page can score well in a lab test and still perform poorly for real visitors on slow mobile connections, and the reverse can happen too.

Lab data vs field data at a glance
Lab dataField data
SourceSimulated test run, on demandReal visitors' actual page loads (via Chrome User Experience Report)
ConsistencyReproducible, same test conditions each timeVaries with real-world device and network mix
Best forDebugging a specific change before/afterUnderstanding what visitors actually experience
Used for Google rankingNoYes, this is the basis for Core Web Vitals ranking signals
Available for low-traffic sitesAlwaysOnly if enough real visitors were recorded (CrUX has a traffic threshold)

What each tool actually gives you

PageSpeed Insights (PSI) is Google's own tool, and it's the only one of the three that combines both data types in one report: field data from the Chrome User Experience Report (CrUX) when your site has enough real traffic to qualify, plus a Lighthouse-powered lab test underneath. This dual view is exactly why PSI is the closest thing to 'what Google sees.'

GTmetrix runs a lab test too, but gives you far more control over test conditions: choice of test server location, simulated device and connection type, and a waterfall chart that's genuinely useful for diagnosing exactly which request is slow. It has no field data of its own — everything it reports is a single simulated run.

Lighthouse is the open-source auditing engine that powers the lab-test portion of both PSI and, indirectly, much of GTmetrix's scoring philosophy. You can run it directly from Chrome DevTools or the command line, with no server round-trip, which makes it the fastest option for iterating locally while you're actively making changes.

They're not really three competing products
Lighthouse is the shared engine. PSI wraps it and adds Google's real-world field data. GTmetrix wraps a similar lab-testing approach and adds configurability. Thinking of them as three unrelated scoring systems is where the confusion comes from — they overlap by design.

Why scores differ between tools, and even between runs

Beyond the lab-vs-field distinction, several other factors move the number even for identical pages. Test server location changes network latency to your host. Simulated connection speed (throttled 4G vs a faster profile) changes how long resources take to arrive. CPU throttling settings simulate a slower or faster device. And even the exact same tool, run twice in a row, can vary by a few points due to normal network jitter — this is expected, not a bug.

None of this means the scores are meaningless. It means a single number from a single tool, on a single run, is a snapshot, not a verdict. Trends across multiple runs and multiple tools matter more than any one score in isolation.

Which tool to trust for which purpose

  1. 1
    Use PageSpeed Insights to know where you stand with Google
    If your site has enough traffic for CrUX field data, PSI's field report is the closest available proxy to your actual Core Web Vitals ranking signal. Check this first.
  2. 2
    Use GTmetrix when you need to diagnose a specific slow request
    Its waterfall view and configurable test conditions make it easier to pinpoint exactly which image, script, or font is the bottleneck.
  3. 3
    Use Lighthouse (via Chrome DevTools) while actively making changes
    It's the fastest feedback loop since it runs locally with no queue or server round-trip, ideal for a quick before/after check as you optimize.
  4. 4
    Don't obsess over an exact numeric score from any single tool
    Look for consistent trends across tools and across your top pages, not a single perfect number on one run of one tool.
Illustrative same-page score spread across tools (illustrative)
PageSpeed Insights (mobile)
72
GTmetrix (default server/device)
81
Lighthouse (DevTools, local)
78
If your site is too small for field data
PSI will simply omit the field data section and show only the lab test if your site doesn't have enough recorded Chrome traffic. This is common for smaller sites and isn't an error — the lab score is still useful, just treat it as a lab-only reading.

Where WebPageTest and browser DevTools fit in

Two other tools are worth knowing about, even though they're less commonly the first stop. WebPageTest offers even deeper configurability than GTmetrix — multiple test locations worldwide, real device testing rather than only simulated throttling, video comparison of two runs side by side, and a very detailed request-level breakdown. It rewards the extra complexity when you're chasing a specific, stubborn performance problem rather than doing a general check.

Your browser's own DevTools (the Network and Performance tabs, available in Chrome, Firefox, and Edge) skip the external tool entirely. You can throttle your own connection, record a full performance trace, and see exactly which resource is blocking rendering, without leaving the page you're debugging. It's less polished than a dedicated speed-testing product, but it's the fastest way to answer 'why is this specific thing slow, right now.'

A simple monthly routine that avoids over-testing

You don't need to run every tool on every page constantly. A practical cadence for a small site is: check PageSpeed Insights for your top few pages roughly once a month to track field-data trends over time, and reach for GTmetrix, WebPageTest, or Lighthouse specifically whenever you make a change you want to verify — a new hero image, an added script, a hosting switch. Testing more often than that mostly adds noise without adding insight, since day-to-day fluctuation is expected and not meaningful on its own.

  • Lab data is a controlled, repeatable simulation; field data is aggregated real-visitor experience.
  • PageSpeed Insights is the only one of the three with real field data built in, when your traffic qualifies.
  • GTmetrix offers the most configurable, detailed lab test for pinpointing specific slow requests.
  • Lighthouse is the shared underlying engine, and the fastest option for local iterative testing.
  • Score differences between tools and even between runs of the same tool are expected, not errors.
  • Trust trends over time and across tools more than any single score from any single run.
  • WebPageTest and browser DevTools are worth reaching for on stubborn, specific performance problems.
Why do I get different scores on PageSpeed Insights and GTmetrix for the same page?
They test under different simulated conditions (server location, connection speed, device profile), and PageSpeed Insights may also be blending in real-user field data that GTmetrix simply doesn't have access to. Different methodology, different number — both can be 'correct' for what they measure.
Which speed test does Google actually use to rank my site?
Google's ranking signal is based on real-user field data (Core Web Vitals from the Chrome User Experience Report), which is exactly the field data section shown in PageSpeed Insights when your site has enough traffic to qualify. Lab tests from any tool are a helpful proxy, not the ranking input itself.
Is a 100/100 score necessary?
No. A perfect lab score on one tool doesn't guarantee a good real-world experience, and a good real-world experience doesn't require a perfect lab score. Focus on the Core Web Vitals thresholds and genuinely noticeable load-time improvements rather than chasing a specific number.
Why does my score change every time I run the same test?
Normal network variability, server load, and timing jitter cause small fluctuations between runs even with identical settings. A few points of variance run to run is expected; look at the broader trend rather than any single result.
How often should I actually test my site's speed?
Roughly monthly for a general trend check, plus whenever you make a change worth verifying — a new image, an added script, a hosting change. Testing far more often than that mostly adds noise, since normal run-to-run variance isn't meaningful on its own.
pagespeed insights vs gtmetrixlighthouse vs pagespeed insightswebsite speed test toolscore web vitals testing toolslab data vs field data