ZSTD vs Brotli vs GZIP: escolhendo a compressão para APIs

O que é compressão de API (e quando vale a pena)

A compressão de resposta de API significa que seu servidor codifica o corpo da resposta (frequentemente JSON) em um fluxo de bytes menor antes de enviá-lo pela rede. O cliente (navegador, app móvel, SDK ou outro serviço) então descomprime. Sobre HTTP, isso é negociado via cabeçalhos como Accept-Encoding (o que o cliente suporta) e Content-Encoding (o que o servidor escolheu).

O que isso faz para APIs

A compressão traz basicamente três benefícios:

• Menos banda: respostas menores consomem menos bytes fim a fim.
• Menor latência em links limitados: menos bytes costuma significar downloads mais rápidos em mobile, Wi‑Fi congestionado e chamadas entre regiões.
• Menor custo de egress: se você paga por dados de saída, reduzir o tamanho transfere-se diretamente para menos custos.

A troca é direta: compressão economiza banda, mas custa CPU (compressão/descompressão) e às vezes memória (buffers). Se vale a pena depende de onde está seu gargalo.

Quando a compressão mais ajuda

Compressão costuma brilhar quando as respostas são:

• Ricas em texto e repetitivas, como JSON, respostas GraphQL, HTML ou logs.
• Médias a grandes, onde reduzir dezenas ou centenas de kilobytes importa.
• Servidas sobre redes lentas ou caras, como mobile, clientes internacionais ou tráfego entre regiões.

Se você retorna grandes listas JSON (catálogos, resultados de busca, análises), compressão é frequentemente um dos ganhos mais fáceis.

Quando ela ajuda pouco

Compressão é geralmente um mau uso de CPU quando respostas são:

• Minúsculas (por exemplo, algumas centenas de bytes). Cabeçalhos + overhead de CPU podem superar a economia.
• Já comprimidas (JPEG/PNG, MP4, ZIP, muitos PDFs). Recompressar geralmente traz pouca redução e pode até aumentar o tamanho.
• Serviços limitados por CPU (endpoints quentes já lutando com computação). Adicionar compressão pode aumentar a latência da cauda.

Eixos de decisão que usaremos ao longo deste guia

Ao escolher entre ZSTD vs Brotli vs GZIP para compressão de API, a decisão prática costuma se resumir a:

1. Redução de tamanho (taxa de compressão)
2. Latência (tempo do servidor até o primeiro byte mais a decodificação no cliente)
3. Suporte do cliente (o que seus chamadores e intermediários lidam de forma confiável)

Todo o resto neste artigo é sobre equilibrar esses três para sua API e padrões de tráfego.

ZSTD vs Brotli vs GZIP: Comparação rápida

Todos os três reduzem o tamanho do payload, mas otimizam para diferentes restrições—velocidade, taxa de compressão e compatibilidade.

Resumo de uma visão

• ZSTD (Zstandard): Muitas vezes o melhor equilíbrio para APIs quando você se importa com baixa latência e CPU previsível. Boa taxa sem ser lento.
• Brotli: Costuma ganhar em menos bytes na rede, especialmente para respostas ricas em texto (JSON, conteúdo tipo HTML). Configurações altas podem custar mais CPU.
• GZIP: A opção “funciona em todo lugar”. Amplamente suportado e fácil de operacionalizar, mas tipicamente mais lento e/ou maior que alternativas modernas com orçamento de CPU comparável.

Forças típicas (e o que isso significa para APIs)

Velocidade do ZSTD: Ótimo quando sua API é sensível à latência de cauda ou seus servidores são limitados por CPU. Ele pode comprimir rápido o suficiente para que o overhead seja muitas vezes negligenciável frente ao tempo de rede—especialmente para respostas JSON médias a grandes.

Taxa do Brotli: Ganha quando a banda é o principal recurso (clientes mobile, egress caro, entrega via CDN) e as respostas são principalmente texto. Payloads menores podem valer a pena mesmo se a compressão demorar mais.

Compatibilidade do GZIP: Melhor quando você precisa do máximo suporte do cliente com mínimo risco de negociação (SDKs antigos, clientes embarcados, proxies legados). É uma base segura mesmo que não seja a preferida em desempenho.

O que “nível de compressão” realmente muda

Níveis de compressão são presets que trocam tempo de CPU por saída menor:

• Níveis baixos: compressão mais rápida, payloads maiores. Bom para APIs em tempo real.
• Níveis altos: payloads menores, compressão mais lenta (e às vezes mais memória). Melhor para respostas grandes e cacheáveis.

A descompressão costuma ser muito mais barata que compressão para os três, mas níveis muito altos ainda podem aumentar CPU/bateria do cliente—importante para mobile.

Regra prática simples

• Escolha padrão: use ZSTD para a maioria das APIs JSON/REST/GraphQL onde latência importa.
• Mude para Brotli: quando você estiver otimizando para mínimos bytes (respostas ricas em texto, entrega via CDN, redes lentas) e puder arcar com CPU extra.
• Fique com GZIP: quando precisar de ampla compatibilidade ou sua infraestrutura/ferramentas não suportarem encodings mais novos.

Taxa de compressão vs Latência: O trade-off central

Compressão é frequentemente vendida como “respostas menores = APIs mais rápidas.” Isso é frequentemente verdade em redes lentas ou caras—mas não é automático. Se a compressão adicionar tempo suficiente de CPU no servidor, você pode acabar com requisições mais lentas apesar de menos bytes na rede.

