Var en komprimerande proxy kan spara bandbredd
Placera innehållsreducering före den begränsade klientlänken och ta hänsyn till bildkvalitet, befintlig komprimering och HTTPS-synlighet.
Placera innehållsreducering före den begränsade länken på svarsvägen:
website → proxy transforms response → slow or metered link → browserOm hela kroppen redan har passerat den länken kan en senare förminskning inte återvinna de byten. En fjärrtransformator med snabbare uppströmslänk kan tjäna ett annat syfte än en lokal proxy vid webbläsaren.
Ziproxy illustrerar tillvägagångssättet: projektet beskriver en icke-cachande HTTP-proxy som gzippar textliknande innehåll och kan producera mindre bilder med lägre kvalitet.
| Svarsväg | Möjlig minskning |
|---|---|
| Gzip-kodning | Förlustfri; webbläsaren avkodar originaldata |
| Omkomprimering av bilder | Kan kasta bort detaljer och vara olämplig när exakta bilder spelar roll |
| Innehåll som redan är effektivt komprimerat | Mindre utrymme för ytterligare minskning |
| Vanlig HTTPS CONNECT | Ogenomskinlig TLS hindrar omvandling av HTML eller bilder utan en annan betrodd ordning för åtkomst till klartext |
Bearbetning och det extra språnget tar också tid, så färre byte garanterar inte snabbare slutförande. Cachning återanvänder ett lämpligt lagrat svar; komprimering kan omvandla ett nyligen hämtat svar utan att lagra det.
Där HTTP-innehåll är synligt, respektera Cache-Control: no-transform. Policyn för no-transform-svar styr regelriktig innehållshantering; den är skild från transportkryptering. Uppskatta nyttan utifrån det faktiska innehållet och krypteringsvägen, inte utifrån en gammal demonstration med klartextbilder.