Hvor en komprimerende proxy kan spare båndbredde
Plasser innholdsreduksjon foran den begrensede klientlenken og ta hensyn til bildekvalitet, eksisterende komprimering og HTTPS-synlighet.
Plasser innholdsreduksjon foran den begrensede lenken på svarveien:
website → proxy transforms response → slow or metered link → browserDersom hele kroppen allerede har passert denne lenken, kan en senere reduksjon ikke gjenopprette de bytene. En fjerntliggende transformator med raskere oppstrøm kan tjene et annet formål enn en lokal proxy ved siden av nettleseren.
Ziproxy viser denne fremgangsmåten: prosjektet beskriver en HTTP-proxy uten hurtigbuffer som gzipper tekstlignende innhold og kan produsere mindre bilder med lavere kvalitet.
| Svarvei | Mulig reduksjon |
|---|---|
| Gzip-koding | Tapfri; nettleseren dekoder originaldataene |
| Ny komprimering av bilder | Kan forkaste detaljer og være uegnet når nøyaktige bilder er viktige |
| Innhold som allerede er komprimert effektivt | Mindre rom for ytterligere reduksjon |
| Vanlig HTTPS CONNECT | Ugjennomsiktig TLS forhindrer omforming av HTML eller bilder uten en annen betrodd ordning for tilgang til klartekst |
Behandling og det ekstra spranget tar også tid, så færre byte garanterer ikke raskere fullføring. Bufring bruker et egnet lagret svar på nytt; komprimering kan omforme et nylig hentet svar uten å lagre det.
Der HTTP-innhold er synlig, respekter Cache-Control: no-transform. Retningslinjen for no-transform-svar styrer samsvarende innholdshåndtering; den er atskilt fra transportkryptering. Vurder fordelene ut fra det faktiske innholdet og krypteringsveien, ikke ut fra en gammel demonstrasjon med klartekstbilder.