Hvor en komprimerende proxy kan spare båndbredde
Placer indholdsreduktion før det begrænsede klientlink, og tag højde for billedkvalitet, eksisterende komprimering og HTTPS-synlighed.
Placer indholdsreduktion før det begrænsede link på svarstien:
website → proxy transforms response → slow or metered link → browserHvis hele kroppen allerede har passeret det link, kan en efterfølgende formindskelse ikke genskabe de byte. En ekstern transformator med hurtigere upstream kan tjene et andet formål end en lokal proxy ved browseren.
Ziproxy illustrerer tilgangen: projektet beskriver en ikke-cachende HTTP-proxy, der gzipper tekstlignende indhold og kan producere mindre billeder af lavere kvalitet.
| Svarsti | Mulig reduktion |
|---|---|
| Gzip-kodning | Tabsfri; browseren afkoder de oprindelige data |
| Genkomprimering af billeder | Kan kaste detaljer væk og være uegnet, når præcise billeder betyder noget |
| Indhold, der allerede er effektivt komprimeret | Mindre plads til yderligere reduktion |
| Almindelig HTTPS CONNECT | Uigennemsigtig TLS forhindrer omdannelse af HTML eller billeder uden en anden betroet adgang til klartekst |
Behandling og det ekstra spring tager også tid, så færre byte garanterer ikke hurtigere afslutning. Caching genbruger et egnet gemt svar; komprimering kan omdanne et netop hentet svar uden at gemme det.
Hvor HTTP-indhold er synligt, respekter Cache-Control: no-transform. Retningslinjen for no-transform-svar styrer overensstemmende håndtering af indhold; den er adskilt fra transportkryptering. Vurder fordelene ud fra det faktiske indhold og krypteringsvejen, ikke ud fra en gammel demonstration med klartekstbilleder.