JavaScript Bundle Size Estimator

Gzip size is how large your JavaScript files are after compression during transfer. Modern servers and CDNs compress files automatically — Brotli and gzip can reduce bundle sizes by 60-80%. The gzip size is what affects download time; the uncompressed size affects parse and execution time. Both matter: large uncompressed bundles cause slow JavaScript parsing even on fast connections. Aim for under 200KB gzipped for the initial JS bundle.

Tree-shaking is dead code elimination — bundlers remove exports that aren't imported. It works only with ES module syntax (import/export), not CommonJS (require). Packages that support tree-shaking: date-fns, lodash-es, @radix-ui/react-*, @tanstack/* libraries. Packages that don't: lodash (CJS), moment (very limited). Check if a package has a 'module' field in package.json pointing to .mjs files, which indicates ES module support for tree-shaking.

For Vite projects: install rollup-plugin-visualizer and add it to vite.config.ts — it generates an interactive treemap. For webpack: use webpack-bundle-analyzer (npx webpack-bundle-analyzer stats.json). For Next.js: add @next/bundle-analyzer to next.config.js. For a quick online check: use bundlejs.com or bundlephobia.com to see exact gzipped size of any npm package. Use import cost VS Code extension to see sizes inline while coding.

Most common: (1) Importing entire lodash (import _ from 'lodash') instead of individual functions. (2) Using moment.js — 72KB gzipped; replace with dayjs (2.4KB) or date-fns (tree-shakeable). (3) Loading all of D3 when only using a few modules. (4) Not splitting routes — all pages load at startup. (5) Including polyfills for modern browsers that don't need them. (6) Development dependencies in production bundles.

Code splitting defers non-critical JavaScript until it's needed, reducing initial bundle size. In React: use React.lazy() + Suspense for route-level or component-level splitting. In Next.js: dynamic() from next/dynamic. In Vite: import('./module') creates automatic split points. Split by route (most impactful), by feature (load on demand), or by user interaction (load after first interaction). Target under 50KB per route chunk for optimal performance.

Mobile users face a triple penalty: (1) slower download on cellular networks, (2) slower JavaScript parsing — mid-range Android parses JS ~3-4x slower than desktop, (3) slower execution due to CPU throttling. A 500KB gzipped bundle takes ~2.4s to parse on a mid-range phone. The rule of thumb: keep total JS under 200KB gzipped on mobile, under 500KB for desktop-first apps. Use Chrome DevTools' device throttling to simulate real mobile performance.