Gdje kompresijski proxy može uštedjeti propusnost
Stavite smanjenje sadržaja prije ograničene veze klijenta i uzmite u obzir kvalitetu slika, postojeću kompresiju i vidljivost HTTPS-a.
Stavite smanjenje sadržaja prije ograničene veze na putu odgovora:
website → proxy transforms response → slow or metered link → browserAko je cijelo tijelo već prošlo tu vezu, kasnije smanjivanje ne može vratiti te bajtove. Udaljeni pretvarač s bržom uzlaznom vezom može služiti drugoj svrsi od lokalnog proxyja uz preglednik.
Ziproxy ilustrira taj pristup: njegov projekt opisuje HTTP proxy bez keširanja koji gzip kompresijom obrađuje tekstualni sadržaj i može proizvesti manje slike niže kvalitete.
| Put odgovora | Moguće smanjenje |
|---|---|
| Gzip kodiranje | Bez gubitaka; preglednik dekodira izvorne podatke |
| Ponovna kompresija slika | Može odbaciti pojedinosti i biti neprikladna kada su točne slike važne |
| Sadržaj koji je već učinkovito komprimiran | Manje prostora za daljnje smanjenje |
| Uobičajeni HTTPS CONNECT | Neprozirni TLS sprječava pretvorbu HTML-a ili slika bez drugog pouzdanog rješenja za pristup otvorenom tekstu |
Obrada i dodatni skok također traju, pa manje bajtova ne jamči brže dovršenje. Keširanje ponovno koristi prihvatljiv pohranjen odgovor; kompresija može pretvoriti novopreuzeti odgovor bez pohrane.
Gdje je HTTP sadržaj vidljiv, poštujte Cache-Control: no-transform. Politika odgovora no-transform uređuje sukladno rukovanje sadržajem; odvojena je od transportnog šifriranja. Procijenite koristi prema stvarnom sadržaju i putu šifriranja, a ne prema staroj demonstraciji slika u otvorenom tekstu.