Dove un proxy di compressione può risparmiare banda
Collocare la riduzione del contenuto prima del collegamento client limitato e tenere conto della qualità delle immagini, della compressione esistente e della visibilità HTTPS.
Collocare la riduzione del contenuto prima del collegamento limitato sul percorso di risposta:
website → proxy transforms response → slow or metered link → browserSe il corpo completo ha già attraversato quel collegamento, ridurlo in seguito non recupera quei byte. Un trasformatore remoto con un upstream più veloce può servire a uno scopo diverso da un proxy locale accanto al browser.
Ziproxy illustra l'approccio: il suo progetto descrive un proxy HTTP senza cache che comprime con gzip i contenuti di tipo testuale e può produrre immagini più piccole e di qualità inferiore.
| Percorso di risposta | Riduzione possibile |
|---|---|
| Codifica gzip | Senza perdita; il browser decodifica i dati originali |
| Ricompressione delle immagini | Può scartare dettagli ed essere inadatta quando le immagini esatte contano |
| Contenuto già compresso in modo efficiente | Meno margine per un'ulteriore riduzione |
| HTTPS CONNECT ordinario | Il TLS opaco impedisce la trasformazione di HTML o immagini senza un altro accordo fidato per accedere al testo in chiaro |
Anche l'elaborazione e il salto aggiuntivo richiedono tempo, quindi meno byte non garantiscono un completamento più rapido. La cache riutilizza una risposta memorizzata idonea; la compressione può trasformare una risposta appena recuperata senza memorizzarla.
Dove il contenuto HTTP è visibile, rispettare Cache-Control: no-transform. La politica di risposta no-transform disciplina il trattamento conforme dei contenuti; è distinta dalla cifratura del trasporto. Stimare i benefici dal contenuto reale e dal percorso di cifratura, non da una vecchia dimostrazione con immagini in chiaro.