...
logótipo de alojamento web

Limiares de compressão HTTP: Configurações óptimas para alojamento web

Os limites de compressão HTTP determinam o tamanho a que o seu servidor comprime o conteúdo e, assim, controlam diretamente o TTFB, a carga da CPU e a largura de banda. Neste guia, mostrar-lhe-ei limiares, níveis e definições de cabeçalho específicos para uma entrega rápida, bem como uma separação clara entre compressão dinâmica e estática. Compressão.

Pontos centrais

Resumirei primeiro os ajustes mais importantes para que possa começar de forma direcionada e evitar o desperdício de ciclos de CPU desnecessários. Baseio-me em limites claros, níveis adequados e cabeçalhos limpos para que os browsers, proxies e CDNs funcionem corretamente em conjunto. Faço a distinção entre respostas dinâmicas e activos de construção e mantenho a compressão por salto estritamente sob controlo. Minimizo o TTFB com níveis moderados de compressão em tempo de execução e obtenho a taxa máxima de ficheiros pré-comprimidos. Verifico regularmente as métricas e ajusto os limites à carga, à mistura de ficheiros e à latência do mundo real, para que a sua configuração seja visivelmente mais eficiente. mais rápido ...a vontade.

  • Limiar 512-1024 B, padrão 1024 B
  • Pauzinho de pão 3-4 dinâmico, 9-11 estático
  • Gzip 5-6 como alternativa
  • MIME Apenas recursos de texto
  • Variar e ETag por codificação

O que são limiares de compressão HTTP?

Um limiar determina o tamanho acima do qual uma resposta é comprimida e evita que a sobrecarga do cabeçalho aumente artificialmente os pequenos ficheiros; é precisamente aqui que Ponto de equilíbrio-Considerações. Com respostas muito pequenas, a codificação de conteúdos pode aumentar a carga útil e custar CPU ao mesmo tempo. Por isso, normalmente defino um limite inferior de 1024 bytes, ou 512 bytes para APIs de alta frequência com muitas respostas pequenas. Limites menores aumentam a taxa de compressão, mas aumentam o TTFB e a CPU quando o conteúdo dinâmico varia muito. Limites maiores poupam tempo de computação, mas arriscam um potencial desperdiçado com ficheiros HTML, CSS ou JSON de tamanho médio que são de boa qualidade. Redução lucro.

Brotli vs. Gzip: Escolha e níveis

O Brotli consegue frequentemente taxas 15-21% melhores do que o Gzip para recursos de texto, mas custa mais CPU por pedido, o que eu tenho em conta para respostas dinâmicas e uso níveis moderados. almofada. Para compressão em tempo de execução, utilizo Brotli nível 3-4, para activos pré-empacotados nível 9-11. Para clientes antigos ou conteúdos que mudam muito, utilizo Gzip nível 5-6. O HTTP/2 e o HTTP/3 beneficiam de uma boa compressão, desde que os buffers do servidor e os pontos de descarga estejam corretamente definidos e não haja paragens no fluxo. Se quiser fazer uma comparação mais aprofundada, pode encontrar mais informações na minha Comparação Gzip vs. Brotli valores e considerações práticas adicionais que fazem a escolha no alojamento quotidiano facilitar.

Definir limiares: Barreiras de proteção e limiar de rentabilidade

Começo com 1024 bytes como limite básico, porque a sobrecarga do cabeçalho é claramente compensada e a utilização da CPU permanece razoável, especialmente com HTML e JSON, que são muito diferentes. condensar sair. Com redes de latência muito baixa e muitas respostas API mínimas, 512 bytes podem ser úteis. A compressão raramente vale a pena abaixo de 512 bytes, porque os custos de administração geralmente excedem a redução da carga útil. No caso de máquinas muito utilizadas, eu aumento temporariamente o limite até que os reservatórios da CPU tenham buffers novamente. Este ajuste gradual mantém o TTFB baixo e preserva o Estabilidade do sistema global.

Comprimir tipos MIME especificamente

