It was never the bundle
A week spent making a page faster, and where the time actually went.
I spent a week on a page that everyone agreed was slow, with a shared assumption that the JavaScript was to blame. The JavaScript was not to blame. It is worth writing down what was, because the ordering surprised me.
What actually cost time
Roughly in order of severity:
- A font that blocked first paint for 800ms. Self-hosted, no
font-display, and it was serving four weights of which the page used one. - Three round trips before any content byte. A redirect, then a redirect to add a trailing slash, then the document.
- An image sized for a display nobody had. 2400px wide, rendered at 380, and it was above the fold so it competed with everything.
- The bundle. Real, measurable, and roughly a quarter of the total — which is to say the thing everyone was arguing about was the fourth-largest problem.
Why the ordering is predictable
The first three are all latency and the fourth is throughput, and latency has not improved at anything like the rate bandwidth has. A 4G connection today moves far more bytes per second than a 2010 connection but the round trip costs about the same, so anything serialised is disproportionately expensive and stays that way.
Bundle size is the thing that is easy to measure, easy to graph, and easy to assign to a team. That is why it absorbs the attention. The waterfall is harder to look at and is where the answer usually is.
The unsatisfying conclusion
We shipped the font fix and the redirect fix in an afternoon and got most of the win. The bundle work took three weeks, landed later, and nobody could see it in the numbers by then.