Vercel reduz tempo de instalação do pnpm em até 14% nos builds

A Vercel publicou no changelog oficial uma otimização para quem usa pnpm como gerenciador de pacotes nos builds da plataforma. Segundo o anúncio, deploys Pro com cache de build restaurado tiveram, em média, 14% menos tempo gasto instalando dependências depois que a mudança entrou em produção. A aplicação é automática, vale para todos os planos e não exige nenhuma configuração extra no projeto.

O ganho não vem de baixar pacotes mais rápido. Vem de um passo específico do pipeline de instalação que, até então, era refeito do zero a cada deploy: a verificação de políticas de supply chain do lockfile.

O gargalo escondido na instalação

Toda vez que o pnpm instala dependências num ambiente de CI, ele confere se o pnpm-lock.yaml respeita as políticas de supply chain configuradas, ou seja, se os pacotes listados não batem com padrões conhecidos de pacotes maliciosos ou comprometidos. Essa checagem roda em cima de cada entrada do lockfile, então projetos grandes pagam um preço proporcional ao tamanho da árvore de dependências.

O changelog da Vercel traz um exemplo concreto dessa diferença. Antes da otimização, um lockfile com 461 entradas levava assim:

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

Com a mudança em produção, o mesmo projeto, sem alteração no lockfile, passou a reaproveitar a verificação anterior em vez de refazê-la:

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

São 2,8 segundos contra 135 milissegundos no mesmo passo do pipeline. A diferença não aparece em todo deploy, porque depende de duas condições específicas.

Quando o ganho é real

Em resumo: o melhor caso (instalação em milissegundos) só acontece quando o lockfile não mudou entre um deploy e outro e a verificação anterior ainda está disponível para reaproveitamento. Fora dessa condição, o build ainda roda a checagem completa, só que mais rápido em média (os 14% medidos pela Vercel em deploys Pro com build cache restaurado).

Isso cobre um cenário bastante comum: pull requests que mexem em código de aplicação sem tocar em package.json ou no lockfile. É exatamente o tipo de deploy que se repete várias vezes por dia em qualquer time que usa preview deployments para revisão de PR.

Por que isso importa para quem usa pnpm na Vercel

Quem desenvolve front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → lida com esse tipo de fricção toda semana: abrir um PR pequeno, esperar o preview subir, repetir o ciclo várias vezes até o review fechar. Cada segundo a menos na instalação de dependências é tempo a menos entre o push e o link do preview na mão do revisor.

Em times que pagam por minuto de build, o efeito também aparece na fatura. Um projeto monorepo com várias apps e lockfile pesado, do tipo que hoje gasta alguns segundos só na etapa de supply chain, tende a sentir mais a diferença do que um projeto pequeno, simplesmente porque tem mais entradas para verificar.

Vale separar duas coisas que o anúncio junta no mesmo número. A métrica de 14% é uma média para deploys Pro com cache restaurado, não o teto do que dá para economizar. O caso de milissegundos é o melhor cenário, não o típico. Projetos que trocam dependências com frequência, ou que não batem a condição de cache restaurado, vão ver ganho menor do que os 14% relatados.

O que a otimização não resolve

A mudança é específica do pnpm rodando na infraestrutura da Vercel, então quem usa npm ou Yarn no mesmo projeto não é afetado por ela. Também não altera o tempo de download de pacotes novos: se o lockfile mudou, com dependência adicionada, atualizada ou removida, a verificação de supply chain roda de novo por inteiro, porque o cache anterior não é mais válido para aquele conteúdo.

Outro ponto que fica de fora é a relação com ferramentas de cache remoto de build, como as usadas em monorepos com Turborepo. Essa otimização mexe só na etapa de instalação de dependências do pnpm, não no cache de artefatos de build da aplicação em si. As duas coisas continuam sendo camadas separadas do pipeline, e usar uma não substitui a outra.

Vale a pena migrar para pnpm por causa disso?

Times que já usam npm ou Yarn e cogitam trocar só por essa otimização específica deveriam pesar o custo de migração contra o ganho real esperado. A vantagem de instalação do pnpm sobre os concorrentes já existe há anos, graças ao armazenamento em content-addressable store com hard links em vez de cópias completas de cada pacote; essa mudança da Vercel reforça um ponto que já era forte, não cria um motivo novo sozinho.

Para quem já roda pnpm na Vercel, não há nada para configurar: a otimização está ativa por padrão em todos os planos, segundo o changelog oficial. O ganho aparece sozinho na próxima leva de deploys, principalmente nos PRs que não tocam no lockfile, que costumam ser a maioria do tráfego de preview deployments no dia a dia de um time de front-end.

Fonte: Vercel Changelog