Compressão de tráfego API é o conjunto de técnicas que reduz o volume de bytes trafegados entre cliente e servidor, seja compactando payloads, seja evitando enviar o que não muda. As duas famílias resolvem problemas diferentes e se combinam bem.
A pergunta prática não é "qual algoritmo é melhor", e sim "onde está o desperdício". Em APIs REST típicas, boa parte do tráfego é texto repetitivo (chaves JSON, nomes de campos, listas de IDs) e respostas idênticas reenviadas a cada chamada. Atacar isso rende mais que trocar de codec.
1. Gzip como padrão de compatibilidade
Gzip é o baseline. Praticamente todo cliente HTTP moderno negocia Accept-Encoding: gzip, e servidores como Nginx e o API Gateway da AWS suportam a compactação de payloads por configuração. O ganho em JSON costuma ficar na casa de 60% a 80% de redução, dependendo da repetição interna do documento. É a escolha segura quando você não controla quem consome a API.
O custo é CPU. Em picos de tráfego, comprimir cada resposta pode virar gargalo. Meça antes de ligar em tudo.
2. Brotli quando o cliente é navegador
Brotli entrega taxas melhores que gzip em conteúdo textual, especialmente em payloads grandes e com dicionário previsível. O suporte é amplo em navegadores atuais, mas irregular em clientes antigos, bibliotecas de terceiros e dispositivos embarcados. A regra prática: ofereça Brotli via negociação de conteúdo e mantenha gzip como fallback. Nunca sirva Brotli para quem não pediu.
3. zstd para tráfego interno entre serviços
Quando o cliente é outro serviço seu, você controla os dois lados e pode usar zstd, que equilibra bem taxa de compressão e velocidade. É comum em malhas de serviços e pipelines de dados. O ganho sobre gzip em payloads binários ou semi-estruturados costuma justificar a troca. Em APIs públicas, o suporte ainda é limitado.
4. Compressão seletiva por tipo de conteúdo
Nem tudo deve ser comprimido. Imagens em JPEG ou PNG, vídeos e arquivos já compactados não ganham nada com gzip e só gastam CPU. Configure a compressão por Content-Type: comprima application/json, text/*, application/xml e similares; ignore o resto. Essa única regra evita boa parte do desperdício em APIs que também servem arquivos.
5. Reduzir o payload antes de comprimir
Compressão não conserta payload mal desenhado. Se a resposta traz 40 campos e o cliente usa 6, o ganho real vem de um parâmetro de seleção de campos ou de endpoints mais específicos. O mesmo vale para formatos: JSON com chaves longas repetidas comprime bem, mas um formato colunar ou binário pode ser menor já na origem. Ataque o tamanho antes de apertar o botão do gzip.
6. Paginação e limites de resposta
Listas sem paginação são uma fonte silenciosa de tráfego. Um endpoint que devolve "todos os pedidos" cresce com o tempo e vira problema de banda e de latência. Defina limites padrão, cursores e um teto máximo por requisição. Isso reduz o volume de forma previsível e melhora o tempo de resposta no cliente.
7. Cache HTTP com ETag e Cache-Control
Se a resposta não mudou, não precisa trafegar de novo. ETag permite que o cliente pergunte "mudou?" e receba um 304 Not Modified sem corpo. Cache-Control define por quanto tempo o cliente pode reusar a resposta sem nem perguntar. Em APIs com dados que mudam pouco (catálogos, configurações, listas de referência), essa estratégia costuma render mais que qualquer codec.
8. HTTP/2 e HTTP/3 com multiplexação
HTTP/2 reduz overhead de cabeçalhos com HPACK e permite múltiplas requisições na mesma conexão. HTTP/3 troca o transporte para QUIC, o que ajuda em redes móveis instáveis. Nenhum dos dois substitui a compressão de payload, mas os três juntos atacam camadas diferentes do mesmo problema: bytes por resposta, bytes por cabeçalho e bytes por conexão.
9. Monitorar o ganho real, não o teórico
Ligar compressão sem medir é apostar. Acompanhe taxa de compressão por endpoint, uso de CPU no servidor e tempo total de resposta. Em alguns casos, o ganho de banda não compensa o custo de processamento, principalmente em payloads pequenos. Um JSON de 2 KB comprimido para 1,4 KB economiza pouco e adiciona latência.
Qual escolher na prática
Para APIs públicas, comece por gzip com Brotli negociado e compressão seletiva por tipo de conteúdo. Some cache HTTP antes de mexer em algoritmos. Para tráfego interno entre serviços, avalie zstd. E antes de tudo, revise o tamanho do payload na origem: a melhor compressão é a que não precisa acontecer.
FAQ
O que é compressão de tráfego API?
É a redução do volume de bytes trafegados entre cliente e servidor em chamadas de API. Envolve compactar payloads com algoritmos como gzip, Brotli ou zstd e evitar transferir dados desnecessários por meio de cache, paginação e seleção de campos.
Gzip ou Brotli: qual usar?
Use Brotli quando o cliente é navegador moderno e você controla a negociação de conteúdo. Mantenha gzip como fallback para clientes antigos ou desconhecidos. Em APIs internas, zstd pode ser mais vantajoso pelo equilíbrio entre taxa e velocidade.
Comprimir toda resposta da API é boa ideia?
Não. Conteúdo já compactado, como imagens e vídeos, não ganha com gzip e consome CPU. Configure a compressão por tipo de conteúdo e meça o ganho real por endpoint antes de aplicar em toda a API.
Cache HTTP substitui compressão?
Não substitui, complementa. Cache com ETag e Cache-Control evita reenviar respostas idênticas, enquanto a compressão reduz o tamanho das que precisam trafegar. Em APIs com dados estáveis, o cache costuma ter impacto maior.
Como medir o ganho de compressão?
Acompanhe taxa de compressão por endpoint, uso de CPU no servidor e latência total. Compare o volume antes e depois. Payloads pequenos podem não justificar a compressão, e o custo de processamento pode superar a economia de banda.
Compressão afeta a latência?
Pode aumentar levemente, porque o servidor gasta tempo comprimindo e o cliente, descomprimindo. Em payloads grandes e conexões lentas, a redução de bytes costuma compensar. Em payloads pequenos e redes rápidas, o efeito pode ser neutro ou negativo.
