Kde môže komprimujúca proxy ušetriť šírku pásma
Umiestnite redukciu obsahu pred obmedzené klientske spojenie a zohľadnite kvalitu obrázkov, existujúcu kompresiu a viditeľnosť HTTPS.
Umiestnite redukciu obsahu pred obmedzené spojenie na ceste odpovede:
website → proxy transforms response → slow or metered link → browserAk celé telo už tým spojením prešlo, jeho neskoršie zmenšenie tieto bajty nezíska späť. Vzdialený transformátor s rýchlejším upstreamom môže slúžiť inému účelu než lokálna proxy pri prehliadači.
Ziproxy tento prístup ilustruje: jeho projekt opisuje nekešujúcu HTTP proxy, ktorá komprimuje textový obsah pomocou gzip a môže vytvárať menšie obrázky nižšej kvality.
| Cesta odpovede | Možné zníženie |
|---|---|
| Kódovanie gzip | Bez straty; prehliadač dekóduje pôvodné dáta |
| Opätovná kompresia obrázkov | Môže zahodiť detaily a byť nevhodná, keď záleží na presných obrázkoch |
| Už efektívne komprimovaný obsah | Menej priestoru na ďalšie zníženie |
| Bežné HTTPS CONNECT | Nepriehľadný TLS bráni transformácii HTML alebo obrázkov bez iného dôveryhodného usporiadania prístupu k otvorenému textu |
Spracovanie aj ďalší skok zaberú čas, takže menej bajtov nezaručuje rýchlejšie dokončenie. Kešovanie znova využíva vhodnú uloženú odpoveď; kompresia môže transformovať novo získanú odpoveď bez jej uloženia.
Kde je obsah HTTP viditeľný, dodržiavajte Cache-Control: no-transform. Zásada odpovede no-transform riadi vyhovujúce zaobchádzanie s obsahom; je oddelená od šifrovania prenosu. Odhadujte prínosy zo skutočného obsahu a cesty šifrovania, nie zo starej ukážky obrázkov v otvorenom texte.