Before recording a page-load trace in the Chrome DevTools Performance panel, which recording conditions do you set, and why is an unthrottled run on a developer laptop with a warm cache a misleading baseline?

## The trace describes the machine you recorded it on Every performance recording is a measurement of one specific combination: this build, this hardware, this network, this cache state, this browser profile. Change any of those and the numbers change, sometimes by an order of magnitude. The reason to configure the recording carefully is not ritual — it is that the default configuration (your fast laptop, a warm cache, a development build, your everyday browser with a dozen extensions) is the configuration *least* like the users complaining. ## CPU throttling The single largest gap between a developer's machine and a real user's is single-core CPU speed. Script parsing, compilation and execution scale almost directly with it, so a 200 ms startup on a laptop can be well over a second on a mid-range phone. The Performance panel's CPU throttling dropdown applies a multiplier that slows the main thread down artificially — a 4x slowdown is the common proxy for a mid-range device and 20x for a low-end one. Two caveats worth saying out loud in an interview. First, the multiplier is uniform: it slows everything, whereas a real phone also has different cache sizes, thermal throttling and memory pressure, so the *shape* of the trace can still differ. Second, throttling makes CPU-bound problems visible, which is exactly why unthrottled traces of script-heavy pages look deceptively fine. ## Network throttling and cache state Network throttling constrains bandwidth and adds latency so requests take a realistic amount of time. Without it, everything served from localhost arrives essentially instantly and the trace cannot show you a loading problem at all. Chrome ships presets for slower connections; their labels have been renamed across versions, so pick the one that matches the audience you care about rather than memorizing a name. Cache state matters just as much. A reload with a warm cache skips downloads, skips some parsing work, and produces a page that is genuinely faster than a first visit — so a warm-cache trace silently answers a different question. Disabling the cache while DevTools is open gives you the first-visit picture. Both are legitimate questions; the mistake is not knowing which one you asked. ## A clean browser profile Extensions inject content scripts into pages, add listeners, and run their own work on your main thread. In a trace, that work is often indistinguishable at a glance from the page's own. Recording in a fresh profile, a guest window, or with extensions disabled removes an entire class of phantom costs — and a surprising number of "our page has a mysterious 300 ms of scripting" investigations end here. ## Recording the right span For a load investigation, use the panel's reload-and-record control rather than starting a recording on an already-open page: it begins capturing, then navigates, so HTML parsing, script evaluation and the first paints are all inside the trace. If you are investigating an interaction instead, do the opposite — get the page to the pre-interaction state, start recording, perform the single interaction, and stop. Keep recordings short. Long ones are harder to read, the profiler's own overhead accumulates, and you end up scrolling past minutes of nothing. ## Also profile the right build Throttling a development build does not save it. Dev builds carry unminified modules, development-only warnings and a hot-reload client, and those costs can easily outweigh whatever you are investigating. Point the profiler at a production build served the way production serves it. ## What throttling is not Simulated throttling remains a simulation. It approximates a slow device and a slow link well enough to expose problems and to compare a before against an after, and it is repeatable in a way a real device never is. It does not reproduce a specific phone's behaviour, and it should not be presented as though it did. The honest framing is: throttled recordings tell you *whether the problem exists and whether your fix helped*; they do not tell you the exact number a given user will see.