Npm Package Size Calculator
Check the install size and download time impact of adding an npm package to your project. Enter values for instant results with step-by-step formulas.
Formula
Bundle Impact = Gzipped Size / Current Bundle x 100%
Where Gzipped Size is the package size after minification and gzip compression (the actual bytes transferred over the network), and Current Bundle is your existing JavaScript bundle size. Download time is calculated as Gzipped Size divided by connection speed. Total install size includes the package plus all its dependencies.
Worked Examples
Example 1: Adding date-fns to a React Project
Problem: Evaluate adding date-fns (package: 50 KB, minified: 20 KB, gzipped: 7 KB, 0 deps) to a project with a 200 KB current bundle.
Solution: Download on 4G: 7 KB / (12000/8 KBps) = 4.67ms\nBundle increase: 7 / 200 = 3.5%\nNew bundle: 200 + 7 = 207 KB gzipped\nBudget impact: 207 / 170 = 121.8% of recommended budget\nMobile parse time: ~20ms (20 KB minified)\nCDN cost at 100K users/month: $0.05
Result: Bundle: 207 KB (+3.5%) | Download: ~5ms on 4G | Parse: ~20ms mobile | Minimal impact
Example 2: Evaluating a Heavy Analytics Package
Problem: Consider adding an analytics library: 300 KB package, 120 KB minified, 45 KB gzipped, 12 dependencies (avg 30 KB each).
Solution: Total install: 300 + (12 x 30) = 660 KB\nDownload on 4G: 45 / 1500 = 30ms\nBundle increase: 45 / 200 = 22.5%\nNew bundle: 200 + 45 = 245 KB gzipped\nBudget: 245 / 170 = 144.1% (over budget)\nMobile parse: ~120ms\nCDN cost at 100K users/month: $0.34\nAnnual CDN cost: $4.10
Result: Bundle: 245 KB (+22.5%) | OVER budget | Consider lighter alternative or lazy loading
Frequently Asked Questions
What is the difference between package size, minified size, and gzipped size?
These three metrics represent different stages of package optimization. Package size (also called install size or unpacked size) is the total file size when the package is installed via npm install, including source files, documentation, tests, and configuration. Minified size is the package source code after removing whitespace, comments, and shortening variable names through a tool like Terser or UglifyJS. Gzipped size is the minified code after applying gzip compression, which is how it is actually transferred over the network via HTTP compression. For example, a package might be 200 KB unpacked, 80 KB minified, and 25 KB gzipped. The gzipped size is the most important metric for web performance because it represents the actual bytes downloaded by users.
How do npm dependencies affect bundle size?
Each npm dependency you add to your project brings its own code and potentially its own dependencies (transitive dependencies), creating a dependency tree that can grow exponentially. A package with 5 direct dependencies might actually install 50 or more packages when transitive dependencies are counted. However, bundle size impact depends on how much of each package actually ends up in your production bundle. Modern bundlers like webpack and Rollup support tree shaking, which eliminates unused exports from packages that use ES module syntax. A 500 KB package where you only import one small function might add only 5 KB to your bundle if it is properly tree-shakeable. Packages using CommonJS modules (require/module.exports) cannot be tree-shaken and contribute their full size.
How do I check the size of an npm package before installing it?
Several tools help you evaluate package size before adding it to your project. Bundlephobia (bundlephobia.com) is the most popular, showing minified and gzipped sizes, download times on various connections, and the package dependency tree. Package Phobia (packagephobia.com) shows the install size (disk space used by npm install). The npm CLI itself provides size information with npm pack --dry-run which shows what files would be included in the package. For checking the impact on your specific bundle, tools like webpack-bundle-analyzer, source-map-explorer, and import-cost (VS Code extension) show real sizes after bundling. The import-cost extension is particularly useful as it shows the size inline next to each import statement in your editor.
What is tree shaking and how does it reduce bundle size?
Tree shaking is a dead code elimination technique used by modern JavaScript bundlers to remove unused exports from your final bundle. The term comes from the idea of shaking a tree so that dead leaves (unused code) fall off. For tree shaking to work, packages must use ES module syntax (import/export) rather than CommonJS (require/module.exports), because ES modules have statically analyzable import declarations. When you write import { debounce } from 'lodash-es', the bundler can determine that only the debounce function is used and exclude all other lodash functions. However, side effects in modules (code that runs at import time) can prevent tree shaking. Packages can declare themselves side-effect-free in their package.json with the sideEffects field.
How does package size affect Core Web Vitals and SEO?
Package size directly impacts several Core Web Vitals metrics that Google uses as ranking signals. Largest Contentful Paint (LCP) can be delayed when large JavaScript bundles block the main thread during parsing and execution, preventing the browser from rendering content. First Input Delay (FID) increases when the browser is busy parsing JavaScript and cannot respond to user interactions. Cumulative Layout Shift (CLS) can be affected when JavaScript-dependent content loads asynchronously and shifts visible elements. Google research shows that sites loading more than 500 KB of JavaScript have significantly higher bounce rates on mobile devices. Each 100 KB of additional JavaScript adds approximately 350ms to Time to Interactive on a median mobile device, directly impacting user experience and search rankings.
What are alternatives to large npm packages that improve performance?
Many popular npm packages have smaller alternatives that provide similar functionality. Instead of moment.js (72 KB gzipped), use date-fns (tree-shakeable, often under 5 KB for common operations) or dayjs (2.9 KB gzipped). Replace lodash (72 KB) with lodash-es (tree-shakeable) or individual lodash method packages like lodash.debounce. Instead of axios (14 KB), consider the native fetch API (0 KB). Replace numeral.js with the native Intl.NumberFormat API. For React state management, zustand (1 KB) replaces Redux (7 KB plus react-redux). Preact (3 KB) can replace React (42 KB) for simpler applications. These micro-libraries and native APIs can reduce your total bundle size by hundreds of kilobytes without sacrificing functionality.