Bundle Size: The Quiet Killer of Mobile Web Performance
Bundle size is the total weight of JavaScript and CSS the browser must download and parse before your app becomes interactive. On a fast desktop with broadband, a heavy bundle is barely noticeable. On a mid range Android over 4G, a heavy bundle is the difference between a usable app and one that the user closes. Most mobile web performance work is bundle work.
What you actually need to know
- Mobile web performance is bundle weight more than anything else.
- Under 200 KB compressed JavaScript on initial load is a reasonable target.
- Tree shaking, code splitting, and lighter libraries are the levers.
- Enforce a bundle budget in CI.
- The second visit can be much faster with the right caching.
| Bundle size | Mobile experience |
|---|---|
| Under 100 KB compressed | Excellent everywhere |
| 100 to 200 KB | Good on 4G, fine on 5G and Wi-Fi |
| 200 to 300 KB | Acceptable, noticeable on slow networks |
| 300 to 500 KB | Slow on 4G, problematic on 3G |
| Over 500 KB | Mobile users close the tab |
The core argument
Bundle size is the part of web performance that disappears when you are testing on your own laptop with fiber. The dev machine has the bundle cached, the network is fast, and the CPU barely notices the extra weight. It all feels free. Then the customer on a mid range Android over 4G in a coffee shop loads the same page and the experience is brutal.
The cost of a heavy bundle is concentrated in the first visit and on mobile networks. The bundle has to download, the CPU has to parse it, and the main thread stays blocked until that parse finishes. What the user sees is a blank screen, then a partial render, then finally something they can interact with. On a slow phone the gap between blank and interactive can be five to ten seconds. That is a churn event.
The teams that take bundle size seriously hit performance targets that the same teams cannot hit when they ignore bundle size. The discipline is mostly mechanical: split code at the route boundary, dynamic import the heavy components, make sure tree shaking actually works, and swap out the libraries that were not earning their weight.
The cost of the discipline is small. A few hours per pull request to think about what new code adds to the bundle. A CI check that blocks regressions. A quarterly review of the bundle composition. The return is mobile performance that does not deteriorate over time.
The biggest wins
| Lever | Typical savings | Effort |
|---|---|---|
| Replace Moment.js with date-fns or Day.js | 60 to 200 KB | Hours |
| Replace Lodash with native or per function imports | 60 to 100 KB | Hours |
| Tree shakeable icon imports | 50 to 200 KB | Hours |
| Code splitting by route | Variable, often large | Days |
| Dynamic import of heavy components | Variable, often large | Hours per component |
| Replace heavy charting library | 100 to 400 KB | Days |
| Remove unused dependencies | Variable | Hours |
| Server side render the heavy components | Significant | Days |
How much does this cost
The investment to put bundle discipline in place is roughly a sprint. The ongoing cost is per pull request awareness. Both are small. The return is faster mobile performance that compounds across every user.
Features the bundle discipline must have
- A documented bundle budget.
- CI enforcement of the budget.
- A bundle analyzer report on every pull request.
- A list of approved heavy libraries with justification.
- A quarterly review of the bundle composition.
- A clear policy on tree shakeable imports.
- Source maps for production bundles to support analysis.
- A way to test on slow networks during development.
Expert opinion
The teams that ship fast mobile web in 2026 take bundle size seriously the way teams in 2010 took image weight seriously. The discipline is unglamorous. The return is the difference between mobile users who stay and mobile users who close the tab. The investment per pull request is small. The compounding effect is large.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A client SaaS reported that their mobile conversion was significantly worse than their desktop conversion. The team assumed it was a UX problem. The metrics suggested otherwise. The mobile Largest Contentful Paint was over six seconds. The desktop was under two.
We measured the bundle. The initial JavaScript was 780 KB compressed. The breakdown showed Moment.js, the full Lodash, a charting library used on one page, and an icon library that imported everything.
We replaced Moment with date-fns. We swapped Lodash for per function imports. We dynamic imported the charting library. We migrated the icons to tree shakeable imports.
The bundle dropped to 180 KB compressed. The mobile LCP dropped to 2.4 seconds. The mobile conversion improved by roughly thirty percent over the next quarter. The desktop conversion improved by a smaller amount because it had been less constrained.
For more on the related work, see largest contentful paint the metric that changes conversions and code splitting strategies for Next js applications.
Common mistakes teams make
- Testing only on the dev machine with fiber.
- No bundle budget. The size grows monotonically.
- Importing whole libraries when a function would have sufficed.
- No code splitting by route.
- Heavy components loaded on every page.
- Wrong import style that breaks tree shaking.
- No CI enforcement. The budget is theoretical.
- Treating bundle size as solved once. It needs ongoing attention.
A 30 day plan to put bundle discipline in place
- Week one. Measure the current bundle. Identify the top contributors.
- Week two. Make the easy swaps. Moment to date-fns. Lodash to per function.
- Week three. Add code splitting by route. Dynamic import heavy components.
- Week four. Set the budget. Add CI enforcement.
For more on the related work, read code splitting strategies for Next js applications and lazy loading the patterns that work and the ones that backfire. On the broader performance side, the real numbers behind a fast web app in 2026 is the natural next read.
FAQ
Frequently asked
- What is a reasonable bundle size in 2026?
- How do I measure bundle size?
- What are the biggest contributors to bundle size?
- What about code splitting?
- What is tree shaking?
- How do I keep the bundle small over time?
- What about the second visit?
Author
Why this work lands with me
I am Yashveer Singh. Founder of Yashveer Labs. I take this kind of project because I have done enough of them to know what kills them. The version of me that writes a post like this is the same one who builds the system afterward. There is no handoff to a junior, no agency middleman, no surprise scope. That is the bet I am making on my own brand.