Apenas comprimo MIMEs de texto, como text/html, text/css, application/javascript, application/json e image/svg+xml, porque podem ser utilizados por razões de redundância. Ganhos arrastar. Deixo conteúdos binários como image/*, application/pdf ou font/woff2 intactos, uma vez que o efeito é pequeno ou negativo. Para os tipos de letra, utilizo diretamente o WOFF2 porque já codifica eficientemente e a compressão adicional é de pouca utilidade. Mantenho listas de permissões explícitas e evito wildcards para que nenhum ficheiro binário acabe acidentalmente no codificador. Desta forma, mantenho a cadeia de compressão limpa e evito Corrupção devido a erros de classificação.

Estático vs. dinâmico: separação clara

Eu empacoto ativos estáticos no processo de compilação ou na borda da CDN com antecedência como .br e .gz e deixo o servidor usar essas variantes diretamente. entregar. Para respostas dinâmicas, defino níveis moderados e mantenho os buffers suficientemente pequenos para que o primeiro bloco de bytes flua rapidamente. É importante comprimir apenas um salto nas cadeias de proxy para que não ocorra dupla compressão. Posso desligar a compressão na Origem se o CDN já a tiver feito e a separar corretamente através do Vary. Essa separação economiza CPU e garante uma compressão constante Tempos de resposta mesmo sob carga.

Gestão de cabeçalhos e armazenamento em cache

Envio sempre Vary: Accept-Encoding para que as caches distingam as variantes corretamente e não haja falhas que atrasem os utilizadores ou falsifiquem os activos; este cabeçalho é decisivo. Para ficheiros estáticos, utilizo a codificação de conteúdo (br/gzip) mais o comprimento do conteúdo, enquanto os fluxos dinâmicos funcionam frequentemente com a codificação de transferência: chunked. As ETags devem ser específicas da codificação, caso contrário, a cache fornecerá versões incorrectas. Também defino TTLs de cache longos para activos pré-comprimidos e protejo-os com controlo de cache: público, imutável, se os hashes do ficheiro estiverem no nome. Apresento aqui um ponto de partida compacto: Configuração da compressão HTTP, que lhe mostrará os elementos mais importantes do Sequência espectáculos.

HTTP/2 e HTTP/3: Flush e buffer

Com HTTP/2 e HTTP/3, presto atenção aos pontos de descarga iniciais para que HTML e CSS críticos não atrasem o início da renderização. atraso. Os buffers demasiado grandes podem tornar a multiplexagem mais lenta porque um fluxo domina o agendamento e outro conteúdo fica à espera. Eu mantenho os primeiros blocos de compressão pequenos e envio rapidamente, depois aumento o tamanho do bloco para ficheiros longos. O Brotli mostra boas taxas com sobrecarga moderada, desde que o nível 3-4 seja usado para respostas dinâmicas. Isto mantém a interatividade elevada, enquanto os pacotes grandes são eficientes. encolher.

Prática: Apache, Nginx, Caddy

Começo com níveis moderados e um limiar de 1024 bytes e depois verifico sistematicamente o TTFB e a CPU em vez de definir cegamente as taxas máximas. aplicar. Para o Apache, ativo o mod_deflate ou o mod_brotli e defino apenas os tipos MIME pretendidos. No Nginx, defino o gzip_min_length 1024 e o Brotli como ligado, combinando-o com o brotli_static para ficheiros pré-comprimidos. O Caddy oferece comutadores simples com codificações gzip zstd br; eu lido com caminhos dinâmicos com níveis baixos separadamente. Por experiência própria, vale a pena dar uma olhada em Carga da CPU e nível de compressão, porque a combinação da proporção de respostas dinâmicas e o número de núcleos excede frequentemente o limite. conjuntos.

Apache Exemplo (mod_deflate/mod_brotli):

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 SetOutputFilter DEFLATE
 DeflateCompressionLevel 6
 DeflateBufferSize 64k



 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 BrotliCompressionQuality 4
 BrotliWindowSize 22

Nginx Exemplo:

gzip ligado;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript image/svg+xml;
gzip_comp_level 5;

brotli ligado;
brotli_comp_level 4;
brotli_static on;
brotli_types text/plain text/css application/json application/javascript image/svg+xml;

Monitorização e resolução de problemas

Meço o TTFB, a utilização da CPU por trabalhador e o tamanho da transferência por tipo, para poder ver onde a compressão ajuda e onde é necessária. danos. Se o TTFB aumentar após a ativação, reduzo o nível ou aumento o limiar. Se houver efeitos estranhos, verifico primeiro se há dupla compressão, cabeçalhos Vary em falta ou tipos MIME incorretamente reconhecidos. Também verifico as políticas CDN e WAF, porque um segundo salto com compressão desloca a carga e muitas vezes piora o tempo até ao primeiro byte. Ferramentas como o WebPageTest e o Browser-DevTools são suficientes para uma verificação inicial. Auditoria completamente.

Pontos de medição e valores recomendados

Mantenho-me fiel a alguns parâmetros claros para que a configuração permaneça controlável e continue a atingir um elevado nível de qualidade. Efeito mostra. A tabela seguinte resume os limiares, níveis e instruções de armazenamento em cache úteis. Abrange pilhas típicas da Web com HTML, CSS, JS, JSON, SVG e fontes. Ajuste o limite de acordo com a carga, o reservatório da CPU e a proporção de respostas dinâmicas. Comece de forma conservadora, meça e mova iterativamente os controles deslizantes em pequenos incrementos. Passos.

Recursos Limiar (bytes) Dinâmico (nível) Estático (Nível) Sugestão de cache
HTML 1024 Br 3–4 / Gz 5–6 Br 9-11 (pré-comprimido) TTL longo para nomes de hash
CSS/JS 1024 Raramente dinâmico Br 9-11 (pré-comprimido) imutável, variantes por hash
JSON (APIs) 512-1024 Br 3–4 / Gz 5–6 não é comum Manter o cabeçalho consistente
SVG 1024 Raramente dinâmico Br 9–11 Pedidos de intervalo de ensaio
Tipos de letra (WOFF2) nenhum nenhum nenhum Não comprimir mais
Imagens (PNG/JPEG/WEBP) nenhum nenhum nenhum Otimização separada
PDF nenhum nenhum nenhum Evitar a codificação

Zstd em contexto: quando faz sentido, quando não faz

Classifico o Zstd de forma independente porque tem excelentes Taxas de produção com boa compressão. No entanto, no ambiente do browser, o suporte é heterogéneo, razão pela qual não costumo implementar o Zstd como a principal codificação do utilizador final. Entre serviços internos ou na rota do backbone CDN, o Zstd pode ser muito útil para manter o tráfego do Origin CDN eficiente. No limite, mantenho o Brotli (para texto) e o Gzip como alternativa até que uma base de clientes com amplo suporte garanta que as variantes sejam negociadas corretamente. No Caddy, deixo o Zstd opcionalmente ativo, mas dou prioridade ao Negociação Brotli antes do Gzip para equilibrar compatibilidade e desempenho.

Pedidos de alcance, descarregamentos e ficheiros pré-comprimidos

Verifico as transferências de grande dimensão (por exemplo, PDFs, CSVs) separadamente. Para dados binários, normalmente desativo a codificação de conteúdo e entrego a identidade (identidade) para que as solicitações de intervalo funcionem corretamente e os downloads permaneçam estáveis. Para arquivos de texto estáticos com variantes .br/.gz, asseguro que o servidor selecione a variante correta dependendo da solicitação do cliente e que o comprimento do conteúdo, a codificação do conteúdo e o ETag sejam consistentes. Para solicitações parciais de variantes compactadas, os intervalos de bytes para o comprimido comprimento - se a pilha não lidar com isso de forma robusta, eu entrego a versão descomprimida para pedidos de intervalo. Isto atenua os casos extremos e evita reinícios incorrectos.

Segurança: compressão e fugas de dados

Tenho em conta os canais secundários relacionados com a compressão, tais como VIOLAÇÃO. Se as respostas reflectirem conteúdos dependentes de segredos (tokens, IDs de sessão) próximos de entradas que possam ser controladas pelo atacante, desactivarei seletivamente a compressão ou dissociarei os segredos (preenchimento, separação em campos separados não comprimidos). Para os caminhos de início de sessão e de pagamento, faz sentido desativar a compressão utilizando cabeçalhos ou regras. Os cookies com cabeçalhos de cookie definidos não são críticos, o que é importante é o Resposta-payload. Por isso, tenho filtros prontos que visam o caminho, o MIME ou determinados modelos, de modo a aplicar facilmente a heurística.

Cadeias CDN e proxy: uma compressão por salto

Defino claramente o salto em que a compressão tem lugar: Ou no Borda (CDN) ou na Origem, não em ambos. Se a CDN comprime, eu omito a codificação do conteúdo na Origin e envio Vary: Accept encoding para que o Edge construa as variantes corretas. Se a Origin tiver que entregar assets pré-comprimidos (.br/.gz), eu configuro o Edge para enviar esses arquivos para a CDN. Transparente e não o transforma novamente. Se eu quiser impedir estritamente as transformações por proxies intermediários (por exemplo, para conformidade), defino Cache-Control: no-transform - então planeio a compressão especificamente na origem. Para depuração, anoto em qual salto o Compressão e manter as métricas separadas por salto.

Streaming, SSE, gRPC e WebSockets

Para eventos enviados pelo servidor (SSE) e fluxos semelhantes, evito níveis elevados e grande caso contrário, a latência aumenta visivelmente. Utilizo blocos pequenos, descargas frequentes e compressão mais desactivada se a interatividade tiver prioridade. O gRPC utiliza a sua própria compressão de mensagens e é executado via HTTP/2 - aqui evito a codificação adicional de conteúdo HTTP para evitar a duplicação. O mesmo se aplica aos WebSockets: o deflate por mensagem pode ser útil, mas eu só o ativo para canais realmente pesados de texto e observo o CPU-efeito exato.

Servidor de aplicações: Definir especificamente as definições da camada de aplicação

Prefiro controlar os limiares no proxy de borda/reverso, mas quando os quadros são comprimidos, defino valores consistentes para que nada funcione em conjunto.

  • Node.js/ExpressDefino um limite de 1024 bytes e níveis moderados. O manipulador estático serve activos estáticos pré-comprimidos diretamente, apenas comprimo rotas dinâmicas para MIMEs de texto.
  • VáSelecciono uma lista clara de MIMEs permitidos para cada manipulador e ignoro a compressão abaixo de 1 KB. Para fluxos longos, mantenho os fluxos de escrita pequenos para não sobrecarregar a primeira pintura. atraso.
  • Java/TomcatUtilizo compressionMinSize 1024 e mantenho a lista MIME explicitamente; os tipos binários são deixados de fora.

Tomcat Exemplo (conetor server.xml):

<Connector port="8080" protocol="HTTP/1.1"
    compression="on"
    compressionMinSize="1024"
    noCompressionUserAgents=""
    compressableMimeType="text/html,text/css,application/javascript,application/json,image/svg+xml"
    URIEncoding="UTF-8" />

Importante: Se um proxy upstream (Nginx, Caddy) já estiver a comprimir, desativo a compressão da camada de aplicação para Duplicação de trabalho e deixar que apenas uma camada assuma a responsabilidade.

Limiares adaptativos e controlo da carga

Penso em termos de políticas em vez de valores rígidos. Sob uma carga elevada de CPU, levanto o Limiar temporariamente (por exemplo, de 1024 para 2048 bytes) ou diminuir o nível de Brotli (por exemplo, de 4 para 2) para respostas dinâmicas. Se a carga diminuir, aumento os valores novamente. Isso pode ser controlado por meio de um sinalizador de recurso, variáveis Env ou um simples recarregamento. Em nós com pouca CPU, reservo a compressão para os MIMEs mais importantes (HTML/JSON), enquanto o CSS/JS vem quase exclusivamente pré-comprimido do armazenamento/CDN. Este Definição de prioridades mantém a TTFB estável em vez de atingir picos.

Manual de testes: verificação rápida

Verifico o efeito com alguns passos reprodutíveis:

  • Negociação: curl -I -H „Accept-Encoding: br“ https://example.com - verificar Content-Encoding, Vary e Content-Length.
  • Recuo: curl -I -H „Accept-Encoding: gzip“ - espera-se gzip? ETag diferente de Brotli?
  • Sem compressãocurl -I -H „Accept-Encoding: identity“ - Comparar a diferença de tamanho e TTFB.
  • Gama: curl -I -H „Range: bytes=0-1023“ - o servidor aceita corretamente os subintervalos e o Content-Range é adequado?
  • DevToolsComparar o tamanho „Sobre a rede“ com o „Tamanho do recurso“ para determinar o tamanho real Poupança para ver.

Brevemente resumido

Defina o limite para 1024 bytes como um ponto de partida rápido, verifique o TTFB e a CPU e ajuste as definições com pequenos Ajustamentos depois. Utilize Brotli 3-4 para conteúdo dinâmico e 9-11 para activos pré-comprimidos, mantendo o Gzip 5-6 como alternativa. Comprima apenas MIMEs de texto e forneça ficheiros pré-comprimidos diretamente para manter os activos de construção leves e duradouros. Preste atenção a Vary: Accept-Encoding, Content-Encoding e ETags específicos de codificação para que as caches funcionem corretamente. Com os limites de compressão HTTP corretamente definidos, pode acelerar visivelmente a entrega sem sobrecarregar a máquina com trabalho de computação desnecessário. bloco.

Artigos actuais