Waar een comprimerende proxy bandbreedte kan besparen
Plaats inhoudsreductie vóór de beperkte clientverbinding en houd rekening met beeldkwaliteit, bestaande compressie en HTTPS-zichtbaarheid.
Plaats inhoudsreductie vóór de beperkte verbinding op het antwoordpad:
website → proxy transforms response → slow or metered link → browserAls de volledige body die verbinding al is gepasseerd, kan verkleining achteraf die bytes niet terugwinnen. Een externe transformator met een snellere upstream kan een ander doel dienen dan een lokale proxy naast de browser.
Ziproxy illustreert de aanpak: het project beschrijft een niet-cachende HTTP-proxy die tekstachtige inhoud gzipt en kleinere afbeeldingen van lagere kwaliteit kan produceren.
| Antwoordpad | Mogelijke reductie |
|---|---|
| Gzip-codering | Verliesvrij; de browser decodeert de oorspronkelijke gegevens |
| Hercompressie van afbeeldingen | Kan detail weggooien en ongeschikt zijn wanneer exacte afbeeldingen ertoe doen |
| Inhoud die al efficiënt is gecomprimeerd | Minder ruimte voor verdere reductie |
| Gewone HTTPS CONNECT | Ondoorzichtig TLS verhindert omzetting van HTML of afbeeldingen zonder een andere vertrouwde regeling voor toegang tot platte tekst |
Verwerking en de extra sprong kosten ook tijd, dus minder bytes garanderen geen snellere voltooiing. Caching hergebruikt een geschikt opgeslagen antwoord; compressie kan een zojuist opgehaald antwoord omzetten zonder het op te slaan.
Waar HTTP-inhoud zichtbaar is, respecteer Cache-Control: no-transform. Het no-transform-antwoordbeleid regelt conforme inhoudsbehandeling; het staat los van transportversleuteling. Schat voordelen in op basis van de werkelijke inhoud en het versleutelingspad, niet op basis van een oude demonstratie met platte-tekstafbeeldingen.