The Cost Of JavaScript

Addy Osmani
Nov 15, 2017 · 8 min read


When most developers think about the cost of JavaScript, they think about it in terms of the download & execution cost. Sending more bytes of JavaScript over the wire takes longer the slower a user’s connection is.

Best practices for reducing how much JavaScript you’re shipping down to users.


Once downloaded, one of JavaScript’s heaviest costs is the time for a JS engine to parse/compile this code. In Chrome DevTools, parse and compile are part of the yellow “Scripting” time in the Performance panel.

Chrome DevTools Performance panel > Bottom-Up. With V8’s Runtime Call Stats enabled, we can see time spent in phases like Parse and Compile
JavaScript and image bytes have very different costs. Images usually don’t block the main thread or prevent interfaces from getting interactive while being decoded and rasterized. JS however can delay interactivity due to parse, compile and execution costs.
Parse times for a 1MB bundle of JavaScript (~250KB gzipped) across desktop & mobile devices of differing classes. When looking at the cost of parse, it’s the decompressed figures to consider e.g ~250KB gzipped JS decompresses to ~1MB of code.
Parse times comparing the performance of Apple’s A11 Bionic chip to the Snapdragon 617 in more average Android hardware.

Execution time

It’s not just parse and compile that can have a cost. JavaScript execution (running code once parsed/compiled) is one of the operations that has to happen on the main thread. Long execution times can also push out how soon a user can interact with your site.

Patterns for reducing JavaScript delivery cost

When you’re trying to keep parse/compile & network transmit times for JavaScript slow, there are patterns that can help like route-based chunking or PRPL.

Other costs

JavaScript can impact page performance in other ways:

  • During runtime, long-running JavaScript can block the main-thread causing pages that are unresponsive. Chunking up work into smaller pieces (using requestAnimationFrame() or requestIdleCallback() for scheduling) can minimize responsiveness issues.
Progressive Bootstrapping visual by Paul Lewis


Transmission size is critical for low end networks. Parse time is important for CPU bound devices. Keeping these low matters.

It’s useful to consider how much JS “headroom” the architectural decisions we make can leave us for app logic.

Learn More

My Chrome Dev Summit 2017 talk covers the cost of JavaScript. Later on performance case studies are walked through for production sites like Pinterest and Tinder.

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Addy Osmani

Written by

Eng. Manager at Google working on Chrome • Passionate about making the web fast.

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.