On pot un proxy de compressió estalviar amplada de banda
Col·loqueu la reducció de contingut abans de l'enllaç restringit del client i tingueu en compte la qualitat de les imatges, la compressió existent i la visibilitat d'HTTPS.
Col·loqueu la reducció de contingut abans de l'enllaç restringit al camí de resposta:
website → proxy transforms response → slow or metered link → browserSi el cos complet ja ha travessat aquest enllaç, reduir-lo després no pot recuperar aquests bytes. Un transformador remot amb un enllaç ascendent més ràpid pot complir una funció diferent de la d'un proxy local al costat del navegador.
Ziproxy il·lustra l'enfocament: el seu projecte descriu un proxy HTTP sense memòria cau que comprimeix amb gzip el contingut de tipus text i pot produir imatges més petites i de menor qualitat.
| Camí de resposta | Reducció possible |
|---|---|
| Codificació gzip | Sense pèrdua; el navegador descodifica les dades originals |
| Recompressió d'imatges | Pot descartar detall i ser inadequada quan les imatges exactes són importants |
| Contingut ja comprimit eficientment | Menys marge per a una reducció addicional |
| HTTPS CONNECT ordinari | El TLS opac impedeix transformar HTML o imatges sense un altre acord de confiança per accedir al text pla |
El processament i el salt addicional també consumeixen temps, així que menys bytes no garanteixen una finalització més ràpida. La memòria cau reutilitza una resposta emmagatzemada elegible; la compressió pot transformar una resposta obtinguda de nou sense emmagatzemar-la.
On el contingut HTTP és visible, respecteu Cache-Control: no-transform. La política de resposta no-transform regeix el tractament conforme del contingut; és independent del xifratge de transport. Estimeu els beneficis a partir del contingut real i del camí de xifratge, no d'una demostració antiga amb imatges en text pla.