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.
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer
Npm Package Size Calculator
Calculator
Adjust values & calculateEnter your values below. Every result is computed in your browser โ no data is sent to any server.
Formula: Bundle Impact = Gzipped Size / Current Bundle x 100%
Worked example โ Bundle: 207 KB (+3.5%) | Download: ~5ms on 4G | Parse: ~20ms mobile | Minimal impact
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 Bundle increase: 7 / 200 = 3.5% New bundle: 200 + 7 = 207 KB gzipped Budget impact: 207 / 170 = 121.8% of recommended budget Mobile parse time: ~20ms (20 KB minified) CDN 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 Download on 4G: 45 / 1500 = 30ms Bundle increase: 45 / 200 = 22.5% New bundle: 200 + 45 = 245 KB gzipped Budget: 245 / 170 = 144.1% (over budget) Mobile parse: ~120ms CDN cost at 100K users/month: $0.34 Annual 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.
What is a good JavaScript performance budget for websites?
Google recommends a total JavaScript budget of approximately 170 KB gzipped (around 700 KB uncompressed) for good performance on mobile devices. This recommendation comes from the time required to download, parse, and execute JavaScript on median mobile hardware. At 170 KB gzipped on a 4G connection, download takes about 0.5 seconds, but parsing and execution on a mid-range phone can take 2-4 seconds. For highly interactive applications, you might allow up to 300 KB gzipped, but each additional KB directly impacts Time to Interactive (TTI). The budget should include all JavaScript: your application code, framework, libraries, and third-party scripts like analytics and ads. Code splitting helps by loading only the JavaScript needed for the current page.
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.
How do CDN costs relate to package bundle size?
CDN bandwidth costs are directly proportional to the total bytes served to users, making bundle size a real financial concern for high-traffic applications. Major CDN providers charge approximately $0.05 to $0.12 per GB of data transfer. For a website with 1 million monthly visitors, adding a 50 KB gzipped package to your bundle increases monthly CDN costs by approximately $3.80 to $5.70. At 10 million monthly visitors, that same package costs $38 to $57 per month, or $456 to $684 per year. While these individual costs seem small, they compound across multiple packages and grow with traffic. This is why companies like Netflix and Airbnb invest heavily in bundle optimization, as their massive traffic volumes make every kilobyte financially significant.
What is the impact of parse and execution time on mobile devices?
JavaScript parse and execution time is the hidden cost of bundle size that disproportionately affects mobile users. While download time gets the most attention, parsing and executing JavaScript can take 2-5 times longer than downloading it on mobile devices. A mid-range Android phone (like a Moto G4) parses JavaScript at roughly 1 MB per second and executes it even slower, while a high-end iPhone might process the same code 3-4 times faster. This means a 200 KB minified package takes approximately 200ms to parse on mobile versus 50ms on desktop. During parsing and execution, the main thread is blocked, making the page unresponsive to user input. This is measured by Total Blocking Time (TBT) in Lighthouse and directly correlates with First Input Delay in real user metrics.
How can I optimize my existing bundle to offset adding a new package?
Before adding a new package, analyze your current bundle with webpack-bundle-analyzer or source-map-explorer to identify optimization opportunities. Common strategies include: implementing code splitting to lazy-load routes and heavy components using dynamic import(), replacing full library imports with targeted imports (import specific functions instead of entire libraries), removing unused dependencies identified through depcheck or npm-check, enabling modern JavaScript output (targeting ES2020+ eliminates polyfills), and configuring your bundler tree-shaking settings properly. Compression improvements like switching from gzip to Brotli can reduce transfer sizes by an additional 15-20%. Often, analyzing an existing bundle reveals 30-50% of unnecessary code that can be eliminated, more than offsetting the cost of adding a needed new package.
References
Background & Theory
History
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer ยท Editorial policy
Related Calculators
๐งฎViewport Size Calculator
Calculate viewport size with inputs, formulas, and instant results.
๐งฎFile Size Converter
Calculate file size converter with inputs, formulas, and instant results.
๐งฎRag Chunk Size Calculator
Calculate optimal chunk sizes for RAG retrieval based on embedding model, overlap, and context.
๐งฎDocker Container Size Calculator
Estimate Docker image and container sizes from base image, layers, and dependencies.
๐งฎOpen Graph Image Size Calculator
Calculate optimal Open Graph and Twitter Card image dimensions for social media sharing.
๐งฎGit Repository Size Calculator
Estimate repository size growth based on commit frequency, file sizes, and branching strategy.
๐งฎDatabase Size Calculator
Estimate database storage needs from table count, rows per table, and average row size.
๐งฎBackup Size Calculator
Calculate backup storage needs based on data volume, retention policy, and change rate.