Dónde un proxy de compresión puede ahorrar ancho de banda
Coloque la reducción de contenido antes del enlace restringido del cliente y tenga en cuenta la calidad de las imágenes, la compresión existente y la visibilidad de HTTPS.
Coloque la reducción de contenido antes del enlace restringido en la ruta de respuesta:
website → proxy transforms response → slow or metered link → browserSi el cuerpo completo ya cruzó ese enlace, reducirlo después no recupera esos bytes. Un transformador remoto con un enlace ascendente más rápido puede cumplir una función distinta de la de un proxy local junto al navegador.
Ziproxy ilustra el enfoque: su proyecto describe un proxy HTTP sin caché que comprime con gzip el contenido de tipo texto y puede producir imágenes más pequeñas y de menor calidad.
| Ruta de respuesta | Reducción posible |
|---|---|
| Codificación gzip | Sin pérdida; el navegador descodifica los datos originales |
| Recompresión de imágenes | Puede descartar detalle y ser inadecuada cuando las imágenes exactas importan |
| Contenido ya comprimido eficientemente | Menos margen para una reducción adicional |
| HTTPS CONNECT ordinario | El TLS opaco impide transformar HTML o imágenes sin otro acuerdo de confianza para acceder al texto plano |
El procesamiento y el salto adicional también consumen tiempo, así que menos bytes no garantizan una finalización más rápida. La caché reutiliza una respuesta almacenada elegible; la compresión puede transformar una respuesta recién obtenida sin almacenarla.
Donde el contenido HTTP es visible, respete Cache-Control: no-transform. La política de respuesta no-transform rige el tratamiento conforme del contenido; es independiente del cifrado de transporte. Estime los beneficios a partir del contenido real y de la ruta de cifrado, no de una demostración antigua con imágenes en texto plano.