# PageSpeed Insights vs GTmetrix

You want the fastest path to a pass on Core Web Vitals and fewer support tickets. This page compares PageSpeed Insights and GTmetrix, why scores differ, and the order to use them.

Updated 2026-09-14 · Source: https://porteur.ai/compare/pagespeed-insights-vs-gtmetrix

## The short answer

Open PageSpeed Insights first. It shows the only score that matters for Search, the Core Web Vitals field assessment. Then use GTmetrix to see the waterfall, test from the market you serve and watch a filmstrip to spot real delays.

## What each tool is built for

| Feature | PageSpeed Insights | GTmetrix |
| --- | --- | --- |
| Engine | Lighthouse lab run plus CrUX field data | Lighthouse lab run |
| Real-user field data | Yes, when available from CrUX | No |
| Locations and devices for lab | Fixed Google server, Mobile and Desktop tabs | Choose test locations and browsers |
| Waterfall and filmstrip | No | Yes, waterfalls, filmstrips and video |
| Monitoring and alerts | No | Yes, monitoring on paid plans |
| Audit categories | Performance, Accessibility, Best Practices, SEO | Performance with detailed request timeline |
| Who it serves | Site owners checking Core Web Vitals status | Engineers debugging page loads across regions |

## Field data vs lab data, and why it matters

PageSpeed Insights shows two views: field and lab. The field section uses the Chrome User Experience Report. It aggregates opted-in Chrome users over 28 days. It reports the 75th percentile per URL or per origin. That is what Google uses to pass or fail Core Web Vitals.

Lighthouse is lab data. It is one simulated load. By default it runs a mid-range phone on throttled 4G. Scores vary between runs. Use it to reproduce issues and test fixes, not to judge the site’s standing in Search.

> If the two disagree, field data wins. That decides your Core Web Vitals assessment.

## Why PageSpeed Insights is unique

Only PageSpeed Insights shows CrUX field data on the page you test. It includes Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint from real users. Good thresholds: LCP up to 2.5 s, CLS up to 0.1, INP up to 200 ms. Poor: LCP above 4 s, CLS above 0.25, INP above 500 ms.

When a URL has too few visits, it falls back to origin data, or shows none. Mobile and desktop are reported separately. Mobile-first indexing means the mobile view is the one that matters first for Search as of 2026.

## What GTmetrix adds that PageSpeed Insights does not

- Waterfall: see every request, size, timing and blocking.
- Filmstrip and video: watch the page render frame by frame to spot late shifts and missing paint.
- Locations: test from the region your buyers use, not a fixed Google server.
- Monitoring: schedule tests and be alerted when a regression lands.

Use these to find TTFB issues, render-blocking files and third-party delays. A single GTmetrix run from London will tell you more about your UK store than a generic lab from a US data centre.

## Why scores differ between the two

Both tools run Lighthouse, so you would expect the same number. You will still see differences. Reasons: different test hardware, network, location, cache state and run-to-run variance. Even two Lighthouse runs in the same tool can differ.

Lighthouse’s performance score weights Total Blocking Time 30 percent, LCP 25, CLS 25, First Contentful Paint 10 and Speed Index 10. GTmetrix may display additional grades based on its own thresholds. PageSpeed Insights also shows Accessibility, Best Practices and SEO scores. Those categories do not exist in GTmetrix.

Field data is a separate thing. It comes from real users over 28 days, not a one-off run. If your product has a burst of traffic on slow 3G or many iOS users, your lab and field can drift. CrUX field data does not include iOS, only Chrome on Android and desktop.

## A workflow that saves you time

