JavaScript execution cost

The on-device CPU time needed to parse, compile, and run JavaScript, which can hurt even after a small compressed bundle downloads.

javascript makes the phone slowthe bundle downloads fast but still freezesthe phone gets hot while the page loadswhy does javascript take so long to startjava script exection costeverything downloaded but the spinner keeps spinningthe app is slow on cheap phonesfine on my macbook, unusable on my mum's phone

See it

Live demo coming soon

What it is

JavaScript execution cost is the device time spent parsing, compiling, and running shipped code. Download size predicts some of it, but code shape and device speed matter too. A compressed bundle can cross the network quickly, expand into much more source, and then occupy the main thread while the interface waits. This is the point Addy Osmani's 'The Cost of JavaScript' hammered on: byte for byte, script is the most expensive thing a page can download, because an image only has to be decoded while a script has to be parsed, compiled, and run.

Reach for it when a page paints but taps lag, startup stalls after the network goes quiet, or desktop looks fine while a low-end phone struggles. Chrome DevTools Performance exposes long tasks and its Bottom-Up view shows which functions consume CPU. Profile with CPU throttling or representative hardware, not only a development laptop.

Gotcha: moving code is not removing cost. A delayed script can still freeze the first interaction, and splitting one long task into queued work can monopolize the thread. Delete work first, yield between remaining chunks, and move pure computation to a Web Worker, which cannot directly read or update the DOM.

Ask AI for it

Reduce this page's JavaScript execution cost. Record startup and the slowest interaction in Chrome DevTools Performance with 4x CPU throttling, then use Bottom-Up to rank script evaluation and functions by self time. Delete unnecessary work, lazy-load optional features with import(), break tasks over 50ms with scheduler.yield(), and move pure CPU-heavy computation into a Web Worker. Keep DOM work on the main thread, repeat the identical trace, and report before and after total script time, longest task, Total Blocking Time, and INP.

You might have meant

bundle sizelong taskmain thread blockingtotal blocking timethird party script tax

Go deeper