Run one speed test tool consistently, not both interchangeably. PageSpeed Insights and GTmetrix use different methodologies and different test locations, so bouncing between them and comparing scores makes the comparison meaningless. Pick one, test from the same conditions each time, and track the trend, not the absolute number.
If you haven't run a test yet, see reading your speed score and fixing what's slow for how to run one.
Why the same URL scores differently every time
Lab tests (PageSpeed, GTmetrix, Lighthouse) simulate a single page load under specific network and CPU throttling conditions. Real-world performance varies by visitor device, connection, location, and even time of day if your server is under load. A lab test is a snapshot, not a guarantee of what every visitor experiences.
Score variance between runs of the same tool, on the same page, five minutes apart, is normal within a few points; a swing of 20+ points means something is actually inconsistent, usually a third-party script or an uncached page. Causes include:
- Third-party scripts (ads, chat widgets, analytics) that load inconsistently
- CDN edge cache warm vs. cold on that specific test
- Server load at the moment of the test
- Random network jitter between the test server and yours
Test the page that matters, not just the homepage
Homepages are usually the most optimized page on a site because they get the most attention. If you're diagnosing a real complaint ("the site feels slow"), test the actual page someone was on: a product page, a blog post, a checkout flow. Different templates load different assets and can have very different scores.
Read Core Web Vitals, not the headline number
The 0-100 score is a weighted composite and it moves around based on which metrics it weights that week. The three numbers underneath it are more stable and more useful:
- LCP (Largest Contentful Paint): how long until the biggest visible element finishes rendering. Under 2.5 seconds is good.
- CLS (Cumulative Layout Shift): how much the page jumps around while loading. Under 0.1 is good.
- TTFB (Time To First Byte): how long the server takes to respond before the browser has anything to render.
For a full breakdown of what each of these means and how to fix what's behind them, see reading a PageSpeed or GTmetrix report.
Control for the variables that actually change results
Before comparing two test runs (before/after a fix, or two different tools), make sure you're testing apples to apples:
- Same device profile. Mobile and desktop tests use different CPU and network throttling. A mobile score will almost always be lower than desktop for the same page, that's expected, not a regression.
- Cache warm. Load the page once yourself first so caching layers are warm, then run the test. A cold cache read inflates TTFB and doesn't reflect what repeat visitors see.
- Same location if possible. Test servers in different regions add different amounts of network latency before your page even starts loading. This mostly affects TTFB, not the page's own rendering weight.
- Run it 3 times, take the median. One run can catch a fluke. Three runs tell you what's real.
What a single number can't tell you
A score doesn't tell you whether a 403 or 500 error is intermittently breaking a resource load, whether a specific visitor's connection is failing outright, or whether DNS is misconfigured for some users and not others. Those are different failure modes with their own diagnostics: see fixing a 403 Forbidden error or fixing ERR_CONNECTION_REFUSED if visitors are reporting the site won't load at all rather than loading slowly. Speed tools assume the page loads successfully; they're the wrong tool for "sometimes it doesn't load."
If you want it tuned, not just measured
Once you've got a clean, repeatable test and you know LCP or TTFB is the actual problem, fixing it is often a hosting-and-caching job as much as a content job. Open a ticket from the portal (Support → New ticket) and a real person will take a look.