Performance forensics & continuous monitoring

WebPageTest diagnoses the problem. AuditJet quantifies what it's costing you.

WebPageTest is the gold standard for diagnosing why a page is slow. This guide explains how it works — waterfall charts, filmstrips, throttling, first vs repeat view — and shows where continuous monitoring picks up where on-demand testing leaves off.

Run Free Audit Start Monitoring

What is WebPageTest?

The open-source tool that set the standard for web performance analysis

WebPageTest is an open-source web performance testing tool originally created by Patrick Meenan while working at AOL. It was later open-sourced, continued at Google, and is now maintained by Catchpoint — a network intelligence company that acquired the project. The public version at webpagetest.org is free for anyone to use. A commercial tier called WPT Pro offers private test environments, full API access, additional test agents, and team features for organisations that need to integrate performance testing into their engineering workflows.

The tool has earned its reputation as the gold standard for on-demand web performance analysis. No other free tool comes close to its diagnostic depth. Where Google Lighthouse produces a scored audit report, WebPageTest goes further: it runs real browsers on real or virtualised hardware, captures every byte of network traffic, records a video of the page loading, and generates a rich set of visualisations — including waterfall charts and filmstrips — that let you see precisely what is happening at each millisecond of a page load.

The primary users of WebPageTest are performance engineers, frontend developers, and DevOps teams doing deep diagnostic work. It is the tool you reach for when something is noticeably wrong and you need to understand the root cause at a granular level — which third-party script is blocking rendering, why Time to First Byte is high for users in a specific region, or exactly how a layout shift is being triggered.

A common point of confusion is the relationship between WebPageTest and Lighthouse. Lighthouse is an audit engine developed by Google — it is shipped inside Chrome DevTools, used by PageSpeed Insights, and now integrated into WebPageTest as one of its outputs. Lighthouse runs a controlled set of checks and returns a performance score. WebPageTest is a broader test harness: it can run Lighthouse as part of its suite, but it also captures raw waterfall data, video, filmstrips, and repeat-view tests that go well beyond what any single Lighthouse run produces. The key distinction is that WebPageTest uses a real browser (Chrome, Firefox, or Safari depending on your configuration) on real or virtualised hardware. Lighthouse as used in most contexts is a synthetic audit engine — fast and standardised, but not the same as a full browser session on physical or emulated hardware in a specific geographic location.

How WebPageTest Works

First views, waterfalls, filmstrips, and throttling — explained

When you submit a URL to WebPageTest, it doesn't just load the page once and return a number. It runs a sequence of tests designed to reveal the full picture of your page's performance behaviour across different conditions and visitor types.

First view vs repeat view

WebPageTest runs every test at least twice. The first view simulates a brand-new visitor — the browser cache is completely empty, so every resource (HTML, CSS, JavaScript, images, fonts) must be downloaded fresh from the origin server or CDN. The repeat view simulates a returning visitor — the browser cache is already populated from the first run, so cached assets load instantly from disk. Comparing the two tells you what your caching strategy is actually delivering. If your repeat view isn't significantly faster, your cache-control headers are probably misconfigured — a surprisingly common issue that has a significant impact on real-user performance.

CPU throttling

WebPageTest can artificially slow the browser's JavaScript execution to simulate low-end mobile hardware. This matters enormously. A modern developer laptop can parse and execute a large JavaScript bundle in under 200ms. A budget Android phone from 2019 might take 2–4 seconds for the same task. If you only test on fast hardware, you'll consistently underestimate the performance problem your median mobile user is experiencing. CPU throttling is how WebPageTest (and Lighthouse) bridge that gap — they slow the virtual CPU to reflect real-world mobile constraints, producing scores that more accurately represent what users on lower-end devices actually encounter.

Network throttling

Beyond CPU, WebPageTest lets you simulate different network connection speeds — 3G, LTE, cable, or fully custom bandwidth and latency settings. A page that loads in under a second on a wired connection might take four or five seconds on a throttled 3G connection, because slow networks amplify the cost of unoptimised resources, too many requests, and large payloads. Network throttling reveals what users on mobile networks — which still account for the majority of web traffic globally — are actually experiencing. You can combine CPU throttling with network throttling to simulate a slow phone on a slow network, which is often the worst-case scenario your real users face.

