Kie kunprema prokurilo povas ŝpari bendolarĝon
Metu enhavredukton antaŭ la limigita klienta ligo kaj konsideru bildkvaliton, ekzistantan kunpremadon kaj HTTPS-videblecon.
Metu enhavredukton antaŭ la limigita ligo sur la responda vojo:
website → proxy transforms response → slow or metered link → browserSe la tuta korpo jam trapasis tiun ligon, malgrandigi ĝin poste ne rekuperas tiujn bajtojn. Fora transformilo kun pli rapida suprenfluo povas servi al alia celo ol loka prokurilo apud la retumilo.
Ziproxy ilustras la aliron: ĝia projekto priskribas nekaŝan HTTP-prokurilon, kiu gzip-kunpremas tekstosimilan enhavon kaj povas produkti pli malgrandajn bildojn de pli malalta kvalito.
| Responda vojo | Ebla redukto |
|---|---|
| Gzip-kodado | Senperda; la retumilo malkodas la originajn datumojn |
| Rekunpremado de bildoj | Povas forĵeti detalojn kaj esti netaŭga, kiam precizaj bildoj gravas |
| Jam efike kunpremita enhavo | Malpli da spaco por plua redukto |
| Ordinara HTTPS CONNECT | Netravidebla TLS malhelpas transformi HTML aŭ bildojn sen alia fidinda aranĝo por aliro al klarteksto |
Ankaŭ prilaborado kaj la plia salto bezonas tempon, do malpli da bajtoj ne garantias pli rapidan finiĝon. Kaŝado reuzas taŭgan konservitan respondon; kunpremado povas transformi ĵus akiritan respondon sen konservi ĝin.
Kie HTTP-enhavo estas videbla, respektu Cache-Control: no-transform. La responda politiko no-transform regas konforman enhavtraktadon; ĝi estas aparta de transporta ĉifrado. Taksi utilecon laŭ la reala enhavo kaj ĉifrada vojo, ne laŭ malnova demonstro de bildoj en klarteksto.