Dicionários Compartilhados: compressão que acompanha a web agentiva

Páginas da web cresceram 6-9% mais pesadas a cada ano na última década, impulsionadas pelo fato de a web estar se tornando mais orientada a frameworks, interativa e rica em mídia. Nada sobre essa trajetória está mudando. O que está mudando é com que frequência essas páginas são reconstruídas e quantos clientes as solicitam. Ambos estão disparando por causa dos agentes.

Dicionários compartilhados reduzem as transferências de ativos de servidores para navegadores, fazendo com que as páginas carreguem mais rápido com menos sobrecarga na rede, especialmente para usuários que retornam ou visitantes em uma conexão lenta. Em vez de baixar novamente pacotes inteiros de JavaScript após cada implantação, o navegador informa ao servidor o que já tem em cache, e o servidor envia apenas as diferenças dos arquivos.

Hoje, estamos empolgados em dar a você uma prévia do nosso suporte para dicionários de compressão compartilhados, mostrar o que vimos em testes iniciais e revelar quando você poderá experimentar a versão beta por conta própria (dica: é 30 de abril de 2026!).

Crawlers, navegadores e outras ferramentas agentes atingem endpoints repetidamente, buscando páginas completas, muitas vezes para extrair um fragmento de informação. Atores agentes representaram pouco menos de 10% do total de solicitações na rede da Cloudflare durante março de 2026, um aumento de ~60% ano a ano.

Cada página enviada é mais pesada do que no ano passado e lida mais frequentemente por máquinas do que nunca. Mas os agentes não estão apenas consumindo a web, eles estão ajudando a construí-la. O desenvolvimento assistido por IA significa que as equipes enviam mais rápido. Aumentar a frequência de implantações, experimentos e iterações é ótimo para a velocidade do produto, mas terrível para o cache.

À medida que os agentes enviam uma correção de uma linha, o empacotador reagrupa, os nomes dos arquivos mudam e cada usuário na Terra pode baixar novamente toda a aplicação. Não porque o código seja significativamente diferente, mas porque o navegador/cliente não tem como saber especificamente o que mudou. Ele vê uma nova URL e começa do zero. A compressão tradicional ajuda com o tamanho de cada download, mas não pode ajudar com a redundância. Não sabe que o cliente já tem 95% do arquivo em cache. Portanto, a cada implantação, em todos os usuários, em todos os bots, envia bytes redundantes repetidamente. Envie dez pequenas mudanças por dia e você efetivamente optou por não usar cache. Isso desperdiça largura de banda e CPU em uma web onde o hardware está rapidamente se tornando o gargalo.

Para escalar com mais solicitações atingindo páginas mais pesadas que são reimplantadas com mais frequência, a compressão precisa ficar mais inteligente.

Um dicionário de compressão é uma referência compartilhada entre servidor e cliente que funciona como uma folha de dicas. Em vez de comprimir uma resposta do zero, o servidor diz "você já conhece esta parte do arquivo porque a armazenou em cache antes" e envia apenas o que é novo. O cliente mantém a mesma referência e a usa para reconstruir a resposta completa durante a descompressão. Quanto mais o dicionário puder referenciar conteúdo no arquivo, menor será a saída comprimida que é transferida para o cliente.

Esse princípio de comprimir contra o que já é conhecido é como os algoritmos de compressão modernos superam seus predecessores. Brotli vem com um dicionário embutido de padrões comuns da web, como atributos HTML e frases comuns; Zstandard é projetado especificamente para dicionários personalizados: você pode alimentá-lo com amostras de conteúdo representativas e ele gera um dicionário otimizado para o tipo de conteúdo que você serve. Gzip não possui nenhum dos dois; ele deve construir dicionários encontrando padrões em tempo real enquanto está comprimindo. Esses algoritmos de "compressão tradicional" já estão disponíveis na Cloudflare hoje.

Dicionários compartilhados levam esse princípio um passo adiante: a versão previamente armazenada em cache do recurso se torna o dicionário. Lembre-se do problema de implantação em que uma equipe envia uma correção de uma linha e cada usuário baixa novamente o pacote completo? Com dicionários compartilhados, o navegador já tem a versão antiga em cache. O servidor comprime contra ela, enviando apenas a diferença. Aquele pacote de 500KB com uma mudança de uma linha se torna apenas alguns kilobytes na rede. Com 100K usuários diários e 10 implantações por dia, essa é a diferença entre 500GB de transferência e algumas centenas de megabytes.

A compressão delta é o que transforma a versão que o navegador já possui no dicionário. O protocolo observa quando o servidor serve pela primeira vez um recurso, anexa um cabeçalho de resposta Use-As-Dictionary, informando ao navegador para essencialmente manter o arquivo porque será útil mais tarde. Na próxima solicitação por esse recurso, o navegador envia um cabeçalho Available-Dictionary de volta, informando ao servidor: "aqui está o que eu tenho." O servidor então prossegue para comprimir a nova versão contra a antiga e envia apenas a diferença. Nenhum arquivo de dicionário separado é necessário.

É aqui que o retorno se concretiza para aplicações reais. Pacotes JS versionados, arquivos CSS, atualizações de frameworks e qualquer coisa que mude incrementalmente entre lançamentos. O navegador já tem app.bundle.v1.js em cache e o desenvolvedor faz uma atualização e implanta app.bundle.v2.js. A compressão delta envia apenas a diferença entre essas versões. Cada versão subsequente também é apenas uma diferença. A versão três se comprime contra a versão dois. A versão 47 se comprime contra a versão 46. As economias não se reiniciam, elas persistem ao longo de toda a história de lançamentos.

Há também discussões ativas na comunidade sobre dicionários personalizados e dinâmicos para conteúdo não estático. Isso é trabalho futuro, mas as implicações são significativas. Vamos deixar isso para outro post.

Se os dicionários compartilhados são tão poderosos, por que todos não os usam já?

Porque da última vez que foram testados, a implementação não conseguiu sobreviver ao contato com a web aberta.

O Google enviou a Compressão de Dicionário Compartilhado para HTTP (SDCH) no Chrome em 2008. Funcionou bem com alguns primeiros adotantes relatando melhorias de dois dígitos nos tempos de carregamento das páginas. Mas o SDCH acumulou problemas mais rápido do que qualquer um conseguiu consertá-los.

O mais memorável foi uma classe de ataques de canal lateral de compressão (CRIME, BREACH). Pesquisadores mostraram que se um atacante pudesse injetar conteúdo ao lado de algo sensível que é comprimido (como um cookie de sessão, token, etc.), o tamanho da saída comprimida poderia vazar informações sobre o segredo. O atacante poderia adivinhar um byte por vez, observar se o tamanho do ativo diminuía e repetir até extrair todo o segredo.

Mas a segurança não foi o único problema, ou mesmo a principal razão pela qual a adoção não aconteceu. O SDCH revelou alguns problemas arquitetônicos, como violar a Política de Mesma Origem (que