writing

The real cost of slow — what shipping more JavaScript actually does

Slow pages lose users and revenue. A tour of the public numbers — bounce, conversion, and engagement — and where JavaScript bundle size fits in.

Performance is not a vanity metric. Every public study of the last decade points the same direction: when pages get slower, people leave, and when they leave, you lose money. The lever you control most directly as an engineer is how much JavaScript you ship — and that is exactly what bundle size measures.

The numbers everyone cites

  • Google's research found that as page load time goes from 1s to 3s, the probability of a bounce increases 32%; from 1s to 5s, 90%. (think with Google)
  • Deloitte's Milliseconds Make Millions report found a 0.1s improvement in mobile site speed lifted retail conversions 8.4% and consumer-spend per visit 9.2%.
  • Amazon and others have long reported that every 100ms of latency measurably reduces sales.

You do not need to relitigate these studies. The direction is settled. The open question for most teams is where their own slowness comes from — and on a modern SPA, the single biggest controllable input is the size of the JavaScript bundle the browser must download, parse, and execute before the page is interactive.

Why JavaScript is the expensive byte

A kilobyte of JavaScript is not the same as a kilobyte of an image. The image decodes off the main thread; the script must be parsed and executed on it. On a median mobile device, parse-and-execute time dominates. Shipping less JavaScript is the most reliable way to make a page feel fast.

That is why bundle size is worth tracking as a first-class metric — not once, in a Lighthouse run before launch, but on every commit, so a regression is caught the day it lands instead of the day a customer complains.

What to do about it

  1. Measure what you ship today. Drop your build's stats into the free bundle analyzer — no signup — and see the treemap.
  2. Track it over time so you can see what changed since which commit. That is what dendrobundle does; see the quick start.
  3. Set a budget and enforce it in CI so the number can only go down.

Speed is a feature. Bundle size is the part of it you can put a number on.