Onde um proxy de compressão pode poupar largura de banda
Coloque a redução de conteúdo antes da ligação restrita do cliente e considere a qualidade das imagens, a compressão existente e a visibilidade de HTTPS.
Coloque a redução de conteúdo antes da ligação restrita no caminho de resposta:
website → proxy transforms response → slow or metered link → browserSe o corpo completo já atravessou essa ligação, reduzi-lo depois não recupera esses bytes. Um transformador remoto com uma ligação ascendente mais rápida pode servir um propósito diferente do de um proxy local junto ao navegador.
O Ziproxy ilustra esta abordagem: o seu projeto descreve um proxy HTTP sem cache que comprime com gzip conteúdo do tipo texto e pode produzir imagens mais pequenas e de menor qualidade.
| Caminho de resposta | Redução possível |
|---|---|
| Codificação gzip | Sem perdas; o navegador descodifica os dados originais |
| Recompressão de imagens | Pode descartar detalhe e ser inadequada quando as imagens exatas importam |
| Conteúdo já comprimido de forma eficiente | Menos margem para redução adicional |
| HTTPS CONNECT comum | O TLS opaco impede a transformação de HTML ou imagens sem outro arranjo de confiança para aceder ao texto simples |
O processamento e o salto adicional também consomem tempo, pelo que menos bytes não garantem uma conclusão mais rápida. A cache reutiliza uma resposta armazenada elegível; a compressão pode transformar uma resposta recentemente obtida sem a armazenar.
Onde o conteúdo HTTP é visível, respeite Cache-Control: no-transform. A política de resposta no-transform rege o tratamento conforme do conteúdo; é separada da cifragem de transporte. Estime os benefícios a partir do conteúdo real e do caminho de cifragem, não de uma demonstração antiga com imagens em texto simples.