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.
Written by Yashveer Singh, founder of Yashveer Labs.
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. The CPU is fast. The bundle weight 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. The main thread is blocked until the parse finishes. The user sees 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. Code splitting at the route boundary. Dynamic imports for heavy components. Tree shaking that actually works. Lighter libraries where the big ones 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.
Frequently asked
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.
Posts that line up with this one.
- Performance Optimization
Code Splitting Strategies for Next.js Applications
Next.js code splits by route automatically. The team still has to handle component level splitting, dynamic imports, and the boundary between client and server components. Here is the playbook.
- Performance Optimization
The Caching Hierarchy: Browser, CDN, Edge, Application, Database
Every web application has five caching layers. Understanding which one to use for which data is how fast applications stay fast at scale.
- Performance Optimization
The Cost of Over-Caching: Stale Data Stories
Caching solves performance problems. Over-caching creates correctness problems. Here is the taxonomy of stale data bugs and how to prevent them.
- Performance Optimization
Image Optimization at Scale: AVIF, WebP, Responsive Images
Images are the largest contributor to page weight on most web products. Here is the format selection, responsive image, and delivery strategy that cuts load time without manual work.