A page takes about four seconds before it is usable. Looking at a browser performance trace of that load, how do you tell whether the main thread was busy or sitting idle waiting on the network, and how does the answer change which fix you reach for?

## Two very different four-second pages "Four seconds to usable" describes at least two unrelated illnesses. In one, the CPU never stops: scripts parse, compile, execute, and the browser recalculates style and lays out repeatedly. In the other, the CPU is idle almost the whole time and the browser is simply waiting for bytes to arrive. Prescribing the wrong medicine is the classic wasted sprint — code-splitting a page that was blocked on a slow API, or adding preconnect hints to a page that was choking on a megabyte of script execution. The trace answers the question directly, and separating the two is the single highest-value read in a profiling session. ## What each track shows - **The main-thread track** is a timeline of tasks. Solid, coloured blocks mean the thread was executing something; gaps mean it had nothing to do. Categories are colour-coded — script evaluation, style and layout, paint — and long tasks (conventionally, anything over 50 ms) are flagged so they are easy to spot. - **The network track** draws one bar per request, positioned by when it started and how long it took. A request bar is internally divided: a leading portion covering queueing, connection setup and waiting for the server's first byte, then the portion where the response body is actually downloading. Reading them together turns "the page is slow" into a mechanism. ## The three shapes you will see **CPU-bound.** The main-thread track is a near-continuous wall of work; the network finished early or is irrelevant to the span. This says the page is doing too much computing at the wrong moment. The remedies are all forms of *less work now*: ship less script to this route, defer non-essential initialization, remove or delay third-party execution, hoist repeated computation out of loops, or move genuinely heavy computation off the main thread. **Network-bound.** The main thread has long empty gaps that line up with one or a few long request bars. The page is not slow because of your code; it is slow because a byte has not arrived. Remedies are about the requests themselves: start the critical ones earlier, reduce how many are required before the page is usable, shrink them, or improve where they are served from. If the bar's *leading* portion dominates — a long stretch before any body bytes — the delay is on the server or in connection setup, and no amount of client optimization touches it. **Chained (the staircase).** Short bursts of main-thread work alternating with idle gaps, where each burst ends by kicking off the next request. This is a dependency chain: HTML is parsed, which discovers a stylesheet, whose parsing discovers a font, which the layout needs, and so on. The total is not one slow thing — it is the *serialization* of several fast things. Measured naively, no single item looks bad, which is why teams miss it. The fix is structural: make the discoveries happen sooner and in parallel rather than one after another, so the chain becomes a wide shallow tree. ## Why the distinction decides the fix Each diagnosis has a completely different lever, and each lever is useless against the other illness: | Trace shape | Bottleneck | Family of fixes | | --- | --- | --- | | Solid main-thread work | CPU on the device | Do less, later, or elsewhere | | Idle thread, long request | Bytes and latency | Fewer, earlier, smaller requests | | Alternating bursts and gaps | Dependency chain | Parallelize discovery; shorten the chain | It also decides *who* you talk to next. A long pre-first-byte segment is a conversation with whoever owns the server or the edge, not a frontend task at all. A wall of scripting is a conversation about what the page is loading and why. ## Traps worth naming - **The answer changes with conditions.** The very same page is often network-bound on a slow connection and CPU-bound on a slow phone. That is not a contradiction; it means you must state which condition you profiled under and, if the audience spans both, profile both. - **Warm cache flips the picture.** A repeat visit with a warm cache can look CPU-bound simply because the network cost has vanished, hiding a first-visit download problem entirely. - **Idle does not always mean network.** Gaps can also be the browser doing work off the main thread, or genuine waiting on something other than a request. Confirm the gap actually lines up with a request bar before calling it network-bound. - **Both can be true.** Plenty of slow pages are network-bound in their first second and CPU-bound in the next. Split the span, diagnose each part separately, and fix the one that dominates first.