Como a Vercel cortou 91% da latência de metadata no edge (e o que isso muda pra você)

Toda requisição que chega à Vercel atravessa a CDN da empresa, que executa, em média, mais de 80 milhões de instruções de roteamento por segundo. Parte desse trabalho é olhar a metadata de rotas: descobrir quais caminhos existem e como servi-los. Quando essa metadata não está em cache, a CDN precisa buscá-la antes de responder, e é exatamente esse passo que o time de engenharia da Vercel atacou no changelog publicado em 10 de setembro de 2026. O resultado: P99 do lookup de metadata caindo de 215,8 ms para 19,1 ms, uma redução de 91%.

Para quem constrói em Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) → e faz deploy na Vercel, esse ganho é invisível no código, mas real na ponta. E para quem opera edge próprio (Cloudflare Workers, um CDN caseiro, cache de rota em qualquer camada), o como é replicável.

Onde nasce a latência: cache miss por caminho

O problema não é obscuro. O path de uma requisição nem sempre bate com o path do conteúdo que a serve. /blog/hello-world pode resolver para a rota dinâmica /blog/[slug]; o payload do React Server Component daquela página pode resolver para /blog/[slug].rsc. A CDN aplica as regras de roteamento (declaradas pelo framework via Build Output API) e, no processo, precisa checar vários paths-alvo até achar a resposta certa.

Antes de fazer o lookup exato, filtros de Bloom no roteamento global descartam paths que definitivamente não existem. O que sobra precisa de uma consulta exata à metadata. E aqui estava o gargalo: a Vercel armazenava a metadata como um objeto separado por path, buscado e cacheado individualmente.

Isso funcionava bem para projetos pequenos que deployavam pouco. O problema aparece na escala oposta: deployments grandes podem ter centenas de milhares de paths, cada um com sua entrada de cache. Como todo deploy novo gera um conjunto fresco de chaves de cache, a primeira consulta a cada path sempre dava cache miss. Sites grandes que fazem deploy com frequência pagavam esse custo repetidamente.

A ideia: buscar em grupo, parsear só o necessário

A solução foi agrupar a metadata de muitos paths em arquivos chamados shards. Buscar um shard traz para o cache a metadata de todos os paths dele de uma vez. Um cache fill por path esquenta um path; um shard fill esquenta todos os paths atribuídos àquele shard.

O detalhe que evita trocar um problema por outro: cada shard carrega um índice interno que permite à CDN localizar a metadata de um path específico sem decodificar, descomprimir ou parsear as outras entradas. Cada busca aquece muitos paths, mas cada lookup ainda processa só o registro que precisa.

A estrutura reusa camadas que a Vercel já tinha para outros datasets de roteamento. Os shards são construídos em JSONL (um valor JSON por linha), com registros chave-valor ordenados e alternados, herdados dos Bulk Redirects, e estruturas Base64 endereçáveis diretamente, vindas dos filtros de Bloom. O time separou de propósito o layout dos dados das estruturas de lookup que ficam por cima, para que cada workload escolha o que precisa:

• registros JSONL chave-valor ordenados, inspecionáveis e com acesso aleatório;
• índices inline opcionais para busca binária de baixo overhead;
• dados Base64 embutidos com decodificação por offset;
• shards limitados que controlam custo de transferência e de cache.

Os ponteiros do índice são armazenados como números de largura fixa, cada um sendo um múltiplo exato de caracteres Base64 de seis bits. Assim, um ponteiro pode ser decodificado no lugar sem primeiro parsear a linha do índice como JSON nem decodificar todo o Base64. O roteamento faz busca binária nos paths codificados usando offsets de byte calculados em build, achando o path em O(log n) leituras de ponteiro e comparações de string. Só então parseia o valor JSON da linha seguinte. O resto do shard fica intacto.

Por que 200 KB e não um shard gigante

A parte mais instrutiva do post é o experimento de tamanho. A intuição inicial do time era que a metadata da maioria dos deployments caberia num único shard, então começaram com shards de vários megabytes, apostando que o índice e a busca binária manteriam o parsing barato.

