Kde může komprimující proxy ušetřit šířku pásma
Umístěte redukci obsahu před omezené klientské spojení a počítejte s kvalitou obrázků, stávající kompresí a viditelností HTTPS.
Umístěte redukci obsahu před omezené spojení na cestě odpovědi:
website → proxy transforms response → slow or metered link → browserPokud celé tělo už tím spojením prošlo, jeho následné zmenšení tyto bajty nezíská zpět. Vzdálený transformátor s rychlejším upstreamem může sloužit jinému účelu než lokální proxy u prohlížeče.
Ziproxy tento přístup ilustruje: jeho projekt popisuje nekešující HTTP proxy, která komprimuje textový obsah pomocí gzip a může vytvářet menší obrázky nižší kvality.
| Cesta odpovědi | Možné snížení |
|---|---|
| Kódování gzip | Bez ztráty; prohlížeč dekóduje původní data |
| Opětovná komprese obrázků | Může ztratit detaily a být nevhodná, když záleží na přesných obrázcích |
| Již efektivně komprimovaný obsah | Méně prostoru pro další snížení |
| Běžné HTTPS CONNECT | Neprůhledný TLS brání transformaci HTML nebo obrázků bez jiného důvěryhodného uspořádání přístupu k otevřenému textu |
Zpracování i další skok také zaberou čas, takže méně bajtů nezaručuje rychlejší dokončení. Kešování znovu využívá vhodnou uloženou odpověď; komprese může transformovat nově načtenou odpověď, aniž by ji ukládala.
Kde je obsah HTTP viditelný, dodržujte Cache-Control: no-transform. Zásada odpovědi no-transform řídí vyhovující zacházení s obsahem; je oddělená od šifrování přenosu. Odhadujte přínosy ze skutečného obsahu a cesty šifrování, ne ze staré ukázky obrázků v otevřeném textu.