Waterfall chart

The waterfall chart is WebPageTest's most powerful diagnostic output. It visualises every HTTP request the browser makes during the page load — HTML, CSS, JavaScript, images, fonts, analytics scripts, A/B testing scripts, everything — as a horizontal bar on a shared timeline. The position of each bar shows when the browser started and finished each request. The colour coding shows the breakdown between DNS lookup, TCP connection, TLS handshake, time to first byte, and content download for each resource. You can immediately see which resources are blocking rendering (shown in a different colour and offset from the critical path), which resources load in parallel, which third-party scripts are taking an unexpectedly long time, and where the real bottlenecks are. A waterfall with dozens of render-blocking scripts stacked at the top is immediately visually obvious — and immediately actionable.

Filmstrip view

The filmstrip is a sequence of screenshots taken every 100–500ms during the page load, showing exactly when content becomes visible to the user. This is invaluable because raw technical metrics can be misleading in isolation. A page might technically finish loading in 2.5 seconds, but the filmstrip might reveal that the entire viewport was blank white until second 2.2 — meaning users stared at nothing for the first 88% of the load time. The filmstrip makes this immediately visible. It's particularly useful for diagnosing issues like render-blocking CSS, slow hero image loads, or large above-the-fold JavaScript that delays any visible content. For visual regression work — comparing a before and after an optimisation change — the filmstrip is often more informative than any numeric metric.

Video capture and visual comparison

WebPageTest records an actual video of the page loading during the test. This video can be played back directly, or compared side-by-side with another test run — for example, a before-and-after comparison of a performance optimisation. This visual comparison mode is one of WebPageTest's most compelling features for performance engineering work: rather than arguing about whether LCP improved by 200ms, you can show a video of the old experience versus the new one, frame by frame. The visual comparison also powers Speed Index, a composite metric that measures how quickly the visible page content fills in over time.

Scripting for multi-step flows

Advanced WebPageTest users can write test scripts that simulate multi-step user interactions — log in, add a product to a cart, navigate to checkout. This is essential for e-commerce and SaaS teams who care about the performance of authenticated flows, not just public landing pages. Scripted tests can also set cookies, execute JavaScript, click elements, and capture custom metrics at any step of the flow. This makes WebPageTest usable for testing the performance of your entire conversion funnel, not just the homepage.

Key Features

What WebPageTest offers beyond basic performance scores

WebPageTest has accumulated a rich set of features over years of active development. Beyond the core waterfall and filmstrip, several capabilities make it particularly powerful for teams doing serious performance engineering work.

Lighthouse integration

WebPageTest runs a full Lighthouse audit alongside its own test suite, giving you both the Lighthouse performance score (LCP, INP, CLS, and the composite score) and the deeper WPT diagnostic data in a single test run. This means you don't have to choose between the standardised scoring that stakeholders understand and the forensic depth that engineers need. You get both, with the Lighthouse results contextualised by the waterfall and filmstrip from the same browser session.

Experiments (A/B testing)

WPT's Experiments feature lets you run two versions of a page side by side — your current production version and a proposed change — and see which loads faster with a visual comparison. This is invaluable for validating that a proposed optimisation actually improves performance before deploying it. You can compare waterfalls, filmstrips, and all Lighthouse metrics between the two versions, and share a link to the comparison with your team.

Carbon Control

WebPageTest now includes a Carbon Control feature that estimates the CO₂ footprint of a page load, based on the amount of data transferred and the estimated energy mix of the server infrastructure. This is an emerging area of web sustainability and is becoming increasingly relevant for organisations with sustainability reporting requirements. Heavy pages — particularly those with large unoptimised images or excessive JavaScript — have a measurable carbon cost that Carbon Control makes visible.

Global test locations

WebPageTest maintains test agents in 40+ locations worldwide — across North America, Europe, Asia Pacific, South America, and Africa. This matters because CDN performance, DNS resolution time, and raw network latency vary enormously by region. A page that loads quickly for users in the United States might load very slowly for users in Southeast Asia if your CDN isn't properly configured for that region. Testing from multiple locations is the only way to understand the geographic distribution of your users' actual experience.

