Hvor en komprimerende proxy kan spare båndbredde
Plasser innholdsreduksjon før den begrensede klientlenken og ta hensyn til bildekvalitet, eksisterende komprimering og HTTPS-synlighet.
Plasser innholdsreduksjon før den begrensede lenken på svarveien:
website → proxy transforms response → slow or metered link → browserHvis hele kroppen allerede har passert den lenken, kan en senere forminsking ikke gjenopprette de bytene. En ekstern transformator med raskere oppstrøm kan tjene et annet formål enn en lokal proxy ved nettleseren.
Ziproxy illustrerer tilnærmingen: prosjektet beskriver en ikke-cachende HTTP-proxy som gzipper tekstlignende innhold og kan produsere mindre bilder av lavere kvalitet.
| Svarvei | Mulig reduksjon |
|---|---|
| Gzip-koding | Uten tap; nettleseren dekoder de opprinnelige dataene |
| Rekomprimering av bilder | Kan kaste detaljer og være uegnet når eksakte bilder betyr noe |
| Innhold som allerede er effektivt komprimert | Mindre rom for ytterligere reduksjon |
| Vanlig HTTPS CONNECT | Ugjennomsiktig TLS hindrer transformasjon av HTML eller bilder uten en annen betrodd ordning for tilgang til klartekst |
Behandling og det ekstra hoppet tar også tid, så færre byte garanterer ikke raskere fullføring. Bufring gjenbruker et egnet lagret svar; komprimering kan transformere et nylig hentet svar uten å lagre det.
Der HTTP-innhold er synlig, respekter Cache-Control: no-transform. Retningslinjen for no-transform-svar styrer i samsvar med reglene for innholdshåndtering; den er atskilt fra transportkryptering. Vurder fordelene ut fra det faktiske innholdet og krypteringsveien, ikke fra en gammel demonstrasjon med klartekstbilder.