Lighthouse vs WebPageTest: Which Performance Tool Should You Use in 2026?

Lighthouse and WebPageTest are the two most widely used web performance tools, but they answer fundamentally different questions. Lighthouse is a fast, local audit tool built into Chrome DevTools that scores your page against a checklist of best practices and returns synthetic lab data in under 30 seconds. WebPageTest is a deep-inspection synthetic testing platform that runs your page in a globally distributed, real-device lab and produces detailed waterfall charts, filmstrip video, and multi-step scripting. Choosing between them — or knowing how to use them together — depends on the problem you are trying to solve, your team's workflow, and how precisely you need to match Chrome User Experience Report (CrUX) field data. This guide works through every meaningful dimension of the comparison so you can make that call with confidence.

How each tool works: data sources and methodology

Understanding the output of any performance tool starts with understanding how it collects data. Both Lighthouse and WebPageTest produce lab data — they load your page in a controlled browser environment rather than aggregating measurements from real users. This makes them categorically different from field data sources like CrUX, which captures performance as experienced by actual visitors. Lab data is deterministic and actionable; field data is statistically representative but noisy. Knowing which category you are working with changes how you interpret results.

Lighthouse 12 (the current stable version as of 2026) operates in two modes. The most common — accessible directly in Chrome DevTools under the Lighthouse tab, via the lighthouse CLI, or via the PageSpeed Insights API — uses simulated throttling. Lighthouse runs the page at full native speed, captures a trace, then post-processes that trace to simulate how the page would have loaded on a 4G mobile connection with 4x CPU slowdown. This simulation runs in under 30 seconds and requires no special infrastructure, which is why it integrates so naturally into CI pipelines. The trade-off is accuracy: simulated throttling abstracts away real-world variables like TCP connection setup, GPU rendering pipelines, and device thermal state, which can cause LCP values to deviate from CrUX field data by 15-30% on complex pages.

Lighthouse also supports DevTools throttling mode, which applies actual network and CPU throttling at the operating system level during the run. This mode is slower and less repeatable but produces trace data closer to real conditions. In either mode, Lighthouse scores are composites: the overall Performance score is a weighted average of five metrics (FCP, Speed Index, LCP, TBT, and CLS). A single Lighthouse score number therefore tells you very little about individual Core Web Vitals without drilling into the per-metric data.

WebPageTest (now operated by Catchpoint after its acquisition from Google) takes a different approach. Tests run in a geographically distributed fleet of physical and virtual test agents. The physical device lab includes real Android handsets (Moto G4, Moto G71, Pixel 6a) and iOS devices, giving you access to hardware identical to what a significant fraction of your users actually use. Network conditions are applied by genuine packet shaping on the test agent network interface, not by post-processing simulation. As a result, WebPageTest's LCP readings on the Moto G4 - 4G preset correlate much more closely with CrUX p75 mobile values than Lighthouse simulated mode does.

WebPageTest also records a real video of the page loading and derives Speed Index from that video. Its waterfall chart captures every HTTP request, DNS lookup, TLS handshake, and server processing delay in full fidelity. You see exactly which resources blocked rendering and exactly which resource was the LCP element and when it started downloading. This level of detail is not available in Lighthouse's trace output without manual analysis in the DevTools Performance tab.

Core Web Vitals measurement accuracy

CWV accuracy matters most when you are trying to predict whether your page will pass Google's Search Console thresholds before launching a change. The question is: does the tool's lab measurement agree with what CrUX will eventually record for real users?

The INP row deserves particular attention. Lighthouse does not measure INP directly because INP requires actual user interaction — clicks, key presses, pointer events — that cannot be automated in a passive load test. Instead, Lighthouse uses Total Blocking Time (TBT) as a lab-side proxy for interaction responsiveness. TBT measures how long long tasks on the main thread block input processing during page load. TBT correlates statistically with INP across large populations, but it is a poor predictor for specific pages, particularly those where INP is driven by post-load interactions rather than load-time scripting.

WebPageTest supports INP measurement through its scripting API when you define interaction steps (clicks, form inputs, scrolls). This produces actual INP values rather than a proxy. For pages where INP is a concern — heavily interactive applications, e-commerce product pages with configurators, single-page apps with complex state — WebPageTest's scripted INP measurement is meaningfully more useful than Lighthouse's TBT.

For a practical workflow, you can validate your Lighthouse scores against real-user data using the CWV Score Checker, which pulls live CrUX data for any URL and lets you compare lab estimates against field actuals.

Real-device testing and throttling models

