WebPageTest vs PageSpeed Insights

Use PageSpeed Insights for the verdict and trend. It shows real world Core Web Vitals from the last 28 days and a pass or fail that Search cares about.

Use WebPageTest for the investigation. It gives filmstrips, waterfalls, real browsers and locations, connection profiles, first and repeat views, and one click experiments to try a change.

On a site you ship yourself, start with PageSpeed Insights to see if the URL passes. If not, switch to WebPageTest to find exactly what blocks paint or interaction, then confirm the fix back in PageSpeed Insights field data after it ships long enough to register.

Core Web Vitals as of 2026: LCP is good up to 2.5 s, poor above 4 s. CLS is good up to 0.1, poor above 0.25. INP is good up to 200 ms, poor above 500 ms. INP replaced FID in March 2024. PageSpeed Insights uses the 75th percentile of real Chrome users on Android and desktop over 28 days. A URL with too little traffic falls back to origin data or shows nothing. Lighthouse in PageSpeed Insights is a single lab run and its score can vary between runs.

1. 1

   Check the field section first

   The top section reads: Discover what your real users are experiencing. This is the Chrome UX Report. If it shows a Core Web Vitals assessment, that is your pass or fail for Search.

2. 2

   Look at the vitals distribution

   Open the LCP, INP and CLS charts. Find the 75th percentile values. If LCP is 3.1 s you fail LCP. If INP is above 200 ms you fail INP. Fix the one that fails first.

3. 3

   Use the lab section to form a hypothesis

   Scroll to Diagnose performance issues. This is Lighthouse on a simulated mid range phone over throttled 4G. Note audits like Render blocking resources or Reduce the impact of third party code. Scores vary, so read the audits instead of chasing 100.

4. 4

   Pick one page to fix

   Start with a revenue page, for example /pricing, or a landing page. Copy its URL. You will use WebPageTest to find the exact blockage.

1. 1

   Choose a realistic test agent

   Pick the location closest to your main audience, a real mobile browser for mobile issues, and a 4G or 3G profile if most users are on mobile.

2. 2

   Run first and repeat views

   First view shows cold cache. Repeat view shows caching and service worker effects. A large first vs repeat gap points to missing cache headers or heavy third party code.

3. 3

   Open the filmstrip and waterfall

   The filmstrip shows when the hero appears and when layout stabilises. The waterfall shows request order, blocking and priorities. Look for late CSS, render blocking scripts and slow TTFB.

4. 4

   Inspect key metrics

   Check LCP element in the filmstrip and its request in the waterfall. Note CLS events. For interactivity, look for long main thread tasks and heavy script downloads that align with delays.

5. 5

   Try experiments

   Use built in experiments to defer a script, inline critical CSS or change image priority. Compare the before and after filmstrips to see if the hero paints sooner or layout stops shifting.

A fixed page shows the hero image by about 2.5 s on a 4G profile, does not jump after paint, and responds to a tap within about 200 ms in the trace.

1. 1

   Pick the failing vital

   From PageSpeed Insights field data on /pricing, suppose LCP fails at 3.4 s. You will optimise the hero render path.

2. 2

   Prove the cause in WebPageTest

   Run a mobile test on a 4G profile. In the waterfall, you see a CSS background image discovered late and a large render blocking stylesheet.

3. 3

   Apply the fix locally

   Convert the hero to an <img> with fetchpriority=high and a responsive srcset. Preload the hero if it must stay as a CSS background. Inline critical CSS, load the rest with media=print and onload. Defer non critical scripts.

4. 4

   Validate in WebPageTest

   Re run first and repeat views. The filmstrip shows the hero by 2.2 s. The waterfall shows CSS requests later with non blocking media and scripts deferred.

5. 5

   Ship and watch field data

   Deploy. Give it time to gather visits. After the change, check the same URL in PageSpeed Insights across the next 28 days. When the 75th percentile LCP drops under 2.5 s, the page passes.

Field data wins. It reflects real users over 28 days on Android and desktop Chrome, at the 75th percentile. It is what Search Console and PageSpeed Insights use for the Core Web Vitals assessment. iOS is not in that dataset. Low traffic URLs may fall back to origin or show nothing.

Lab runs are for debugging. Lighthouse runs once on a simulated mid range phone over throttled 4G. WebPageTest runs on real browsers and connections that you choose. Run several times to steady your read, then act on patterns you see in filmstrips and waterfalls, not on a single score swing.

• Use the same URL with cache busting off. Avoid running behind a login where the tools cannot reach.
• In WebPageTest pick a location near your audience, a real mobile browser, and a 4G profile to mirror Lighthouse. Run 3 to 5 times and read the median.
• Capture first and repeat views to measure caching. Save the test link.
• In PageSpeed Insights, keep notes of the date. Remember that field trends lag by 28 days.
• When you ship a change, annotate your changelog with the test links and what you changed on the render path.

Google applies the page experience signal to field data at the Good thresholds. Relevance and content weigh more, but a pass helps. The Lighthouse score is not a ranking factor. Mobile first indexing is complete, so measure mobile first and read the Mobile tab before Desktop in PageSpeed Insights as your main view of real users.