Vercel cuts pnpm install time by up to 14% in builds

Vercel published an official changelog entry about an optimization for teams using pnpm as their package manager in the platform's builds. According to the announcement, Pro deploys with restored build cache saw, on average, 14% less time spent installing dependencies after the change went into production. The rollout is automatic, applies to all plans, and requires no extra configuration in the project.

The gain doesn't come from downloading packages faster. It comes from a specific step in the install pipeline that, until now, was redone from scratch on every deploy: the lockfile's supply-chain policy verification.

The hidden bottleneck in installation

Every time pnpm installs dependencies in a CI environment, it checks whether pnpm-lock.yaml complies with the configured supply-chain policies, meaning whether the listed packages don't match known patterns of malicious or compromised packages. This check runs against every entry in the lockfile, so large projects pay a price proportional to the size of their dependency tree.

Vercel's changelog gives a concrete example of this difference. Before the optimization, a lockfile with 461 entries took this long:

✓ Lockfile passes supply-chain policies (461 entries in 2.5s)
Done in 2.8s using pnpm v12.3.4

With the change in production, the same project, with no lockfile changes, started reusing the previous verification instead of redoing it:

✓ Lockfile passes supply-chain policies (verified 58s ago)
Done in 135ms using pnpm v12.3.4

That's 2.8 seconds versus 135 milliseconds for the same pipeline step. The difference doesn't show up on every deploy, because it depends on two specific conditions.

When the gain is real

In short: the best case (installation in milliseconds) only happens when the lockfile hasn't changed between deploys and the previous verification is still available for reuse. Outside that condition, the build still runs the full check, just faster on average (the 14% measured by Vercel in Pro deploys with restored build cache).

This covers a fairly common scenario: pull requests that change application code without touching package.json or the lockfile. It's exactly the kind of deploy that repeats several times a day in any team that uses preview deployments for PR review.

Why this matters for teams using pnpm on Vercel

Front-end developers deal with this kind of friction every week: open a small PR, wait for the preview to go up, repeat the cycle several times until the review closes. Every second shaved off dependency installation is less time between the push and the preview link landing in the reviewer's hands.

For teams that pay by the build minute, the effect also shows up on the bill. A monorepo project with multiple apps and a heavy lockfile, the kind that today spends several seconds just on the supply-chain step, tends to feel the difference more than a small project, simply because it has more entries to verify.

It's worth separating two things the announcement bundles into the same number. The 14% metric is an average for Pro deploys with restored cache, not the ceiling of what can be saved. The millisecond case is the best-case scenario, not the typical one. Projects that change dependencies frequently, or that don't meet the restored-cache condition, will see a smaller gain than the reported 14%.

What the optimization doesn't solve

The change is specific to pnpm running on Vercel's infrastructure, so teams using npm or Yarn in the same project aren't affected by it. It also doesn't change the download time for new packages: if the lockfile has changed, with a dependency added, updated, or removed, the supply-chain verification runs in full again, because the previous cache is no longer valid for that content.

Another point left out is the relationship with remote build-cache tools, like the ones used in monorepos with Turborepo. This optimization only touches pnpm's dependency installation step, not the cache of the application's own build artifacts. The two things remain separate layers of the pipeline, and using one doesn't replace the other.

Is it worth migrating to pnpm because of this?

Teams that already use npm or Yarn and are considering switching just for this specific optimization should weigh the migration cost against the actual expected gain. pnpm's installation advantage over its competitors has existed for years, thanks to its content-addressable store with hard links instead of full copies of each package; this Vercel change reinforces a point that was already strong, it doesn't create a new reason on its own.

For teams already running pnpm on Vercel, there's nothing to configure: the optimization is active by default on all plans, according to the official changelog. The gain shows up on its own in the next batch of deploys, especially in PRs that don't touch the lockfile, which tend to make up most of the preview deployment traffic in a front-end team's day-to-day.