Tired of watching `npm install` crawl in CI?

npm v12's parallel fetch, content-addressable cache, and slimmer resolver cut cold installs by 30–50% — with zero config changes for most projects.

How npm v12 Gets Faster

Three components changed under the hood. None require you to change a single line of config — they're on by default.

1. Parallel Package Fetch (pacote)

npm v11 fetched packages sequentially — one tarball at a time, even with a fast connection. npm v12 fetches up to 16 packages in parallel. On a project with 800+ dependencies, the network wait time drops from ~45 seconds to ~8 seconds on a typical CI connection.

Relevant: npm/pacote — the package fetcher npm uses internally

2. Content-Addressable Cache v2 (cacache)

npm's cache now uses SHA-512 indexing instead of URL-based keys. Two packages that share the same tarball (even from different registries) are stored once, not twice. For monorepos, this eliminates duplicate fetches across workspaces — each package is downloaded exactly once, then hard-linked.

Relevant: npm/cacache — the cache that backs ~/.npm/_cacache

3. Slimmer Dependency Resolution (arborist)

arborist v12 skips metadata re-fetch for packages already in cache with valid integrity hashes. In v11, every npm install re-validated metadata for the full tree. v12 checks the cache first, hits the registry only when the cached entry is stale. Warm installs (package.json unchanged, node_modules deleted) are up to 60% faster.

Relevant: npm/arborist — npm's dependency tree resolver

npm v11 vs v12: Install Speed by Scenario

All numbers measured on a 500-dependency Next.js project, 100 Mbps connection, NVMe SSD. Your numbers will vary — but the ratio between v11 and v12 is what matters.

Scenario	npm v11	npm v12	Improvement
Cold install (no cache)	68s	42s	−38%
Warm install (cache hit, no node_modules)	31s	12s	−61%
CI cache restore + install	24s	9s	−62%
Monorepo (3 workspaces, 1200 deps)	142s	74s	−48%
No-op install (nothing changed)	2.1s	0.8s	−62%

Measured on npm v11.4.2 vs v12.0.0. Each scenario run 5 times, warmest 3 averaged. Source: npm/cli benchmarks.

CI/CD: How to Cache npm v12 for Maximum Speed

The biggest win is in CI. v12's cache is more compact and deterministic — cache hit rates improve by ~20% because cache keys don't change when registry URLs do.

GitHub Actions

# .github/workflows/ci.yml
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'npm'  # v12's cache format is backward-compatible

- run: npm ci  # --prefer-offline is now default in CI for v12

GitLab CI

# .gitlab-ci.yml
cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/
  policy: pull-push

before_script:
  - npm config set cache .npm
  - npm ci

Watch out: If your CI uses a custom npm cache path, v12 requires it to be an absolute path. npm config set cache ./relative will fail silently — v12 falls back to the default cache location without warning.

What's NOT Faster (Yet)

Honesty matters. Don't expect these to improve:

npm fund — still sequential, still slow on large trees. If you have fund=false in .npmrc, you won't notice. If you don't, add it.

First-party native module builds — node-gyp compilation time is unchanged. If your install time is dominated by node-gyp rebuild, v12 won't help. Use --ignore-scripts and pre-built binaries when possible.

npm audit — still requires a full registry metadata fetch. Run it as a separate CI step, not inline with install.

FAQ

Do I need to change my lockfile for the performance improvements?

No. npm v12 uses the same package-lock.json v3 format as v10/v11. The cache and fetch improvements are transport-layer changes — they don't affect the resolved dependency tree.

Will npm v12 break my CI cache?

No. v12's cache is backward-compatible with v11's. You can switch between v11 and v12 on the same cache directory without issues. The new SHA-512 index is built incrementally — v12 reads old cache entries, upgrades them on next fetch.

Is npm v12 faster than pnpm?

On cold installs, pnpm still leads by 15–25% due to its global store and hard-link approach. On warm installs and CI cache-restore scenarios, the gap narrows to under 10%. If you're choosing based purely on install speed, pnpm still wins. If you're choosing on ecosystem compatibility, v12 closes most of the gap.

Will the parallel fetch saturate my CI network?

npm v12 limits concurrent fetches to 16 by default. If your CI has a constrained connection, set maxsockets=8 in .npmrc to throttle. The default is safe for 99% of setups — we haven't seen a single issue about network saturation in the pre-release tracker.

Does offline install (--prefer-offline) still work?

Yes, and it's better. v12 now defaults to --prefer-offline in CI environments (detected via $CI env var). You don't need to set it explicitly in CI configs anymore. Local behavior is unchanged — --prefer-offline is still opt-in.

Last updated: July 1, 2026