Which tools measure web performance?

Three different jobs, and you need a tool from each.

Profiling in the browser — why your machine is slow

Chrome DevTools is the main one. The Performance panel records a timeline showing long tasks, layout and paint work, and exactly which function held the main thread. The Memory panel takes heap snapshots for finding leaks, and Coverage shows how much of each bundle actually ran.

Record with CPU throttling set to 4x or 6x — a problem invisible on a laptop is obvious on a mid-range phone.

Lab auditing — a repeatable score

Lighthouse (built into DevTools, or the CLI for CI) runs a standard audit and reports LCP, CLS, TBT and a list of opportunities. WebPageTest does the same from real devices in chosen locations, with a filmstrip and waterfall that make render-blocking resources obvious.

Both are lab data: one synthetic run on one connection. Useful for catching regressions before release, not for knowing what users experience.

Field data — what users actually get

This is the one teams most often skip, and the only one that reflects reality. The Chrome UX Report gives real-user Core Web Vitals for your origin, and Vercel Speed Insights, Sentry or a web-vitals script report your own traffic.

Lab and field regularly disagree. A site can score 95 in Lighthouse while real users on slow phones see a 6-second LCP, because the lab run does not have their device, network or cache state.

Bundle analysis

webpack-bundle-analyzer, rollup-plugin-visualizer or source-map-explorer show what is actually in your JavaScript. Usually the fastest route to a real improvement, because an unexpectedly large dependency is easy to fix once you can see it.

Start with field data to learn whether there is a problem, use lab tools to reproduce it, and profile to find the cause.