If RUM tells you that a segment is slow, a synthetic tool like WebPageTest tells you why — frame by frame, request by request. You pick the device, network, and location, run the page in that controlled lab, and get back two views that make the load impossible to misunderstand: the filmstrip and the waterfall.
The tool
What WebPageTest gives you
You enter a URL, choose a configuration (e.g. Moto G on 4G in Mumbai), and it runs the page several times — averaging the runs so one flaky result doesn't fool you. It surfaces a performance summary (is the page quick, stable, resilient?), the metrics you know (TTFB, Start Render, LCP, TBT), total page weight, and the two views below.
Pick the config from reality
The whole point of lab testing is control — but control over the wrong environment is misleading. Use RUM to learn your real audience's device + network, then reproduce that here.
View 1
The filmstrip
The filmstrip is a frame-by-frame screenshot of the load. It makes the invisible obvious: how long the screen stayed blank, the moment of First Contentful Paint, when the LCP element lands — and any layout shift that jumps in late. Scrub through it:
InteractiveScrub the load, frame by frame
2.4s
Largest Contentful Paint (hero)
85% visually complete
The filmstrip turns a load into frames. You can see the blank period, the moment of First Paint, when the LCP lands, and — between 2.4s and 2.8s — a late ad causing a layout shift.
Blank until ~1.6s (FCP), hero lands at 2.4s (LCP), then a late ad shoves the layout at 2.8s. The filmstrip makes each moment visible.
View 2
The network waterfall
The waterfall shows every request on a timeline, each broken into its phases — DNS, connect, SSL, wait (TTFB), download — colour-coded so you can see where time actually went. Markers show Start Render and LCP. Click a request to inspect it:
InteractiveRead the waterfall
Start render
LCP
DNS Connect SSL Wait (TTFB) Download
hero.jpg finishes at 1800 ms. Each bar breaks into DNS → connect → SSL → wait → download. Notice hero.jpg only starts at ~1050 ms — that resource-load delay is exactly what pushes LCP out.
Each row is a request; each colour is a phase. The gap before hero.jpg even starts downloading is the resource-load delay that's holding LCP back.
What to look for
Long wait bands → slow server (TTFB). Repeated DNS/connect/SSL on many rows → too many origins (preconnect them). A late-starting critical image → a discovery/priority problem (preload it). The waterfall turns “it's slow” into a specific, fixable cause.
The killer feature
Experiments & opportunities
WebPageTest's Opportunities tab flags issues like render-blocking CSS, and its Experiments let you test a fix without touching your code. It re-runs your page with the change injected — inline the critical CSS, drop lazy-loading from the LCP image, add caching headers — and shows the before/after. You get a quick win confirmed in the lab before you spend time editing anything.
It also shows Real World Metrics from the Chrome UX Report (CrUX) right next to your lab run — a built-in reminder that lab FCP and field FCP won't match, and that interaction metrics like INP only exist in the field.
Q1Multiple choice
Your first WebPageTest run shows FCP 1.2s; a re-run shows 2.1s. Which do you report, and why does the tool run several times?
Q2Multiple choice
A teammate wants to 'use WebPageTest to track our INP regression.' Why won't that work, and what does the lab tool show instead?
Q3Multiple choice
You suspect inlining critical CSS will fix a slow FCP, but the change is risky to ship. How does WebPageTest let you verify the bet cheaply?
Q4Multiple choice
In the waterfall, a request shows a long grey “wait (TTFB)” band. What does that point to?
Q5Sort each scenario
Which WebPageTest view best answers each question?
How long was the screen blank?
Is DNS/SSL eating time on a third-party origin?
Exactly when did the layout jump on screen?
Why did the hero image download start so late?
Did a request's time go to waiting on the server or downloading bytes?
Key takeaways
→WebPageTest runs your page in a chosen device/network/location, averaged over several runs.