Bundle size
Rough JS bundle sizing: source → minify / gzip / Brotli. For first-load intuition and performance budgets — not a webpack-stats replacement. Results after Calculate.
Results
Enter data and click Calculate.
Why JS bundle size matters
Browsers must download, parse, and execute JavaScript before pages feel interactive. A large initial bundle hurts TTI — especially on mobile (weaker CPUs + networks).
This calculator gives rough sizes from source (minify ~70%, gzip ~21%, Brotli ~18%). It does not replace vite build / Lighthouse.
Raw size vs transferred size
- Source / minified — on-disk artifact (resource size).
- Gzip / Brotli — typical HTTP transfer size.
- Compression helps download; the engine still parses uncompressed JS.
Download cost vs parse/execute cost
Even on fast Wi‑Fi, 300 KB of minified JS can stall the main thread on a low-end phone. “Small gzip transfer” ≠ “cheap at runtime.”
- Framework runtimes have a fixed baseline cost.
- Heavy libraries hurt both KB and parse time.
- Measure with Lighthouse, Performance panel, Web Vitals.
Code splitting and lazy loading
The goal is less initial JS — not necessarily a smaller sum of all chunks. Lazy routes, dynamic import(), and tree-shaking defer cost until use.
This calculator does not model splits — enter the chunk that actually ships on first load.
Intuitive thresholds (gzip initial)
Rule of thumb — tune to your product.
| Gzip (approx.) | Feel | Typical action |
|---|---|---|
| < ~100 KB | comfortable | keep the budget |
| ~100–300 KB | noticeable on 3G/CPU | audit dependencies |
| > ~300 KB | painful first load | split / remove deps |
Result ratios are fixed — trust build stats for production decisions.
Numeric examples (with assumed ratios)
- 50 KB source → ~35 KB min, ~10.5 KB gzip — light chunk.
- 300 KB source → ~210 KB min, ~63 KB gzip — already mobile-sensitive.
- Pre-minified vendor code may compress differently than app source — check the Network panel.
FAQ — JS bundles
How to read minify/gzip estimates vs real build stats.
- Is this exact Vite/webpack output?
- No. Fixed rule-of-thumb ratios. Decide from build stats and Lighthouse.
- Where do 70% / 21% / 18% come from?
- Simplified typical ratios vs JS source. Real gzip depends on redundancy.
- KB or KiB?
- MB = ×1024 KB (common in frontend tooling).
- Cut gzip or cut source first?
- Reduce initial JS first (split, tree-shake, fewer deps). Compression is second.
- Is Brotli always better than gzip?
- Often smaller transfer; CDN support and CPU cost also matter.
- Small gzip but a slow page — why?
- Parse/execute still runs on uncompressed JS. Watch the main thread, not only transfer KB.
- How does this relate to JSON/Base64?
- API payload cost vs app JS cost — audit both when TTI suffers.
- What should I enter with code splitting?
- The chunks loaded on first paint/route — not the whole project sum.