Onde o tempo é gasto

Ajuda separar dois custos:

• Tempo de compressão (lado servidor): trabalho feito antes do servidor começar a enviar bytes. Isso pode adicionar diretamente ao tempo da resposta (TTFB).
• Tempo de descompressão (lado cliente): trabalho feito após receber os bytes. Normalmente mais barato que compressão, mas pode importar em dispositivos fracos.

Uma alta taxa de compressão pode reduzir o tempo de transferência, mas se a compressão adicionar (digamos) 15–30 ms de CPU por resposta, você pode perder mais tempo do que ganha—especialmente em conexões rápidas.

A armadilha da latência de cauda sob carga

Sob carga, compressão pode prejudicar p95/p99 mais que p50. Quando o uso de CPU sobe, requisições enfileiram. Enfileiramento amplifica pequenos custos por requisição em grandes atrasos—a latência média pode ficar bem, mas os usuários mais lentos sofrem.

Meça como um recurso de performance

Não adivinhe. Rode um teste A/B ou rollout gradual e compare:

• p50 e p95 de latência (idealmente também p99)
• Utilização de CPU e saturação nas instâncias da API
• Tamanhos de resposta e tempo até o primeiro byte

Teste com padrões de tráfego e payloads realistas. O “melhor” nível de compressão é o que reduz o tempo total, não apenas bytes.

Custos de CPU e memória no Servidor e Cliente

Compressão não é “de graça”—ela desloca trabalho da rede para CPU e memória em ambas as pontas. Em APIs, isso aparece como maior tempo de tratamento de requisições, picos de memória e às vezes lentidão no cliente.

Onde a CPU é gasta

A maior parte da CPU é gasta comprimindo respostas. Compressão encontra padrões, constrói estado/dicionários e escreve a saída codificada.

A descompressão é tipicamente mais barata, mas ainda relevante:

• Servidores podem descomprimir requisições (raro para JSON, mais comum para uploads ou lotes).
• Clientes descomprimem respostas no caminho crítico antes de parsear JSON.

Se sua API já é limitada por CPU (servidores de aplicação ocupados, autenticação pesada, queries caras), ligar compressão em nível alto pode aumentar a latência de cauda mesmo que os payloads encolham.

Considerações de memória

Compressão pode aumentar o uso de memória de várias formas:

• Buffers: implementações podem precisar de buffers de entrada/saída; payloads maiores significam buffers maiores.
• Buffering completo vs streaming: compressão em streaming pode começar a enviar mais cedo e manter a memória mais estável, enquanto buffering completo pode inflar pico de memória por requisição.

Em ambientes conteinerizados, picos maiores de memória podem resultar em mais OOM kills ou limites mais apertados que reduzem a densidade.

Impacto em autoscaling e limites de contêiner

Compressão adiciona ciclos de CPU por resposta, reduzindo o throughput por instância. Isso pode disparar autoscaling mais cedo, elevando custos. Um padrão comum: banda cai, mas gasto de CPU sobe—então a escolha certa depende de qual recurso é escasso para você.

Por que a velocidade de descompressão importa para clientes

Em mobile ou dispositivos de baixa potência, descompressão compete com renderização, execução de JavaScript e bateria. Um formato que economiza alguns KB mas demora mais para descomprimir pode parecer mais lento, particularmente quando “tempo até dados utilizáveis” importa.

ZSTD para APIs: forças, limites e padrões sensatos

Zstandard (ZSTD) é um formato moderno projetado para entregar boa taxa de compressão sem desacelerar sua API. Para muitas APIs ricas em JSON, é um forte “padrão”: respostas significativamente menores que GZIP com latência similar ou menor, além de descompressão muito rápida nos clientes.

Onde ZSTD é melhor

ZSTD é mais valioso quando você se importa com o tempo ponta a ponta, não apenas bytes mínimos. Ele tende a comprimir rápido e descomprimir extremamente rápido—útil para APIs onde cada milissegundo de CPU compete com o tratamento da requisição.

Também se sai bem em uma ampla gama de tamanhos de payload: JSON pequeno a médio frequentemente vê ganhos, enquanto respostas grandes podem se beneficiar ainda mais.

Níveis de compressão sensatos para APIs

Para a maioria das APIs, comece com níveis baixos (comumente 1–3). Eles frequentemente oferecem a melhor troca latência/tamanho.

Use níveis mais altos somente quando:

• Payloads são grandes (centenas de KB a MB)
• Banda é cara ou limitada
• Você mediu que CPU não é o gargalo

Uma abordagem pragmática é um padrão global baixo e aumentar seletivamente o nível para alguns endpoints de “resposta grande”.

Streaming e modo dicionário

ZSTD suporta streaming, o que pode reduzir pico de memória e começar a enviar dados mais cedo para respostas grandes.

O modo dicionário pode ser um grande ganho para APIs que retornam muitos objetos similares (chaves repetidas, esquemas estáveis). É mais efetivo quando:

• Payloads são relativamente pequenos, mas frequentes
• Você pode gerenciar dicionários versionados com segurança

Limites de compatibilidade a observar

Suporte no servidor é direto em muitas stacks, mas compatibilidade do cliente pode decidir. Alguns clientes HTTP, proxies e gateways ainda não anunciam ou aceitam Content-Encoding: zstd por padrão.

Se você atende consumidores terceiros, mantenha um fallback (geralmente GZIP) e habilite ZSTD apenas quando Accept-Encoding claramente o incluir.