# Compressão de tráfego API: 9 estratégias para reduzir banda > Compressão de tráfego API reúne técnicas que reduzem o volume de bytes trocados entre cliente e servidor, compactando payloads ou evitando transmitir dados inalterados. As duas abordagens resolvem problemas distintos e podem ser combinadas para diminuir consumo de banda, latência e custos de infraestrutura em integrações. *Blog Sem Juízo · Especiais · 17 de setembro de 2026 · Igor Bastos* 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. 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. --- Fonte (canonical): https://blogsemjuizo.com.br/especiais/compressao-de-trafego-api-9-estrategias-para-reduzir-banda/