Onde un proxy de compresión pode aforrar ancho de banda
Coloque a redución de contido antes da ligazón restrinxida do cliente e teña en conta a calidade das imaxes, a compresión existente e a visibilidade de HTTPS.
Coloque a redución de contido antes da ligazón restrinxida na ruta de resposta:
website → proxy transforms response → slow or metered link → browserSe o corpo completo xa cruzou esa ligazón, reducilo despois non recupera eses bytes. Un transformador remoto cunha ligazón ascendente máis rápida pode cumprir unha función distinta da dun proxy local xunto ao navegador.
Ziproxy ilustra o enfoque: o seu proxecto describe un proxy HTTP sen caché que comprime con gzip o contido de tipo texto e pode producir imaxes máis pequenas e de menor calidade.
| Ruta de resposta | Redución posible |
|---|---|
| Codificación gzip | Sen perda; o navegador descodifica os datos orixinais |
| Recompresión de imaxes | Pode descartar detalle e ser inadecuada cando as imaxes exactas importan |
| Contido xa comprimido eficientemente | Menos marxe para unha redución adicional |
| HTTPS CONNECT ordinario | O TLS opaco impide transformar HTML ou imaxes sen outro acordo de confianza para acceder ao texto simple |
O procesamento e o salto adicional tamén consomen tempo, así que menos bytes non garanten unha finalización máis rápida. A caché reutiliza unha resposta almacenada elixible; a compresión pode transformar unha resposta recentemente obtida sen almacenala.
Onde o contido HTTP é visible, respecte Cache-Control: no-transform. A política de resposta no-transform rexe o tratamento conforme do contido; é independente do cifrado de transporte. Estime os beneficios a partir do contido real e da ruta de cifrado, non dunha demostración antiga con imaxes en texto simple.