Charts · 21

What a byte of JavaScript costs

The same number of bytes as a JPEG and as a bundle arrive over the same wire in the same time, and only one of them then stops the page. An image is decoded off the main thread and painted. JavaScript has to be parsed, compiled and run, on the thread that also handles your tap, before anything it renders can appear. Pick a size, press measure, and the page builds that bundle and times every stage on your own machine.

500 KB of JavaScript
31 ms
143 KB of JPEG
54 ms

download (Fast Wi-Fi: 20 ms round trip then 100 Mbps, on an assumed 3.5× gzip) · parse and compile · first execution. Press measure for real numbers. The JPEG lane is the same bytes on the wire, so the download is identical: the whole difference is the main-thread work, because an image is decoded off-thread and never executed.

Notes

The bundle is generated in the page: thousands of small functions with varied identifiers and literals so it gzips roughly like real code (real production bundles compress 3 to 4×; the measured ratio is shown). Transfer size comes from CompressionStream("gzip"). Parse and compile is timed around new Function(source), which parses the whole text and compiles the top level while inner functions are pre-parsed and compiled lazily, as V8 does for a script; the first execution then compiles each function as it is called, which is why the execute stage is not small. Download is computed, not measured: one round trip plus the gzipped bytes at the chosen bandwidth, the same model as the URL chart, and the JPEG lane is given the identical transfer size so the download term cancels; its decode is estimated at 0.04 ms per KB, which is generous to JavaScript. A caveat in the honest direction: this synthetic bundle only defines and calls small functions, while a real bundle of the same size bootstraps a framework and hydrates a tree, so its execute stage is larger than the one measured here. Each measurement generates a fresh source text, because an identical string would hit the engine’s compilation cache and report a parse time of nearly zero. The device factors are the usual working numbers for JavaScript on a mid-range and a low-end Android against a laptop; the real gap for your users is in your analytics. Sources: Osmani, The Cost of JavaScript (2018, updated); V8 blog, Blazingly fast parsing; Chrome DevTools performance documentation.