JavaScript Bundle Size Budget Strategy
Define and enforce JavaScript bundle size budgets. Learn splitting strategies, tree-shaking, and how to track JS size against performance budgets across code-split chunks and third-party scripts.
Detailed Explanation
JavaScript Bundle Size Budgets
JavaScript is typically the most expensive asset on a web page. Beyond download cost, JS has parse, compile, and execution costs that directly impact Time to Interactive (TTI) and Total Blocking Time (TBT).
Recommended JS Budget Ranges
| Site Type | JS Budget |
|---|---|
| Blog/Content | 50-80 KB |
| Landing Page | 60-100 KB |
| E-commerce | 150-300 KB |
| SPA | 200-400 KB |
| Dashboard | 300-500 KB |
These are transfer sizes (compressed). Uncompressed sizes are typically 3-4x larger.
Breaking Down the JS Budget
A JS budget should be split across categories:
- Framework/runtime — React (~40 KB gzipped), Vue (~30 KB), Svelte (~2 KB)
- First-party code — Your application logic
- Third-party scripts — Analytics, ads, chat widgets, A/B testing
- Polyfills — Only serve to browsers that need them
Tracking Strategy
When adding resources to the Performance Budget Tracker:
- Add each code-split chunk as a separate entry (e.g.,
vendor.js,app.js,page-home.js) - Include third-party scripts with their actual transfer sizes
- Account for inline scripts in HTML
Reducing Bundle Size
- Tree shaking — Remove unused code with modern bundlers (webpack, Rollup, esbuild)
- Code splitting — Load JS only when needed using dynamic imports
- Compression — Use Brotli (30% smaller than gzip) in production
- Bundle analysis — Use tools like webpack-bundle-analyzer to identify bloat
- Import cost awareness — Check package sizes before adding dependencies
The Third-Party Problem
Third-party scripts are the leading cause of JS budget violations. A single analytics script can add 50-100 KB. Track each third-party script as a separate resource entry and regularly audit whether each script justifies its cost.
Use Case
JavaScript budget tracking is critical for teams working on SPAs and complex web applications. A common scenario: the initial build ships within budget, but over months of feature development, the bundle grows 2-3x without anyone noticing. Continuous tracking with the Performance Budget Tracker catches this drift early.