PageSpeed Insights, Lighthouse, GTmetrix: why the speed scores never agree

You run PageSpeed Insights on your freshly published landing page: 45 on mobile, red alert. A little worried, you test the same URL on GTmetrix: 92, grade A. Just to be sure, you open the Lighthouse tab in Chrome DevTools, on your own machine: 98. Three tools, three verdicts on the exact same page, with no indication of which one to believe when deciding whether the page has a real problem. This isn't a bug in one of the three tools: it's that they aren't measuring the same thing, under the same conditions, for the same person. Understanding what separates them saves you an afternoon spent optimizing a number that doesn't reflect what your actual visitors experience.

The first gap: lab versus field

Lighthouse (whether it runs in Chrome DevTools, from the command line, or behind PageSpeed Insights) always does the same thing: it loads the page once, in a controlled environment, with a simulated network and CPU following a fixed profile. This is called lab data — reproducible, useful for before/after comparisons, but coming from a single synthetic load. PageSpeed Insights also shows field data: the metrics actually measured on your real Chrome visitors over the past 28 days, aggregated by Google through the Chrome User Experience Report (CrUX) and shown at the 75th percentile, as we detail in our article on LCP. These are two separate blocks in the same report: the numeric score (0 to 100) comes only from the lab run, while the "Good / Needs improvement / Poor" verdict on the Core Web Vitals relies on field data whenever enough traffic exists. A page can therefore show a high lab score and, right below it, a red badge on the real-world LCP — the two numbers coexist without contradicting each other, they simply answer different questions.

Why Lighthouse alone already gives different scores from one run to the next

Before even comparing two tools, run Lighthouse three times in a row on the same page from the same computer: the scores move, sometimes by 10 to 15 points. Loading a page isn't a single operation measured once and for all, but the execution of a dependency graph between the network, HTML parsing, CSS and JavaScript execution, and on-screen rendering — a research paper by Xiao Sophia Wang and her coauthors, presented in 2013 at the NSDI conference under the name WProf, modeled exactly this graph across 350 pages and showed that computation (parsing, JavaScript execution) accounts for up to 35% of the time on the critical path of a page load, alongside the network and rendering (Wang et al., 2013). In practice, this means the CPU capacity available at the exact moment of the test — another open tab, a background process, the load on the server hosting PageSpeed Insights at that instant — changes the result, even with strictly identical code and connection. A single score therefore never has absolute value; only a trend measured several times, or a clear gap (20 points, not 3), deserves to be taken seriously.

GTmetrix: a lab test, but a configurable one

GTmetrix adds a third source of divergence: it lets you choose the test server's location, the simulated connection profile, and, on paid accounts, the emulated device — settings that, by default, don't necessarily match those used by PageSpeed Insights. A test run from a London server on an "Unlimited" connection has no reason to produce the same number as a Google-run test launched from Google's own infrastructure with a different network-throttling profile. GTmetrix remains a lab tool, just like Lighthouse — but it often offers a more readable waterfall view of exactly which resource is blocking the render, a useful complement for diagnosing a problematic image or script once field data has already told you a real problem exists for your visitors.

The number that matters for SEO is neither Lighthouse nor GTmetrix

For Google's ranking, only field data (CrUX) counts toward the Core Web Vitals signal — not the lab score, whichever tool displays it. A page can score 60 on PageSpeed Insights in the lab and still be rated "Good" on the field side if your real visitors, on their actual devices and connections, stay under the Core Web Vitals thresholds (LCP, INP, CLS). The reverse also happens, and it's the trickier case: an excellent lab score masking a degraded field experience, because your real visitors use entry-level devices or a 4G connection that the lab test, calibrated on a generic profile, doesn't reproduce faithfully. Google Search Console's "Core Web Vitals" report remains the only source that reflects what your visitors actually experience, once traffic is high enough for Google to have data on it — see our article on load speed and conversion for what those seconds actually cost in lost visitors.

A simple method to stop chasing a number

1. Pick a single lab tool for your before/after comparisons on a given change (always Lighthouse, or always GTmetrix with the same settings) — comparing yesterday's GTmetrix score to today's PageSpeed Insights score means nothing.
2. Run three passes, not one, and use the median rather than the first number shown: this filters out most of the noise tied to the machine's load at that moment.
3. Once the site is live with real traffic, shift your attention to Search Console's "Core Web Vitals" report: it's the only measurement that matters for SEO and the only one that reflects your actual visitors.
4. Never treat 100/100 as a goal in itself: beyond each metric's "Good" threshold (2.5s for LCP, 0.1 for CLS, 200ms for INP), the extra points have no measurable effect on ranking or on conversion.
5. Treat a 3-to-5-point gap between two runs of the same tool as noise; a gap of 20 points or more signals an actual change worth investigating.

Starting from a base that doesn't depend on test luck

The most reliable way to avoid this back-and-forth between tools is to start from a page that structurally has nothing to hide: no generic theme loading unused CSS, no stack of third-party scripts, no rendering engine invoked on every visit. LanderKit templates are pre-generated Next.js pages, with no CMS and no plugins, that you can test yourself on any tool before buying via their live demos — the variance from one test to the next is minimal there, precisely because there's almost nothing left to cause it. For the hosting and static generation that drive much of this result, our guide to deploying Next.js on Vercel covers the full setup.