JavaScript Costs Four Times, Not Once
A 400KB bundle is not one cost. It is downloaded, parsed, compiled and executed — and gzip only helps with the first of those. The last three are CPU on a device you did not choose and cannot upgrade.
Frame the diagnosis
Performance work starts from a symptom and a signal — never from a resource dashboard.
Four costs hiding behind one number
Bundle size is quoted as a single number, usually compressed, usually in a CI comment. That number describes exactly one of the four things the browser must do with your JavaScript, and it is generally the cheapest one on a modern connection.
Compression shrinks bytes on the wire. It does not shrink the parse work, because the engine parses the *decompressed* source. It does not shrink compilation, and it certainly does not shrink execution — if anything, the decompression itself adds a small amount of CPU. A team that celebrates a 40% gzip improvement has improved one quarter of the problem and left the expensive quarters untouched.
The execution cost is the one that matters most and is quoted least, because it is invisible in every network-shaped view of performance. It is also the one that scales with the *device*, which is why the gap between a developer's experience and a user's experience is so much wider here than anywhere else in the stack.
| Cost | Scales with | Reduced by | Not reduced by |
|---|---|---|---|
| Download | Connection speed, bytes on the wire | Compression, CDN, fewer/smaller files | Anything about code structure |
| Parse | Uncompressed source size, device CPU | Shipping less code | Compression — the engine parses decompressed source |
| Compile | Amount of code actually run, device CPU | Shipping less code, lazy loading | Compression, CDN |
| Execute | What the code does, device CPU | Doing less work at startup, deferring, moving off main thread | Compression, CDN, faster network |
The device gap
Network conditions vary by maybe an order of magnitude between a good and a bad connection. Device CPU varies by a similar factor between a current flagship and the mid-range phone a large share of users actually own — and unlike the network, it does not improve when the user walks into a coffee shop.
This produces the single most common false-negative in frontend performance: the feature is tested on the machine it was written on, where 600ms of script execution takes 90ms, and nobody notices. The bundle ships, the field data shifts, and the connection to the change is lost because the CI budget only tracked bytes.
The practical response is to make the slow device the default test target rather than an afterthought. A throttled profile in CI that approximates a mid-range phone turns an invisible regression into a failing build, which is the only reliable mechanism for something this easy to miss.
| Signal | Value | What it tells you | Verdict |
|---|---|---|---|
| Transferred (gzipped) | 128KB — both devices | The number quoted in the PR. Identical either way | normal |
| Download — laptop, fibre | 90ms | Fast link, cost is negligible | normal |
| Download — mid-range phone, 4G | 410ms | Network cost is real but not dominant | suspect |
| Parse + compile — laptop | 55ms | Invisible during development | normal |
| Parse + compile — phone | 240ms | Untouched by compression or CDN | smoking gun |
| Execute (startup) — laptop | 90ms | Feels instant to the developer who shipped it | normal |
| Execute (startup) — phone | 610ms | The dominant cost, and the one no byte budget measures | smoking gun |
Splitting the bundle moves work; it does not delete it
Code splitting is the standard prescription and it is a good one, provided everybody is clear that it *relocates* cost rather than removing it. The route bundle gets smaller and the first paint arrives earlier; the deferred chunk still has to be downloaded, parsed, compiled and executed at some point, and that point is now during a user interaction rather than during a load the user already expected to wait through.
That trade is usually worth it, because the deferred work is often never needed at all — the user never opens the settings panel, never reaches the checkout step. But when the deferred chunk is on a common path, splitting can turn a slow load into a fast load followed by a laggy first tap, which shows up as an INP regression while every load metric improves.
The only reliable way to distinguish these outcomes is to measure both classes of metric before and after. This is the general "fixing one bottleneck exposes the next" pattern from The Bottleneck Moves After Every Fix, appearing here as a trade between load metrics and interaction metrics.
1// Every route, every modal, every chart library — one bundle2import { Dashboard } from './dashboard'3import { Settings } from './settings'4import { ChartKit } from 'chart-kit' // 180KB, used on one route5import { PdfExport } from './pdf-export' // 90KB, used by ~2% of sessions6 7// Cost on a mid-range phone, every single visit:8// download 410ms + parse/compile 240ms + execute 610ms9// ...before the first screen renders anything.1// First screen only2import { Dashboard } from './dashboard'3 4// Deferred until the route or interaction actually happens5const Settings = lazy(() => import('./settings'))6const ChartKit = lazy(() => import('chart-kit'))7const PdfExport = lazy(() => import('./pdf-export'))8 9// First visit gets a much smaller four-way cost.10// BUT: the chart chunk now loads on interaction —11// measure INP, not just LCP, or you have traded one metric for another.The good column is usually right, and it is not free: work moved to interaction time is work the user now waits for while actively engaged, which is a harsher context than an expected page load.
Key points
- JavaScript costs download, parse, compile and execute; compression and CDNs address only the first.
- Parse, compile and execute are device CPU, so the gap between a developer laptop and a mid-range phone is large and invisible locally.
- A byte budget in CI does not catch execution regressions — a main-thread time budget on a throttled profile does.
- Code splitting relocates cost from load time to interaction time; that is usually a good trade and it must be measured as a trade.
- The cheapest bundle byte is the one never shipped: deleting an unused dependency beats every optimisation applied to keeping it.
Follow the diagnosis
The causal chain, hop by hop — and the readings that invite the wrong conclusion.
- 1Build → bundle: a charting library and a PDF exporter are imported at module scope, so they land in the entry chunk regardless of route.
- 2Network → device: 128KB compressed arrives in 410ms on 4G — the only cost the CI byte budget measured.
- 3Engine → main thread: 400KB of *decompressed* source is parsed and compiled, costing 240ms of CPU that compression did nothing to reduce.
- 4Startup code → main thread: module initialisation executes for 610ms, during which the page cannot paint or respond to input.
- 5User → page: taps during that window are queued behind the long task, so INP records the wait even though the bytes arrived long ago.
- • "We gzipped it, so bundle cost is handled." Compression addresses download only; the engine parses the decompressed source.
- • "It executes in 90ms." On the machine that built it. Measure on the device class your users actually hold.
- • "Bundle size is under budget, so we are fine." A byte budget is blind to execution time, which is usually the dominant cost.
- • "Code splitting made it faster." It made the load faster. Check whether interaction got slower before claiming a win.
- • "Tree shaking removed the unused code." It removes what it can statically prove is unused; side-effectful modules and dynamic access routinely defeat it. Verify with coverage.
Measure, fix, validate
An optimization is not finished until the metric that motivated it has moved.
- • Uncompressed source size per bundle, not just the gzipped transfer number, because parse cost tracks the former.
- • Main-thread time attributed to script parse, compile and execute during startup, on a throttled mid-range device profile.
- • Total blocking time and long-task count during load, as the proxy for how unresponsive the page is while script runs.
- • Per-chunk coverage: how much of the shipped code executes during a typical session, to find code paid for and never used.
- • Field INP alongside field LCP, so a splitting change that trades one for the other is visible.
- • Delete dependencies the first screen does not need — the only change that reduces all four costs at once.
- • Split by route and by interaction so the entry chunk contains what the first screen genuinely requires, and measure INP alongside LCP.
- • Move heavy startup computation off the critical path: defer it, chunk it with yields, or run it in a worker (see [[rendering-and-layout]]).
- • Replace oversized dependencies with smaller ones where the API surface used is small — often a single utility justifying 80KB.
- • Audit coverage per route and remove code that never executes in a real session.
- • Main-thread script time on the throttled profile, before and after, for the same route and the same cold-cache conditions.
- • Field LCP *and* field INP p75 for the affected route and device segment, over a stable window — a split that improves one and degrades the other is a trade, not a win.
- • Coverage data confirming the removed code is genuinely not being pulled in through another path.
- • Total blocking time during load, which should fall if execution work actually left the critical path rather than being renamed.
- • Splitting adds request count and build complexity, and can produce waterfalls of chunk fetches if the graph is deep.
- • Deferred work lands during interactions, where users are less tolerant of delay than during an expected page load.
- • Replacing a mature dependency with a smaller one trades bytes for the risk and maintenance cost of a less-proven library.
- • A throttled CI profile makes builds slower and needs pinning and maintenance to stay comparable over time.
- • A CI budget on main-thread script time on a pinned throttled profile, not only on transferred bytes.
- • A build check that fails when a new dependency lands in the entry chunk without an explicit exemption.
- • Per-route bundle composition reporting in the PR, so a 180KB library appearing in the entry chunk is visible at review time.
- • A field alert on INP p75 to catch work relocated into interaction time.
Accuracy
Performance numbers are conditional. These are the conditions.
- WEB-SPECIFICParse, compile and execute behaviour are JavaScript engine concerns; details differ between V8, SpiderMonkey and JavaScriptCore and change between versions.
- ILLUSTRATIVEThe laptop-versus-phone numbers are invented to show the characteristic ratio. Actual costs depend on engine version, device generation, thermal state and what the code does.
- RUNTIME-SPECIFICEngines apply lazy compilation and caching heuristics that change which costs are paid when. Measure on the target engine rather than reasoning from a general model.
Misconceptions
Apply it
Where the depth lives
Which dependency pulled 180KB into the entry chunk is a build-graph question; the performance domain only tells you that it cost 240ms of parse time on a phone.