Custom metrics

WebPageTest lets you define custom JavaScript metrics to capture from the browser during the test. Any value accessible through Web APIs — resource timing entries, performance marks, Long Tasks, layout shift entries, element visibility timing — can be captured and tracked. This is particularly useful when you want to correlate technical performance data with business metrics, or when you need to track a specific UI element's appearance time that isn't covered by standard metrics.

API access

The WebPageTest API (available in the Pro tier) lets you automate tests programmatically. You can integrate WPT tests into your CI/CD pipeline so that performance is checked on every pull request, build custom dashboards that aggregate WPT results over time, or write scripts that automatically run tests from multiple locations and compare results. The API supports all the same test options as the web interface, including scripted multi-step flows.

Honest Assessment

WebPageTest's genuine strengths — and real limitations

WebPageTest is an excellent tool. It deserves its reputation. But no tool is the right tool for every job — and understanding WebPageTest's limitations is as important as understanding what it does well.

Strengths

Unmatched diagnostic depth — nothing else comes close for deep forensic analysis of a specific page load.
Free for public tests — you can run detailed tests at any time without a subscription.
Open-source with an active community, which means regular improvements and a large body of tutorials and documentation.
Filmstrip and video comparison is genuinely irreplaceable for visual performance work — you can see the user experience, not just a number.
Real browsers on real or virtualised hardware, not just a headless script — the results reflect actual browser behaviour.
Custom scripting enables complex multi-step test scenarios that go far beyond basic page load testing.
40+ global test locations for understanding CDN performance and regional latency differences.

Limitations

No continuous monitoring — every test is manual. You have to remember to run tests, and they only reflect the moment you ran them.
No alerting — nothing fires when your score drops after a deploy at midnight or a third-party script update on a Saturday.
No regression detection — you won't know when a deploy broke something unless you happened to run a manual test immediately before and after.
Results vary between runs due to network variance and resource competition on shared test infrastructure — single-run results can be misleading.
Requires performance expertise to interpret — waterfall analysis is not approachable for non-engineers, and getting value from WPT data has a meaningful learning curve.
No revenue impact modelling — WebPageTest tells you that LCP is 4.2 seconds but doesn't tell you what that costs in conversion rate.
No competitive monitoring — you can't easily track a competitor's performance over time alongside your own.

The Core Distinction

On-demand testing vs continuous monitoring: why both matter

This is the most important conceptual distinction in web performance tooling, and it's one that teams often miss until they've experienced the consequences of not making it.

WebPageTest is a diagnostic tool. You use it when you already know there is a problem, or when you are actively working on a performance optimisation and need to understand root cause. It answers the question: "Why is this page slow?" It does not answer: "Is my site performing well right now, and is it performing better or worse than it was yesterday?"

The analogy is straightforward. WebPageTest is like going to the doctor when you feel sick — you show up, describe symptoms, get a detailed diagnosis, and leave with a treatment plan. Continuous monitoring is a heart rate monitor that runs 24 hours a day, 7 days a week — it doesn't tell you why your heart rate spiked, but it tells you immediately when something changes. Both are valuable. They answer completely different questions. You wouldn't say a heart rate monitor replaces a doctor, and you wouldn't say a doctor visit replaces a heart rate monitor.

Teams that rely only on periodic manual WebPageTest runs discover regressions through user complaints, support tickets, or SEO ranking drops — typically one to three weeks after the regression first occurred. By that point, the damage has accumulated. The regression may have run through an entire weekend of high-traffic shopping, several news cycles, or a period of particularly high conversion rate sensitivity.

There is also what we call the deploy gap. Between developer-initiated releases, performance can degrade through channels that don't trigger anyone to run a manual test: a third-party analytics script vendor quietly ships a larger bundle, a CDN configuration change alters cache hit rates, a new A/B test variant loads additional JavaScript, an ad tag from a programmatic partner begins serving heavier creatives. None of these changes show up in a pull request. None of them prompt a developer to open WebPageTest. They show up in your users' experience, and in your conversion rate — but only if you're monitoring continuously will you notice them within hours rather than weeks.

The practical framework