1. **Check the real-world pass or fail** Open PageSpeed Insights for /, /pricing and your top landing pages. Read the Core Web Vitals assessment at the top. Mobile first.
2. **Triage pages** Group pages into pass, borderline and fail. Borderline is just over 2.5 s LCP, 0.1 CLS or 200 ms INP. Fix borderline pages first.
3. **Reproduce with lab** Switch to the Diagnose section in PageSpeed Insights. Run a few times to see variance. Then run GTmetrix from your target market and browser.
4. **Find the bottleneck** In GTmetrix, read the waterfall and filmstrip. Look for long TTFB, render-blocking CSS and JS, late hero images, layout shifts and long tasks.
5. **Apply targeted fixes** Solve the top blocker. Re-test. Move to the next. Do not chase a perfect 100. Aim to pass Core Web Vitals on mobile.

## Reading PageSpeed Insights without wasting cycles

- Field section: look for the Core Web Vitals assessment. That is your Search-facing status.
- Open the LCP, CLS and INP distributions. You need the 75th percentile to be good.
- If the URL has no data, check the origin summary. If that passes, your fixes may apply across pages.
- In the lab section, expand Opportunities and Diagnostics. Note render-blocking resources, long main thread tasks, large DOM and third-party impact.
- Remember: TBT in lab is the proxy for INP. Improve TBT to improve likely INP.

A fixed /pricing in PageSpeed Insights shows a pass on the field assessment, LCP near 2.0 s on mobile and no large layout shifts above the fold.

## Using GTmetrix to find what actually blocks render

1. **Pick the right location and browser** Choose the nearest region to your users and a mobile profile if most traffic is mobile. Keep the choice consistent between runs.
2. **Run, then open the waterfall** Sort by start time. Find long TTFB on HTML. Then look for CSS that blocks render and synchronous scripts without defer or async.
3. **Watch the filmstrip** Note when the hero text and image appear. If they paint late, fix LCP. If elements jump, fix CLS. Tie timestamps back to the waterfall.
4. **Flag third parties** Locate slow chat, A/B, analytics and embeds. Decide what to remove, lazy-load or defer until interaction.
5. **Re-test after each change** Keep one change per commit. Confirm the waterfall shifts the way you expect.

A fixed /guides/getting-started in GTmetrix shows an early HTML TTFB, a preloaded hero image, deferred scripts and no sudden jumps in the filmstrip.

## Fixes that move LCP, CLS and INP

- LCP: no loading=lazy on the hero, fetchpriority=high, preload if it is a CSS background, responsive srcset and sizes, AVIF or WebP, a CDN and server-rendered HTML that names the image.
- CLS: set width and height or aspect-ratio on every image, video and ad. Reserve space with min-height for banners and embeds. Use overlays for cookie notices. Match fallback and web font metrics with size-adjust and ascent-override. Animate with transform, not layout.
- INP: break long tasks with scheduler.yield or setTimeout. Render the visual change first, then do the work. Fewer and smaller scripts. Move work to web workers. Keep the DOM small. Avoid sync layout thrash.
- Render-blocking: inline critical CSS. Load the rest with media=print and onload. Defer or async scripts. Remove unused CSS. Avoid @import.
- Fonts: font-display swap or optional. Preload the one face you use above the fold. Self-host WOFF2. Subset with unicode-range. Prefer a system font stack if design allows.
- Third parties: remove what no one uses. Load on interaction with a video facade. Defer until after load. Preconnect to early origins. Keep the tag manager lean.
- TTFB: cache or pre-render HTML. Use a CDN. HTTP/2 or HTTP/3. Keep-alive. Consider 103 Early Hints.

## Common pitfalls that waste time

- Chasing 100 in Lighthouse. It is not a ranking factor.
- Testing only desktop. Mobile is what Googlebot uses and often slower.
- Ignoring origin-level field data when a URL has no visits. Use it to prioritise.
- Comparing runs from different locations and networks. Keep conditions stable.
- Lazy-loading the hero image. That delays LCP.
- Letting fonts shift layout. Match metrics or swap fast.

## The tools compared

### PageSpeed Insights

Running Lighthouse and showing Chrome UX Report field data for one URL. (pagespeed.web.dev)

