Kvar ein komprimerande proxy kan spara bandbreidd
Set innhaldsreduksjon før den avgrensa klientlenkja og ta omsyn til biletkvalitet, eksisterande komprimering og HTTPS-synlegheit.
Set innhaldsreduksjon før den avgrensa lenkja på svarvegen:
website → proxy transforms response → slow or metered link → browserDersom heile kroppen allereie har passert den lenkja, kan ein seinare forminsking ikkje vinne dei byta attende. Ein ekstern transformator med raskare oppstraum kan tene eit anna føremål enn ein lokal proxy ved nettlesaren.
Ziproxy syner framgangsmåten: prosjektet skildrar ein ikkje-cachande HTTP-proxy som gzippar tekstliknande innhald og kan lage mindre bilete av lågare kvalitet.
| Svarveg | Mogleg reduksjon |
|---|---|
| Gzip-koding | Utan tap; nettlesaren dekodar dei opphavlege dataa |
| Rekomprimering av bilete | Kan kaste detaljar og vere ueigna når nøyaktige bilete er viktige |
| Innhald som allereie er effektivt komprimert | Mindre rom for ytterlegare reduksjon |
| Vanleg HTTPS CONNECT | Ugjennomsiktig TLS hindrar transformasjon av HTML eller bilete utan ei anna truverdig ordning for tilgang til klartekst |
Behandling og det ekstra hoppet tek òg tid, så færre byte garanterer ikkje raskare fullføring. Bufring nyttar eit eigna lagra svar om att; komprimering kan transformere eit nyleg henta svar utan å lagre det.
Der HTTP-innhald er synleg, respekter Cache-Control: no-transform. Retningslinja for no-transform-svar styrer samsvarande handsaming av innhald; ho er skild frå transportkryptering. Vurder fordelane ut frå det faktiske innhaldet og krypteringsvegen, ikkje ut frå ein gamal demonstrasjon med klartekstbilete.