Use continuous monitoring to detect the signal — "something changed". Use WebPageTest to diagnose the root cause — "here is exactly what changed and why". The two tools are not alternatives. They are different stages of the same workflow.

Honest Comparison

AuditJet vs WebPageTest: genuinely complementary tools

We want to be honest about this comparison because we think honesty leads to better outcomes for performance teams. WebPageTest wins in certain areas unconditionally. AuditJet wins in others. The right answer for most serious teams is to use both.

Capability	AuditJet	WebPageTest
Continuous monitoring	Hourly automated Lighthouse scans with regression alerts. Always on.	On-demand tests only. No scheduling, no automatic monitoring.
Waterfall analysis	Lighthouse-based metrics and score trends. No deep waterfall.	Industry-leading waterfall charts with request-level timing breakdown.
Filmstrip & video	Not available.	Full filmstrip at 100–500ms intervals and video recording of every load.
Regression alerting	Slack, email, and webhook alerts within hours of a score regression.	No alerting. You must re-run tests manually to detect regressions.
Revenue impact	Connects CWV score changes to estimated conversion loss and revenue risk.	Not available.
AI Fix Blueprints	Code-level fix guidance per Lighthouse issue, generated automatically (Watchdog+ plan).	Not available.
First / repeat view testing	Single Lighthouse run per interval.	Automatic first and repeat view on every test, revealing real cache behaviour.
CPU & network throttling	Lighthouse standard mobile throttling profiles.	Full custom throttling — any CPU multiplier, any bandwidth and latency setting.
Multi-step scripting	Not available.	Full scripting support for authenticated flows, multi-page journeys, and custom interactions.
Competitive monitoring	Monitor competitor URLs alongside your own pages.	You can test any URL manually, but no automated competitive tracking.
Global test locations	Standardised test environment.	40+ worldwide test agents for regional performance analysis.
Pricing	From $49/month (Watchdog plan). Free audit report available.	Free for public tests. WPT Pro for API, private tests, and advanced features.

The recommended workflow is not to choose between them. When AuditJet detects that your LCP regressed by 800ms after a Tuesday deployment, your next step is to open WebPageTest and run a detailed diagnostic to understand exactly what changed — which request is slower, whether a new render-blocking script appeared, what the filmstrip shows. AuditJet catches the signal. WebPageTest explains it.

This is why we genuinely recommend WebPageTest as a complementary tool rather than positioning it as a pure competitor. The teams that get the best performance outcomes are the ones using both: continuous monitoring for awareness, and on-demand forensics for diagnosis. Using only WebPageTest means you're flying blind between manual test runs. Using only AuditJet means you can detect regressions but may need deeper tooling to understand root cause in complex cases.

Decision guide

Who should use which — and when

Use WebPageTest if:

Deep diagnostic work

You're actively working on a performance optimisation and need waterfall-level root cause analysis.
You want to compare two page versions visually using filmstrip and video comparison.
You need to test performance in a specific geographic region or on a specific network type.
You want to test authenticated flows or multi-step user journeys using WPT scripting.
You need to validate a fix before shipping — pre/post comparison with visual proof.

Use AuditJet if:

Continuous performance protection

You want to know within hours when a regression occurs, not next time you remember to run a test.
You need to connect performance changes to estimated revenue impact for stakeholder reporting.
You want automated alerts when Core Web Vitals drop below a threshold after any deploy.
You need AI-generated, code-level fix guidance without running a manual diagnostic every time.
You want to monitor competitor performance alongside your own pages on the same dashboard.

Use both:

The complete workflow

AuditJet monitors continuously and catches the regression signal — 'LCP regressed by 900ms at 11:47 PM'.
WebPageTest diagnoses the root cause — 'a new analytics script is render-blocking above the fold'.
AuditJet tracks the fix over time and confirms the regression is resolved.
WebPageTest provides the before/after visual proof for the post-mortem.
Neither tool makes the other redundant. Together, they cover the full performance workflow.

Frequently asked questions

WebPageTest, waterfalls, and continuous monitoring — answered

What is a waterfall chart in web performance?