The throttling model is the single biggest source of divergence between Lighthouse scores and real-user experience on mobile. Most web developers test on fast MacBook Pros or desktop workstations with multi-gigabit connections, then deploy to users on mid-range Android phones on 4G LTE with 3-5ms of additional CPU contention from background apps. Simulated throttling in Lighthouse attempts to bridge this gap computationally, but it cannot fully account for thermal throttling, memory pressure, or GPU rendering bottlenecks on physical low-end hardware.

WebPageTest's real-device test agents eliminate this gap. When you select the Moto G4 - Cable or Moto G71 - 4G preset, the browser executes on that exact hardware. Font rendering, image decode, and JavaScript just-in-time compilation happen in the same physical environment your users experience. The 2026 WebPageTest device lab also includes agents running on ARM-based chips comparable to Snapdragon 695 and Dimensity 900, which represent a large segment of the global Android market.

For TTFB specifically, real-device testing matters because TTFB is a network-round-trip measurement. Lighthouse simulates TTFB by applying a fixed latency offset to the cached trace; it cannot simulate geographic routing, CDN PoP selection, or server cold-start variance. WebPageTest agents test from real network locations in the US, Europe, Asia-Pacific, and Latin America, giving you a view of TTFB variance across your user geography. If you are tuning TTFB for a global audience, only WebPageTest gives you the regional breakdown you need.

Filmstrip, waterfall, and visual completeness analysis

The filmstrip and waterfall are where WebPageTest has no meaningful competition. When you run a test, WebPageTest records a 10fps video of the page loading, then displays that video as a frame-by-frame filmstrip synchronized with the waterfall timeline. You can hover over any waterfall entry and see exactly which frame corresponds to when that resource finished loading. For LCP investigation, this is invaluable: you see the exact moment the LCP element appeared, the exact chain of requests that preceded it, and any render-blocking resources that delayed it.

The waterfall chart itself captures DNS lookup duration, TCP connection time, TLS negotiation time, request send time, server response time (TTFB for that resource), and download duration — all broken out per request. Request rows are color-coded by resource type (HTML, CSS, JS, fonts, images, API calls), and you can filter by domain, content type, or timing segment. Connection view shows which requests shared keep-alive connections. The resulting visualization makes waterfall bottlenecks immediately obvious in a way that Lighthouse's opportunity list never quite achieves.

WebPageTest also calculates Speed Index from the actual filmstrip video. Speed Index quantifies how quickly the visual content of a page fills in above the fold — lower values mean more content appears sooner. Because WebPageTest's Speed Index derives from real video frames captured during a real page load, it accurately reflects rendering delays caused by CSS animations, font loading with FOIT, lazy-loaded hero images, and late-arriving third-party widgets. Lighthouse's simulated Speed Index is derived from the trace rather than video and therefore misses some of these rendering-layer effects.

