Unde un proxy de compresie poate economisi lățime de bandă
Plasați reducerea conținutului înaintea legăturii restricționate a clientului și țineți cont de calitatea imaginilor, de compresia existentă și de vizibilitatea HTTPS.
Plasați reducerea conținutului înaintea legăturii restricționate pe calea răspunsului:
website → proxy transforms response → slow or metered link → browserDacă întregul corp a trecut deja prin acea legătură, micșorarea lui ulterioară nu poate recupera acei octeți. Un transformator la distanță cu un uplink mai rapid poate servi unui scop diferit de cel al unui proxy local de lângă browser.
Ziproxy ilustrează abordarea: proiectul său descrie un proxy HTTP fără cache care comprimă cu gzip conținut de tip text și poate produce imagini mai mici, de calitate mai scăzută.
| Calea răspunsului | Reducere posibilă |
|---|---|
| Codare gzip | Fără pierderi; browserul decodează datele originale |
| Recomprimarea imaginilor | Poate elimina detalii și poate fi nepotrivită când imaginile exacte contează |
| Conținut deja comprimat eficient | Mai puțin spațiu pentru reducere suplimentară |
| HTTPS CONNECT obișnuit | TLS opac împiedică transformarea HTML sau a imaginilor fără o altă soluție de încredere pentru accesul la text clar |
Procesarea și saltul suplimentar consumă și ele timp, așa că mai puțini octeți nu garantează o finalizare mai rapidă. Cache-ul refolosește un răspuns stocat eligibil; compresia poate transforma un răspuns proaspăt obținut fără a-l stoca.
Unde conținutul HTTP este vizibil, respectați Cache-Control: no-transform. Politica de răspuns no-transform reglementează tratarea conformă a conținutului; este separată de criptarea transportului. Estimați beneficiile din conținutul real și calea de criptare, nu dintr-o demonstrație veche cu imagini în text clar.