A waterfall chart is a timeline visualisation of every HTTP request a browser makes when loading a page — HTML, CSS, JavaScript, images, fonts, and third-party scripts. Each resource is drawn as a horizontal bar showing when the browser started and finished downloading it. The chart also colour-codes each phase of the request: DNS lookup, TCP connection, TLS handshake, time to first byte, and content download. You can immediately see which resources are blocking rendering, which load in parallel, and where the real bottlenecks are. WebPageTest produces some of the most detailed waterfall charts available, annotated with paint events, CPU activity, and main thread blocking markers.

What is the difference between first view and repeat view in WebPageTest?

The first view simulates a brand-new visitor with an empty browser cache — every resource must be downloaded fresh. The repeat view simulates a returning visitor with a warm cache — previously cached assets load instantly from disk. Comparing the two is one of the most direct ways to evaluate your caching strategy. If your repeat view is not significantly faster than your first view, you likely have suboptimal cache-control headers, are serving uncacheable personalised content unnecessarily, or have resources that are being re-validated on every request.

What is CPU throttling and why does it matter?

CPU throttling artificially slows the browser's JavaScript execution to simulate low-end mobile hardware. A modern laptop processes JavaScript many times faster than a budget Android phone. Without throttling, performance scores on developer machines systematically underestimate how slow the page is for median users on lower-end hardware. CPU throttling corrects for this by slowing the virtual CPU, producing scores that better reflect the real experience of users who aren't on high-end devices. It's particularly important for measuring Time to Interactive and Total Blocking Time, which are dominated by JavaScript parse and execution costs.

How does WebPageTest differ from Lighthouse?

Lighthouse is an audit engine that runs a scripted set of checks and returns a performance score. WebPageTest is a full test harness that uses real browsers on real or virtualised hardware, captures complete network traffic data, records a video of the page loading, and generates waterfall charts and filmstrips. WebPageTest integrates Lighthouse as one component of its output — so you get Lighthouse scores plus deeper diagnostic data from the same test session. The key distinction is hardware fidelity and data richness: WebPageTest gives you the raw browser session data, not just the audit summary.

Can AuditJet replace WebPageTest?

Not for deep forensic work. WebPageTest is still the best tool for waterfall analysis, filmstrip debugging, video comparison, scripted multi-step flows, and geographic testing. AuditJet is designed for continuous monitoring — hourly Lighthouse scans, regression alerting, revenue impact estimates, and automated fix guidance. The right approach is to use both: AuditJet monitors continuously and catches the 'something regressed' signal; WebPageTest diagnoses exactly what regressed and why.

How do filmstrips help diagnose performance issues?

Filmstrips show a sequence of screenshots taken every 100–500ms during page load, revealing exactly when content becomes visible. This is invaluable because technical metrics alone can be misleading — a page can technically reach Largest Contentful Paint quickly while the user stared at a blank white screen for most of that time. The filmstrip makes the user experience visible frame by frame, showing precisely when meaningful content appeared. It's also the most effective way to compare two versions of a page after an optimisation — you can see the visual improvement directly rather than arguing about whether 180ms of LCP improvement is meaningful.

What is the difference between on-demand testing and continuous monitoring?

On-demand testing means you manually initiate a test when you want to investigate. It's reactive — useful when you know there's a problem or are actively optimising. Continuous monitoring means tests run automatically on a schedule and alert you when results change. It's proactive — it finds problems you didn't know to look for. Teams relying only on on-demand testing typically discover performance regressions through user complaints or SEO traffic drops, often weeks after the regression first occurred. Continuous monitoring closes that gap by surfacing regressions within hours.

Does AuditJet use WebPageTest technology?

No. AuditJet runs Google Lighthouse audits against your pages on a continuous schedule, tracking Lighthouse metrics (LCP, INP, CLS, TTFB, Performance Score) over time and alerting on regressions. WebPageTest is a separate open-source project with its own test agents, waterfall engine, and filmstrip capture infrastructure. The two tools are complementary — each covers a different part of the performance workflow.

Start in minutes

Use WebPageTest to diagnose. Use AuditJet to monitor.

AuditJet watches your Core Web Vitals continuously, alerts you the moment scores regress, and connects every drop to estimated revenue impact — so you always know what to fix first.

Run Free Audit Start Monitoring