O que quebrou a aposta foi a topologia de cache. Cada processo de roteamento mantém um pequeno cache LRU de shards recentes em memória, na frente de um cache regional maior compartilhado por todos os processos da região. Nos testes, o hit rate regional era alto, mas o do LRU era baixo: as requisições se espalhavam por muitos processos em cada região, então cada processo raramente reencontrava o mesmo shard. Transferir shards de vários MB também saiu mais caro que o esperado.

Shards grandes tornavam os LRU misses lentos demais, enquanto shards minúsculos tornavam os regional misses comuns demais.

O equilíbrio prático, achado em produção, ficou em cerca de 200 KB: alto hit rate regional e LRU miss barato de preencher. Os números medidos em tráfego de produção entre 5 e 12 de agosto de 2026:

Vale notar o que ficou de fora: o time avaliou encolher ainda mais os shards com front-coding dos paths ordenados, documentos JSONL que deduplicam metadata e um formato de serialização customizado mais compacto. Todos geravam shards bem menores, mas as simulações previam ganho de latência apenas modesto. A conclusão foi honesta: o trabalho extra de encoding, compatibilidade e rollout não valia a pena para esta migração. Otimização engavetada até outro workload justificar o custo.

Como trocar o roteamento sem servir 404

Esse lookup roda em toda requisição para todo deployment. Se a metadata sharded discordasse da versão por-path, o resultado seria rota obsoleta, status code errado ou 404 em path que existe. O processo de validação é um bom roteiro para qualquer mudança em caminho crítico.

Primeiro, offline: o time montou deployments de teste e rodou um harness que consultava cada path pelos dois caminhos e comparava as respostas. Depois, em produção, atrás de feature flag, o roteamento fazia as duas consultas numa amostra aleatória de requisições, mas continuava servindo o resultado antigo. A comparação rodava em background, por várias semanas, sem atrasar produção. É o padrão que a Vercel chama de shadow mode.

O shadow mode encontrou divergências, e elas eram raríssimas. Uma era um bug no encoding antigo, que empacotava paths em encoded words RFC 2047 para caber texto não-ASCII em campos ASCII, e só aparecia quando um emoji era partido entre duas words. O formato novo guarda paths como UTF-8 puro, então o bug não pode acontecer. Achar esse caso de borda aumentou a confiança na comparação, e os shards passaram a servir tráfego real.

O bônus: build mais rápido

Com os shards em produção, o time voltou ao pipeline de build e removeu o trabalho que virou redundante:

• pular o upload de metadata por path economiza ~9,7 s;
• escrever a metadata de grupo de rotas direto no manifesto economiza ~4,5 s;
• não subir os arquivos que ficaram vazios economiza ~2,4 s.

São cerca de 16,6 s por deploy. No agregado, o passo de deploy ficou ~10% mais rápido; em deployments pesados em metadata, onde essas etapas dominam, a estimativa chega perto de 25%.

O que isso muda pra você

Se você deploya Next.js na Vercel, o contrato da Build Output API não mudou: o framework continua descrevendo o que a aplicação precisa, a Vercel melhorou como a CDN serve. Deployments feitos após 17 de julho de 2026 já usam os shards novos. Para um deployment mais antigo, um redeploy é o suficiente para pegar os lookups rápidos. Nos próprios sites de marketing e docs da Vercel, o P99 do lookup caiu de 203 ms para 31 ms, e o P99 de resolução de rota em sites grandes ficou cerca de duas vezes mais rápido.

O valor mais durável aqui é o padrão de arquitetura, não a feature. Se você mantém qualquer camada de cache de metadata por chave individual (roteamento em Workers, um proxy próprio, resolução de tenant em SaaS multi-tenant), a lição é a mesma: agrupar a busca sem agrupar o parsing. Um índice interno com ponteiros de largura fixa e busca binária deixa você trazer muitos registros num fetch e ainda parsear só um. E o tamanho do bloco não se deduz no quadro branco: ele depende de como seu cache se distribui entre processos, algo que só a medição em produção revela. A Vercel só chegou nos 200 KB porque o LRU se comportou diferente do previsto.

Fonte: Vercel Changelog