Où un proxy de compression peut économiser de la bande passante
Placez la réduction de contenu avant le lien client contraint et tenez compte de la qualité des images, de la compression existante et de la visibilité HTTPS.
Placez la réduction de contenu avant le lien contraint sur le chemin de réponse :
website → proxy transforms response → slow or metered link → browserSi le corps complet a déjà franchi ce lien, le réduire ensuite ne récupère pas ces octets. Un transformateur distant doté d'un amont plus rapide peut servir un autre objectif qu'un proxy local à côté du navigateur.
Ziproxy illustre l'approche : son projet décrit un proxy HTTP sans cache qui compresse en gzip les contenus de type texte et peut produire des images plus petites et de moindre qualité.
| Chemin de réponse | Réduction possible |
|---|---|
| Codage gzip | Sans perte ; le navigateur décode les données d'origine |
| Recompression des images | Peut sacrifier des détails et être inadaptée lorsque des images exactes importent |
| Contenu déjà comprimé efficacement | Moins de marge pour une réduction supplémentaire |
| HTTPS CONNECT ordinaire | Le TLS opaque empêche la transformation du HTML ou des images sans un autre dispositif de confiance pour accéder au texte en clair |
Le traitement et le saut supplémentaire prennent aussi du temps, donc moins d'octets ne garantissent pas une fin plus rapide. Le cache réutilise une réponse stockée éligible ; la compression peut transformer une réponse fraîchement récupérée sans la stocker.
Là où le contenu HTTP est visible, respectez Cache-Control: no-transform. La politique de réponse no-transform régit le traitement conforme du contenu ; elle est distincte du chiffrement de transport. Estimez les bénéfices à partir du contenu réel et du chemin de chiffrement, non d'une ancienne démonstration d'images en clair.