Lighthouse does produce a filmstrip in simulated mode, visible in the PageSpeed Insights report and the Lighthouse HTML output. It is useful for a quick sanity check — confirming that your page starts rendering before 1 second, for instance — but it is a simulated reconstruction rather than a video capture and contains fewer frames (typically 5-10 versus WebPageTest's 100+ at 10fps).

CI/CD integration and automation

Lighthouse was designed with CI integration in mind. The lighthouse Node.js package runs headlessly in any environment that has Chrome or Chromium installed, which means it works in GitHub Actions, CircleCI, Jenkins, GitLab CI, and Vercel's build pipeline without any external dependencies.

Lighthouse CI (LHCI) is the official automation layer on top of Lighthouse. It collects multiple runs per commit (configurable, typically 3-5 to average out variance), uploads results to a LHCI server for historical trending, and lets you define budgets that fail the CI check if any metric degrades. The following GitHub Actions snippet shows a minimal LHCI integration:

name: Lighthouse CI
on: [push]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.14.x
          lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

With an .lighthouserc.json assertions block, you can gate merges on specific metric thresholds: for example, failing CI if LCP exceeds 2.5s or TBT exceeds 300ms. Median scores across three runs are used by default, which reduces the impact of single-run outliers caused by serverless cold starts or network jitter during the test.

WebPageTest provides a REST API at https://www.webpagetest.org/runtest.php that accepts test parameters and returns a test ID. You can poll for results and retrieve the full JSON results including all waterfall data. The webpagetest Node.js package wraps this API. Using WebPageTest in CI is practical but involves more setup: you need an API key, you are subject to rate limits on the free tier (approximately 200 tests per day), and test turnaround time is 60-180 seconds rather than Lighthouse's 10-30 seconds. For teams that need real-device results on every pull request, WebPageTest's hosted Pro plan removes rate limits and provides priority queuing, but this adds monthly cost to what Lighthouse can do for free.

The pragmatic recommendation is to use Lighthouse CI for every commit and every pull request, and trigger a WebPageTest run only on merges to the release branch or when a Lighthouse regression triggers an alert. You can automate this two-tier approach through the same GitHub Actions workflow by conditioning the WebPageTest step on branch name or Lighthouse result threshold. Learn how to set this up end-to-end in the performance monitoring setup guide.

Multi-step user flow testing

Many of the most performance-critical interactions on a website are not simple page loads. Add-to-cart flows, checkout sequences, search-and-filter interactions, authentication redirects, and infinite scroll patterns all involve multiple navigations or interactions that a single-URL test cannot capture.

WebPageTest has supported multi-step scripting for years via its tab-separated script format. A script can navigate to a page, wait for an element, click it, fill a form field, wait for navigation, and record timing at each step. The 2025 WebPageTest update introduced a JavaScript-based scripting API that is significantly more expressive:

// WebPageTest script: measure checkout flow LCP at each step
steps:
  - navigate: https://example.com/product/widget
    label: Product page
    wait_for: .add-to-cart-button
  - click: .add-to-cart-button
    label: Add to cart
    wait_for: .cart-sidebar
  - navigate: https://example.com/checkout
    label: Checkout page
    wait_for: .checkout-form

Each step produces its own filmstrip, waterfall, and CWV readings. You can see exactly which step has the highest LCP, where your INP regression occurs in the checkout sequence, and which API calls slow down the order confirmation screen. This granularity is simply unavailable in any single-URL test.

Lighthouse 12 added user flow API support, which provides a comparable multi-step capability in Node.js. A Lighthouse user flow lets you write Puppeteer-style navigation and interaction steps and receive individual Lighthouse reports for each step. The API is mature and well-documented:

import { launch } from 'puppeteer';
import { startFlow } from 'lighthouse';

const browser = await launch({ headless: true });
const page = await browser.newPage();
const flow = await startFlow(page, { name: 'Checkout flow' });

await flow.navigate('https://example.com/product/widget');
await flow.startTimespan({ stepName: 'Add to cart' });
await page.click('.add-to-cart-button');
await page.waitForSelector('.cart-sidebar');
await flow.endTimespan();
await flow.navigate('https://example.com/checkout');

const report = await flow.generateReport();

The Lighthouse user flow API runs locally in your development environment, which means it measures your local machine's performance characteristics rather than a standardized device. For development-loop feedback ("did my refactor make this step faster?"), this is ideal. For release-quality validation against field data, WebPageTest's real-device scripting produces more trustworthy absolute values.

Cost, access, and tooling ecosystem

Cost is a real decision factor, particularly for teams at smaller organizations or open-source projects with limited tooling budgets.

Lighthouse's zero marginal cost makes it uniquely suitable for high-frequency testing scenarios: every commit in a monorepo, every PR in a large team, or every page in a 10,000-page site crawl. The performance tools directory lists additional free and paid tools that complement both Lighthouse and WebPageTest, including real user monitoring (RUM) solutions that provide field data to validate lab findings from either tool.

WebPageTest's Pro plans (starting at around $15/month for small teams as of 2026) add private test agents for testing behind authentication or on staging environments, higher API rate limits, and persistent historical data without self-hosting an LHCI server. For teams that run WebPageTest as a release gate rather than a continuous monitoring tool, the free tier is often sufficient.

Which should you choose? A decision framework

The answer almost always involves using both tools at different points in your development cycle. Here is a practical framework:

Use Lighthouse when you:

• Need feedback in under 30 seconds during active development
• Want to gate pull requests on performance budgets in CI/CD at zero marginal cost
• Are doing a quick structural audit — render-blocking resources, image sizing, unused JavaScript
• Need to test a staging environment behind authentication that cannot be reached by external test agents
• Are comparing relative changes between two versions of the same page (Lighthouse variance is acceptable when both runs use the same conditions)

Use WebPageTest when you:

• Need to validate CWV thresholds against what CrUX will actually report for real mobile users
• Are debugging an LCP or TTFB regression where you need full waterfall fidelity to identify the root cause
• Need to test from specific geographic regions to understand regional TTFB variance
• Are measuring the performance of multi-step user flows like checkout or onboarding sequences
• Want Speed Index data from real video rather than a simulated filmstrip
• Need to test on a specific physical device your users are on (Moto G71, Pixel 7a)

For a deeper look at measuring Core Web Vitals end-to-end — from choosing tools to interpreting CrUX data — see the full guide to measuring Core Web Vitals. For tool selection when evaluating your specific site, the tools section includes the CWV Score Checker that pulls live PageSpeed Insights data and highlights the gap between your lab scores and field data, helping you decide how much to invest in real-device WebPageTest validation.

If you are just starting out with Lighthouse and want a structured walkthrough of interpreting every section of a Lighthouse report, the Lighthouse audit walkthrough tutorial covers the full report from Performance score to accessibility findings.