vlt.io reduz em até 70% os metadados do registro npm

O problema: packuments que crescem sem parar

A vlt.io anunciou que seu registro serve metadados de pacotes 70% menores que o npmjs.org. O ganho vem dos packuments - os metadatos completos de um pacote, que reúnem o package.json de cada versão publicada mais informações de nível superior como tags de distribuição e datas de publicação. Eles crescem indefinidamente a cada versão publicada, e em instalações limpas (sem lockfile ou com pacote novo) o gerenciador precisa baixar o packument inteiro. Nessas instalações, os packuments representam cerca de 45% dos bytes no npm e no pnpm, 40% no vlt e 25% no bun; só o fixture do Next.js soma 458 packuments e 73,3 MB, contra 109,7 MB de tarballs. Os maiores (gzipped) são @prisma/client com 6,65 MB, prisma com 5,40 MB, vite com 4,41 MB e playwright com 3,41 MB.

A abordagem da vlt

O registro npm já serve uma forma abreviada do packument, mas ela omite campos relevantes, é servida apenas quando o cliente pede e sua lista de campos está congelada há anos: quando libc passou a ser usada para escolher dependências nativas opcionais, o campo não existia lá; minimumReleaseAge precisa do campo time, também ausente. O próprio cliente npm não usa a versão abreviada por precisar desses campos.

A vlt serve por padrão um "install packument" que mantém os campos necessários à instalação - incluindo time, license e libc - e descarta dos metadados de dist as assinaturas por versão e checksums, preservando apenas integrity. É justamente a remoção de assinaturas, do shasum SHA-1 e do documento de atestação (strings base64/hex que o gzip não comprime) que leva o packument do vite de 391 KB para 104 KB na rede. A verificação dos tarballs continua feita pelo integrity, que é mantido. A empresa afirma poder adicionar novos campos rapidamente se mantenedores exigirem.

Números medidos

A medição (repositório vltpkg/vlt-registry-packument-size, rodada via proxy local, dados de 2026-09-30 e 2026-10-06, com npm 12.1.0, pnpm 12.6.0, bun 1.4.2 e vlt 1.3.0) mostrou reduções de 78,7% a 86,3% nos tamanhos de transferência de packuments entre npmjs.org e vlt.io, dependendo do gerenciador e da configuração. O pnpm, com minimumReleaseAge de 24 horas, fez 47 buscas duplas do npmjs.org (66,05 MB extras) e 91 buscas com janela de 7 dias (91,32 MB); no vlt.io não houve nenhuma busca dupla, porque o packument abreviado da vlt inclui o campo time.

Nos tempos de instalação (mediana de cinco execuções por registro), o vlt.io foi de 20% a 72% mais rápido: por exemplo, a API Express caiu de 11,6s para 4,8s com npm e de 9,8s para 2,8s com o cliente vlt. Com configurações padrão de cada gerenciador, a fatia dos packuments na instalação limpa caiu de 25–45% para 5–15% dos bytes totais.

Otimizações extras para o cliente vlt

Como 58,6% das versões publicadas pelos 1000 pacotes mais baixados são prereleases - instaladas com muito menos frequência -, a vlt adicionou o parâmetro de consulta ?stable, que filtra as versões estáveis. O cliente vlt só o usa quando o range pedido não pode casar com um prerelease e após o registro anunciar suporte. Com isso, as transferências do cliente vlt para o vlt.io caíram 89,5% a 95,8% (os quatro fixtures: de 136,57 MB para 7,49 MB). Para pacotes individuais, o ganho chega a 99,4% no caso do playwright.

Conclusão

A vlt destaca que o benefício vai para quem faz instalações limpas frequentes - desenvolvedores ou agentes em ambientes efêmeros - e para quem paga banda ou egress em registros npm hospedados como JFrog Artifactory ou Cloudsmith, para os quais a mudança reduziria a conta de egress em 70%. Os benchmarks são públicos e podem ser reproduzidos.