# WebPageTest vs PageSpeed Insights

Use PageSpeed Insights for the call on pass or fail. Use WebPageTest to watch the page load and find the blockers. This page shows how to choose and how to run both on one slow page.

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

## Verdict: which to use when

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.

## What each tool measures

| Use case | PageSpeed Insights | WebPageTest |
| --- | --- | --- |
| Decide if Search sees the page as fast | Shows Chrome UX Report field data over 28 days at URL or origin level, with a Core Web Vitals assessment | Not built for field data, runs synthetic tests you control |
| See why a load is slow | Runs Lighthouse once in lab conditions with audits and a score | Filmstrips, waterfalls, request details, CPU, connection and cache control |
| Control device, network, location | Limited: one simulated mid range phone and desktop lab run | Rich controls: real browsers, many locations, 3G to fibre profiles, first and repeat views |
| Compare before and after a code change | Rerun and compare lab audits; field trends lag by 28 days | A/B experiments on a run, repeatable scripts, side by side waterfalls |
| Share and track a single test | Public URL for the PSI report | Shareable test IDs and links; export waterfalls and video |

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.

## How to read PageSpeed Insights for a decision

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

> When PageSpeed Insights field and lab disagree, trust the field data. It reflects real users, devices and networks over 28 days.

## How to use WebPageTest to find the bottleneck

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

## A one page workflow: from slow to shipped

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

## Common findings and how to fix them

| Symptom in tests | Likely cause | Change to ship |
| --- | --- | --- |
| Hero appears late in filmstrip; LCP is high | Render blocking CSS; hero image lazy loaded or discovered late; slow TTFB | Inline critical CSS; load rest with media=print and onload; no loading=lazy on hero; fetchpriority=high; preload CSS background; cache HTML or serve via CDN |
| Layout jumps after first paint; CLS spikes | Ads, images or iframes without size; banners injected above content; font swap metrics mismatch | Set width and height or aspect ratio; reserve min height for slots; use overlays for notices; size adjust and ascent override on fallback font; use transform for animations |
| Interactivity lags; long tasks in the Performance trace | Heavy handlers; hydration of large frameworks; third party scripts; large DOM; sync layout thrash | Break long tasks with scheduler.yield or setTimeout; render the visual change first; defer or remove third party code; move work to web workers; reduce DOM size |
| Big gap between first and repeat view | No caching or big third party bundles | Add cache headers and immutable asset URLs; load third party on interaction or after load; preconnect only where needed |
| Slow start of HTML in the waterfall | High TTFB: redirects, distant origin, server rendering time | Cut redirects; cache or pre render HTML; use a CDN; enable HTTP/2 or HTTP/3; keep alive; consider 103 Early Hints |
| Many blocking requests before first paint | Synchronous scripts in head; CSS @import chains; unused CSS | Add defer or async, module scripts defer by default; remove @import; purge unused CSS |

## Field vs lab: what to trust and how to reconcile

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.

## Set up good, comparable tests

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

## Why PageSpeed Insights gets the final say for Search

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.

## The tools compared

### WebPageTest

Synthetic performance testing with deep request analysis and control. (webpagetest.org)

Good at: Filmstrips and waterfalls that show what blocks paint; Choice of real browsers, locations and connection profiles; First and repeat views to compare cache effects; On run experiments to try deferring or inlining resources.

Choose it when You need to see why a page is slow and test changes under realistic conditions you control.

Not for: Field data or a Core Web Vitals pass. It does not show the Chrome UX Report assessment.

### PageSpeed Insights

Showing field data from the Chrome UX Report and running Lighthouse in one URL view. (pagespeed.web.dev)

Good at: Core Web Vitals assessment from real Chrome users over 28 days; A single Lighthouse lab run with audits and a score; Mobile and Desktop tabs to compare contexts.

Choose it when You need the pass or fail that matters for Search and a quick lab run to form a hypothesis.

Not for: Detailed request level debugging, controlled locations or connection profiles. Use WebPageTest for that.

**Verdict.** Use PageSpeed Insights to make the call, because it shows the 28 day field data and the Core Web Vitals assessment that Search cares about. Use WebPageTest to do the real debugging: watch the filmstrip, read the waterfall, choose a realistic location and network, and run first and repeat views. Pair them: decide in PageSpeed Insights, diagnose in WebPageTest, then confirm the shipped fix as the field data improves over time.

## Questions

### Is WebPageTest better than PageSpeed Insights?

They serve different jobs. Use PageSpeed Insights to decide if a URL passes Core Web Vitals in the field. Use WebPageTest to see the load frame by frame, inspect waterfalls and test different locations, connections and repeat views. Together they give you the verdict and the root cause.

### How do I test a page for free?

Run the URL in PageSpeed Insights for field data and one Lighthouse lab run. Then run it in WebPageTest with a nearby location and a mobile browser for a filmstrip and waterfall. Both offer free tests with limits as of 2026.

### What if PageSpeed Insights shows no field data for my URL?

There may be too little traffic to build a URL level view. PageSpeed Insights will use origin level data if available, or show nothing. You can still use the lab run and WebPageTest to debug and improve the page. As traffic grows, field data will appear over a 28 day window.

### Why do my Lighthouse scores change between runs?

Lighthouse is one simulated load, so scores vary with network noise and page variability. Read the audits and the waterfall patterns instead of chasing a round number. Run several times, then confirm the change in WebPageTest and finally in PageSpeed Insights field data over time.

### How do I improve INP on an interactive page?

Find long main thread tasks and heavy handlers. Break work up with scheduler.yield or setTimeout. Render the visual change first, then do the rest. Trim third party scripts, reduce DOM size, and move heavy work to a web worker. Aim for about 200 ms at the 75th percentile in the field.

### Can I rely on WebPageTest for my Core Web Vitals pass?

No. WebPageTest is synthetic. Your Core Web Vitals assessment comes from the Chrome UX Report, which PageSpeed Insights and Search Console show. Use WebPageTest to fix the cause, then wait for the field data to reflect the change.

## Read next

- [Lighthouse vs PageSpeed Insights: lab and field](https://porteur.ai/compare/lighthouse-vs-pagespeed-insights): Use Lighthouse for repeatable lab checks, PageSpeed Insights for real-user field data. See why scores differ and which to trust for fixes and reporting.
- [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.
- [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.
- [Largest Contentful Paint: what slows it and what fixes it](https://porteur.ai/guides/largest-contentful-paint): See what usually counts as LCP, what makes it slow, how to fix it in order, and how to read it in Lighthouse and field data.
- [How to improve Interaction to Next Paint](https://porteur.ai/guides/how-to-improve-interaction-to-next-paint): Cut slow interactions to under 200 ms. See where INP hurts, why Lighthouse misses it, and the fixes that make your page feel instant.
- [How to fix cumulative layout shift, cause by cause](https://porteur.ai/guides/how-to-fix-cumulative-layout-shift): See how CLS is measured, find the shifting elements, fix each common cause, and check field data after 28 days to confirm it worked.

Paste your slow URL to get a free check that reads your site, the searches around it and rivals on them in about thirty seconds, and shows three findings you can ship. Free check: https://porteur.ai/