What npm and Yarn Actually Do Over the Network
An npm install or yarn install is not a single download. The package manager first resolves the full dependency tree by fetching metadata from the registry for every package and its transitive dependencies. It then downloads individual compressed tarballs for each package, verifies checksums, extracts them into node_modules, and runs any postinstall lifecycle scripts. A project with 500 direct and transitive dependencies may make hundreds of separate HTTPS requests. Any slow step in that chain — metadata resolution, tarball download, disk write, or script execution — will make the entire install feel slow even on a fast connection.
Find the Slow Phase
| Slow Phase | Likely Cause | Best Fix |
|---|---|---|
| Resolving packages | Lockfile or registry metadata latency | Use a committed lockfile and stable registry |
| Downloading packages | Registry route, VPN, DNS | Test registry and network path |
| Building native modules | CPU, compiler, node-gyp | Install build tools or use compatible Node version |
| Running postinstall | Package lifecycle scripts | Identify the script with --timing flag |
| Writing node_modules | Disk speed or antivirus scanning | Use SSD and exclude project folder from AV |
Fix 1: Check and Change the Registry
Confirm the configured registry before assuming npm itself is slow:
npm config get registry
npm ping
The default registry is https://registry.npmjs.org. If your company uses an internal mirror (such as Verdaccio, Artifactory, or Nexus), and that mirror is slow or unreachable from outside the VPN, every install will be slow. You can switch registries temporarily to test:
npm config set registry https://registry.npmjs.org
For private packages that must come from a company mirror, test both inside and outside the VPN if policy allows to isolate where the slowness originates.
Fix 2: Use the npm Cache Effectively
npm maintains a local content-addressable cache of downloaded tarballs. Find its location with:
npm config get cache
On macOS and Linux it defaults to ~/.npm. On Windows it is typically %AppData%\npm-cache. When you run npm install --prefer-offline, npm serves packages from this cache without hitting the network for anything already stored locally. This can make reinstalls dramatically faster on slow or intermittent connections.
If you suspect the cache is corrupted — manifesting as checksum errors or packages that install differently on every run — verify it first:
npm cache verify
Only clean the cache when verification reports errors or installs are consistently broken. Clearing a healthy cache forces the next install to re-download everything:
npm cache clean --force
yarn cache clean
Fix 3: Lockfiles and Reproducibility
package-lock.json (npm) and yarn.lock (Yarn) are not primarily speed tools, but they prevent dependency re-resolution on every install. Without a committed lockfile, npm must resolve the full dependency tree from scratch each time, making many extra metadata requests. With a lockfile, npm knows exactly which versions to fetch and can skip resolution entirely.
In CI environments, use npm ci instead of npm install. The ci command reads the lockfile exactly, never modifies it, removes existing node_modules before installing, and is faster and more predictable for clean installs.
Fix 4: Consider pnpm for Faster Reinstalls
pnpm is a drop-in alternative to npm and Yarn that stores all packages in a single content-addressable store on disk and uses hard links into each project's node_modules. Because packages are never duplicated on disk, reinstalling the same package across multiple projects is nearly instant — the hard link is created without any network request or file copy. On a machine with many Node.js projects, pnpm can reduce both disk usage and install time substantially compared to npm or classic Yarn.
Fix 5: Parallelism and CI Caching
npm version 7 and later install dependencies in parallel by default, which significantly reduces total install time compared to npm 6's sequential approach. If you are on npm 6, upgrading alone may noticeably improve install speed.
In CI/CD pipelines, the biggest speed improvement usually comes from caching the npm or Yarn cache directory between runs rather than caching node_modules directly. Caching node_modules can cause subtle issues when lockfiles change; caching the content-addressable cache directory is safer and still avoids re-downloading unchanged packages. Most CI platforms (GitHub Actions, GitLab CI, CircleCI) have built-in cache steps for npm and Yarn cache directories.
Fix 6: Test VPN, Proxy, and Antivirus
Package installs create a storm of small HTTPS requests and thousands of file writes. Corporate proxies, SSL inspection, endpoint security tools, and antivirus scanning can slow that pattern far more than a single large download. Test on a clean network path if allowed, and ask IT about approved exclusions for project dependency folders and the npm cache directory. Excluding node_modules and the npm cache from real-time antivirus scanning is a common and safe performance optimization on developer machines.
Frequently Asked Questions
Why is npm install slow even on fast internet?
npm installs download many small packages, verify integrity hashes, run lifecycle scripts, compile native modules, and write thousands of files to disk. The bottleneck is often disk I/O, antivirus scanning, or postinstall scripts rather than raw bandwidth.
Should I clear the npm cache?
Verify the cache first with npm cache verify. Cache cleaning is a later step when installs repeatedly fail or the package manager reports checksum errors. Clearing a healthy cache makes the next install download everything again, which is slower, not faster.
Is npm ci faster than npm install?
Often yes, especially in CI or clean installs. npm ci uses the lockfile exactly, skips dependency resolution, and removes the existing node_modules folder before installing, giving a consistent and predictable result every time.