Good at: Core Web Vitals field assessment; Simple lab run on mobile and desktop; Actionable Lighthouse audits.

Choose it when You need to know if a page passes Core Web Vitals and want quick lab hints.

Not for: Waterfalls, regional testing, filmstrips or ongoing monitoring.

### GTmetrix

Page speed testing with Lighthouse plus request-level detail. (gtmetrix.com)

Good at: Waterfalls and request timing; Filmstrips and video playback; Choosing test locations and browsers; Monitoring changes over time.

Choose it when You must see what blocks render, compare regions or watch regressions land.

Not for: Real-user Core Web Vitals field data or broad sitewide reporting without setup.

**Verdict.** Use PageSpeed Insights to answer the only question that affects search today: does this page pass Core Web Vitals for real users. If it passes, maintain it. If it fails or is borderline, open GTmetrix from the market you serve, read the waterfall and filmstrip, and fix the specific bottlenecks. Keep conditions consistent. Re-test. Do not chase a perfect Lighthouse score, chase a pass on mobile.

## Questions

### Which should I use first, GTmetrix or PageSpeed Insights?

Start with PageSpeed Insights. It shows the Core Web Vitals field assessment that Search uses. Then switch to GTmetrix to debug waterfalls and regional issues.

### Why is my GTmetrix score different from PageSpeed Insights?

Both run Lighthouse, but test hardware, throttling, location and variance differ. PageSpeed Insights also shows field data from real users, which GTmetrix does not. Expect numbers to vary between individual runs too.

### How accurate is GTmetrix?

GTmetrix is a lab test. It is accurate for the conditions you choose and great for spotting bottlenecks in the waterfall and filmstrip. It does not reflect your 28‑day real-user Core Web Vitals. Use it to diagnose, not to judge ranking.

### Is PageSpeed Insights accurate?

The field section reflects real Chrome users over 28 days at the 75th percentile, so it is the best view of your Core Web Vitals. The lab section is a single simulated run. Treat the field result as the source of truth for Search.

### What is a good GTmetrix score?

Do not anchor on the 0 to 100 lab score. Aim to pass Core Web Vitals on mobile: LCP up to 2.5 s, CLS up to 0.1 and INP up to 200 ms. Use GTmetrix to find and fix what stops that.

### What are alternatives to PageSpeed Insights?

WebPageTest offers deep waterfalls, many locations and filmstrips. Chrome DevTools has the Lighthouse and Performance panels for local profiling. Search Console’s Core Web Vitals report shows CrUX field data across your site.

## Read next

- [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix.
- [Reading a Lighthouse score on a phone](https://porteur.ai/guides/lighthouse-score): Use the mobile Lighthouse run to judge speed and UX. See what each score means, how lab and field data differ, and what to fix first.
- [How to read PageSpeed Insights: field data first, then the score](https://porteur.ai/guides/how-to-read-pagespeed-insights): Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes.
- [Time to first byte: the delay every other metric inherits](https://porteur.ai/guides/time-to-first-byte): TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.
- [Web fonts and page speed: load one face, and load it first](https://porteur.ai/guides/web-fonts-and-page-speed): Ship crisp type without slowing first paint or shifting layout. Choose one fast path, preload the face above the fold, and stop the swap from moving text.
- [Image optimisation for page speed: the hero image and everything below it](https://porteur.ai/guides/image-optimisation-for-page-speed): Fix the hero image first for LCP, then lazy-load the rest. Choose AVIF or WebP, set srcset and sizes, and add width and height to stop shift.
- [GTmetrix vs WebPageTest](https://porteur.ai/compare/gtmetrix-vs-webpagetest): GTmetrix gives a readable report and monitoring. WebPageTest gives filmstrips, connection profiles and repeat views. Here is which to open when.

Drop your homepage URL to get a free read of your site and rivals in about thirty seconds, with three findings you can fix now. Free check: https://porteur.ai/