EngineeringScoreWebPageTest
WebPageTest loads a page from a chosen region, device and connection, then puts every request on a waterfall beside a filmstrip of the load.
Why our report names it
Our performance checks count. Total bytes, how many requests, how many came from third parties, how many images are larger than they need to be. A count establishes that a page is heavy and never establishes which request held up the next one, and our own guidance sends you to WebPageTest for that. The waterfall is the whole reason.
What it doesn't do
- Tests queue behind other people's tests. WebPageTest's own quick start guide tells you to allow roughly a minute for each test ahead of yours and warns it is often longer, so this is a tool you sit down with rather than one you wire into a pull-request check.
- Most of the sandbox experiments are gated. The same guide says a few are free to try while the rest are a premium feature of WebPageTest Pro, and the signed-out view of the site is described as a limited one, so plan on an account.
- A waterfall is evidence, not a decision. It will show you a script that held rendering for a second and a half. Whether that script can be deferred, and what stops working when it is, is a judgement about your application that no measurement makes on your behalf.
- It is still a synthetic run from a WebPageTest machine, describing a load that WebPageTest performed rather than the loads your visitors performed. Its own summary shows Chrome User Experience Report figures beside its numbers rather than instead of them, which is the honest arrangement.
What it does
- The conditions are yours to set before anything runs. WebPageTest offers a region, a device type and a connection profile, throttled mobile profiles among them, so the run reflects a visitor you actually have instead of the desk you happen to be sitting at.
- The details page carries a waterfall of every request and connection the page made, and the filmstrip page sits beside it: keyframes of the load, with a waterfall underneath whose marker follows whichever keyframe you are looking at. That pairing is how a blank screen at a given instant gets traced back to the request responsible for it.
- It goes past diagnosis. WebPageTest can apply a candidate optimisation inside its own sandbox, run an untouched control alongside it and show you both, so "would compressing this really help" turns into a measurement rather than an argument in a pull request.
More on the problem
Nothing here is gated behind us. Go straight to WebPageTest and make your own mind up.
Sources
Every claim about WebPageTest on this page was read on from the pages below. Products change and this page does not change with them, so treat the date as the claim's expiry rather than its publication.
- The WebPageTest home page, rendered through Chromium because it refuses a plain request: the region, device and connection options offered before a test, the description of the signed-out view as a limited one, and the in-depth metrics covering components including DNS, TCP and TLS
- The WebPageTest quick start guide in its own documentation repository, cited there because the published docs site currently returns not-found: the queueing warning, what the details and filmstrip pages contain, how a sandbox experiment runs against a control, and that a few experiments are free to try while the rest are a WebPageTest Pro feature
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.