PageSpeed Insights vs GTmetrix

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.

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.

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.

• 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.

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.

1. 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. 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. 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. 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. 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.

• 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.

1. 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. 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. 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. 4

   Flag third parties

   Locate slow chat, A/B, analytics and embeds. Decide what to remove, lazy-load or defer until interaction.

5. 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.

• 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.

• 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.