Cómo hacer que el servidor envíe respuestas comprimidas: guía paso a paso para ahorrar tráfico

Una sola cabecera en una solicitud HTTP puede reducir el volumen de datos descargados varias veces. Hablamos de la negociación de compresión entre el cliente y el servidor. Si trabajas con proxies y pagas por cada gigabyte de tráfico, este tema afecta directamente tu factura. En esta guía veremos cómo hacer que el servidor envíe respuestas comprimidas, cómo medir el ahorro real en tu tarea y qué obstáculos te esperan.

Introducción: una sola cabecera puede reducir el tráfico varias veces

La compresión HTTP funciona de forma sorprendentemente simple. El cliente le dice al servidor qué algoritmos de compresión entiende. El servidor elige uno adecuado, comprime el cuerpo de la respuesta y lo envía. El cliente descomprime los datos en su lado. Como resultado, por la red no viaja el HTML o JSON original, sino su versión comprimida, que suele pesar de tres a cinco veces menos.

Qué obtendrás al final. Después de leer esta guía sabrás cómo activar la compresión en el lado del cliente, verificar si el servidor realmente envía una respuesta comprimida, medir el ahorro de tráfico en bytes antes y después, y diagnosticar situaciones donde la compresión no funciona por alguna razón. Todo esto es crítico cuando mueves tráfico a través del proxy Proxeon y pagas por gigabytes.

Para quién es esta guía. El material está dirigido a desarrolladores, especialistas en scraping, ingenieros de automatización y a todos los que escriben clientes para trabajar con HTTP a través de proxies. Nivel intermedio. No analizaremos en detalle de qué se compone el gasto de tráfico en general. Eso se aborda en un artículo aparte. Aquí nos centraremos estrictamente en la compresión.

Qué necesitas saber de antemano. Basta con comprender lo básico: qué es una solicitud y respuesta HTTP, qué son las cabeceras y cómo ejecutar un comando en la terminal. Si alguna vez hiciste una solicitud con curl o escribiste un script en Python o Node.js, podrás hacerlo sin problema.

Cuánto tiempo tomará. Leer y repetir todos los ejemplos tomará unos sesenta minutos. Verás los primeros resultados prácticos en solo diez minutos, cuando compares el tamaño de la respuesta comprimida y la no comprimida con tus propios ojos.

Preparación previa

Antes de comenzar, asegúrate de tener todo lo necesario. Esto te ahorrará tiempo y evitará errores a mitad del camino.

Herramientas necesarias

• curl versión 7.72 o posterior. En las compilaciones de 2026, brotli y zstd se admiten de serie en la mayoría de los sistemas.
• Python versión 3.10 o posterior con la librería requests instalada, y para brotli adicionalmente el paquete brotli o brotlicffi.
• Node.js versión 18 o posterior. El módulo zlib está integrado y admite gzip, deflate y brotli.
• Acceso al proxy Proxeon, si quieres medir el ahorro exactamente en las condiciones en las que trabajas a diario.
• Cualquier editor de texto para escribir scripts.

Requisitos del sistema

Funcionará en cualquier sistema moderno: Windows, macOS o Linux. Todos los ejemplos son multiplataforma. Con dos gigabytes de RAM será suficiente. No hay requisitos especiales de procesador, aunque al comprimir grandes volúmenes, el algoritmo brotli en su nivel máximo puede cargar notablemente un núcleo.

Qué instalar y verificar

1. Abre la terminal y ejecuta el comando para verificar la versión de curl:

   curl --version

2. Mira la primera línea de la salida. Allí se indica la versión. Asegúrate de que en la lista de características aparezca brotli y, si es posible, zstd.
3. Verifica Python con el comando

   python --version

   e instala las dependencias:

   pip install requests brotli

4. Verifica Node.js con el comando

   node --version

Consejo: Si curl en tu sistema se compiló sin brotli, instálalo a través del gestor de paquetes oficial de tu sistema operativo. En las compilaciones corporativas de 2026, brotli casi siempre está incluido por defecto.

Copias de seguridad. En esta guía no modificamos la configuración de servidores en producción ni tocamos datos de trabajo. Solo enviamos solicitudes y medimos respuestas. Por lo tanto, no se necesitan copias de seguridad. Sin embargo, si más adelante decides activar la compresión en tu propio servidor web, asegúrate de guardar el archivo de configuración original antes de editarlo.

✅ Verificación: Las tres herramientas responden al comando de verificación de versión y muestran un número. Eso significa que la preparación está completa y puedes continuar.

Conceptos básicos en términos sencillos

Antes de pulsar botones, aclaremos los términos. Esto tomará cinco minutos, pero evitará confusiones más adelante.

Cómo funciona la negociación de compresión

La compresión HTTP se basa en tres cabeceras. Comprender su papel resuelve la mayoría de los problemas.

Accept-Encoding en el cliente. Esta es la cabecera que envía tu cliente junto con la solicitud. En ella se enumeran los algoritmos de compresión que el cliente sabe descomprimir. Por ejemplo, la cadena

Accept-Encoding: gzip, br, zstd

Content-Encoding en la respuesta. Es la cabecera que el servidor añade a su respuesta. Indica con qué algoritmo se comprimió el cuerpo. Si ves

Content-Encoding: br

Vary en el servidor. La cabecera Vary les dice a los cachés y proxies que la respuesta depende de ciertas cabeceras de la solicitud. Para la compresión es crítico el valor

Vary: Accept-Encoding

La idea clave de la negociación

Recuerda la secuencia. El cliente pide mediante Accept-Encoding. El servidor decide y responde mediante Content-Encoding. Los intermediarios se guían por Vary. Si se rompe al menos un eslabón de esta cadena, recibirás una respuesta sin comprimir y pagarás de más por el tráfico.

Consejo: Incluso si tu librería HTTP añade Accept-Encoding automáticamente, siempre verifica la cabecera real de la respuesta. La automatización a veces calla, pero el tráfico se va.

gzip, deflate, brotli, zstd: comparación de algoritmos

Existen cuatro algoritmos de compresión comunes para HTTP. Se diferencian en el grado de compresión y la carga sobre el procesador. Analicemos cada uno y resumamos los números en una tabla.

gzip

El más antiguo y universal. Se admite en todas partes: cualquier servidor, cualquier cliente, cualquier proxy. Ofrece un buen grado de compresión en datos de texto con una carga moderada. Si dudas sobre qué elegir, empieza con gzip.

deflate

Pariente cercano de gzip, usa el mismo algoritmo internamente pero con una envoltura diferente. En la práctica se encuentra con menos frecuencia y a veces está implementado con errores en algunos servidores. El grado de compresión es similar al de gzip. No hay razones especiales para elegir deflate en lugar de gzip.

brotli

Algoritmo moderno diseñado específicamente para la web. En datos de texto comprime notablemente mejor que gzip, especialmente en HTML, CSS y JSON. El costo es una mayor carga en el procesador al comprimir en los niveles máximos. La descompresión es rápida. Se indica en las cabeceras como br.

zstd

Algoritmo moderno rápido con configuración flexible de niveles. Ofrece un grado de compresión similar al de brotli, pero es más rápido en velocidad de compresión. El soporte en la web crece y para 2026 la mayoría de los servidores y clientes actuales lo entienden. Se indica como zstd.

Tabla comparativa en una respuesta de texto típica

Tomemos una respuesta JSON de 1000 kilobytes sin comprimir. Las cifras son aproximadas y dependen del contenido, pero el orden de magnitud es correcto.

• Sin compresión: 1000 KB, ahorro del 0 por ciento, carga mínima en el procesador.
• gzip nivel 6: alrededor de 190 KB, ahorro aproximado del 81 por ciento, carga baja.
• deflate nivel 6: alrededor de 195 KB, ahorro aproximado del 80 por ciento, carga baja.
• brotli nivel 5: alrededor de 165 KB, ahorro aproximado del 83 por ciento, carga media.
• brotli nivel 11: alrededor de 140 KB, ahorro aproximado del 86 por ciento, carga alta.
• zstd nivel 3: alrededor de 175 KB, ahorro aproximado del 82 por ciento, carga baja.
• zstd nivel 19: alrededor de 150 KB, ahorro aproximado del 85 por ciento, carga media.

La conclusión es simple. En datos de texto, cualquier compresión reduce el tráfico aproximadamente cinco veces. La diferencia entre algoritmos está dentro de unos pocos puntos porcentuales. Por lo tanto, para ahorrar tráfico a través de un proxy lo importante no es qué algoritmo, sino el hecho mismo de que la compresión esté activada.

Consejo: Si solo descargas datos y no los envías, la carga en tu procesador es solo por la descompresión, y esta es rápida en todos los algoritmos. Por lo tanto, puedes pedir con confianza la opción que ofrezca el mayor grado de compresión.

✅ Verificación: Entiendes que brotli y zstd suelen ser ligeramente más eficientes que gzip en texto, pero gzip es el más compatible. Esto es suficiente para la práctica.

Paso 1: Enviamos una solicitud y vemos si la respuesta se comprime

Objetivo de esta etapa. Aprender a ver las cabeceras Content-Encoding y el tamaño real del cuerpo. Sin esto es imposible medir el ahorro.

Verificación con curl

1. Abre la terminal.
2. Primero, solicita el recurso sin compresión para conocer el tamaño original. Ejecuta:

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. Anota el número. Es el tamaño de la respuesta sin comprimir en bytes.
4. Ahora pide compresión. La bandera --compressed añade automáticamente Accept-Encoding y descomprime la respuesta:

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. Compara los dos números. El segundo debería ser notablemente menor con el mismo contenido.

Importante: El indicador size_download en curl con --compressed refleja el tamaño de los datos ya descomprimidos, no lo que viajó por la red. Para ver el volumen real de red, usa la cabecera de respuesta y mediciones intermedias, de las que hablaremos en el paso de medición.

Vemos las cabeceras de la respuesta

1. Ejecuta una solicitud con la bandera para mostrar cabeceras:

   curl -s -I --compressed https://example.com/api/data

2. Busca en la salida la línea Content-Encoding. Si dice gzip, br o zstd, el servidor envió una respuesta comprimida.
3. Busca la línea Vary. Que aparezca Accept-Encoding en ella significa una configuración correcta del caché.

Consejo: Para indicar explícitamente el algoritmo deseado, añade la cabecera manualmente:

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

Trabajo a través del proxy Proxeon

Para medir el ahorro en condiciones reales, envía la solicitud a través del proxy. En curl esto se hace con la bandera -x:

curl -s --compressed -x http://usuario:contraseña@dirección_proxeon:puerto -o /dev/null -w "%{size_download}" https://example.com/api/data

Así verás si la compresión llega a través del proxy y si algo elimina cabeceras en el camino.

Resultado esperado. Ves dos números: el tamaño sin compresión y el tamaño con compresión. Y ves la cabecera Content-Encoding en la respuesta. Esto significa que el mecanismo funciona.

Posible problema: si ambos números son iguales y falta Content-Encoding, el servidor no envió compresión. Las causas se analizan en una sección aparte.

✅ Verificación: En la respuesta con la bandera --compressed aparece la línea Content-Encoding con uno de los algoritmos. Eso significa que el paso se completó.

Paso 2: Medimos el ahorro real en Python

Objetivo de esta etapa. Obtener cifras precisas del tráfico de red antes y después de la compresión con un script funcional que puedas aplicar a tu tarea.

Medición simple con requests

La librería requests por defecto añade Accept-Encoding y descomprime la respuesta. Para medir el tamaño real en la red, observaremos la longitud del contenido crudo antes de descomprimir.

1. Crea el archivo measure.py.
2. Pega el siguiente código:

import requests
url = "https://example.com/api/data"
# Solicitud sin compresión
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# Solicitud con compresión
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "ninguno")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("Sin compresión, bytes:", size_plain)
print("Algoritmo de compresión:", encoding)
print("Por red aproximadamente, bytes:", size_wire)
print("Después de descomprimir, bytes:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("Ahorro de tráfico, por ciento:", saved)

Atención: El valor Content-Length no siempre está presente, especialmente con transferencia en chunks. Si falta, usa el método más preciso a continuación.

Medición precisa del volumen de red

Para medir exactamente lo que viajó por la red, desactiva la descompresión automática y cuenta los bytes del flujo crudo.

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# Desactivamos la descompresión automática para ver el tamaño crudo
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("Algoritmo:", r.headers.get("Content-Encoding", "ninguno"))
print("Bytes crudos por red:", raw_bytes)

Compara raw_bytes con el tamaño de la solicitud sin comprimir. La diferencia es tu ahorro real.

Medición a través del proxy Proxeon

Añade el parámetro proxies para obtener las cifras en condiciones reales:

proxies = {
"http": "http://usuario:contraseña@dirección_proxeon:puerto",
"https": "http://usuario:contraseña@dirección_proxeon:puerto",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

Consejo: Ejecuta la medición varias veces y calcula el promedio. Las respuestas dinámicas cambian de tamaño, por lo que una sola medición puede ser engañosa.

Resultado esperado. El script imprime el algoritmo de compresión y el número de bytes crudos, que es menor que el tamaño de la respuesta sin comprimir. Si el ahorro fue del setenta por ciento o más en un recurso de texto, todo funciona correctamente.

✅ Verificación: En la salida, el algoritmo no es igual a la palabra ninguno y los bytes crudos son menores que sin compresión. Excelente.

Paso 3: La misma medición en Node.js

Objetivo de esta etapa. Obtener una herramienta de medición funcional en JavaScript para quienes escriben clientes en Node.

Medición del flujo crudo

1. Crea el archivo measure.js.
2. Pega el código que cuenta los bytes antes de descomprimir:

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'ninguno', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('Sin compresión, bytes:', plain.bytes);
 console.log('Algoritmo:', comp.enc);
 console.log('Comprimido por red, bytes:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('Ahorro, por ciento:', saved);
})();

Importante: En este ejemplo leemos el flujo crudo de res y no conectamos zlib. Por lo tanto, el contador bytes muestra exactamente el volumen de red. Es justo lo que pagas al proveedor del proxy.

Descompresión manual en Node

Si además necesitas leer el contenido, descomprime el flujo con el módulo integrado zlib:

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

Consejo: Para zstd en versiones recientes de Node.js existe zlib.createZstdDecompress. Si tu versión no lo incluye, actualiza Node o usa un paquete npm independiente.

Resultado esperado. Node imprime un ahorro en porcentaje comparable al que obtuviste en Python y curl.

✅ Verificación: Las tres herramientas dan cifras de ahorro similares. Eso significa que tus mediciones son confiables.

Paso 4: Por qué la respuesta llega sin comprimir

Objetivo de esta etapa. Aprender a diagnosticar por qué la compresión no funcionó y solucionar la causa. Este es el problema más común en la práctica.

Primer caso: el cliente no pidió

La causa más común. Tu cliente HTTP no envió la cabecera Accept-Encoding y el servidor honestamente devolvió una respuesta sin comprimir. Esto ocurre cuando formas las cabeceras manualmente y olvidas la compresión, o cuando usas un socket de bajo nivel.

1. Verifica qué se envía exactamente al servidor. En curl añade la bandera -v y busca la línea con Accept-Encoding en las cabeceras salientes.
2. Si la línea no está, añádela explícitamente con -H o con la bandera --compressed.
3. En Python, asegúrate de no haber sobrescrito la cabecera con un valor vacío.

Atención: Algunas librerías, cuando se establece manualmente cualquier cabecera, dejan de añadir sus valores por defecto. Si configuras User-Agent a mano, verifica que Accept-Encoding no haya desaparecido de paso.

Segundo caso: el servidor no sabe

El servidor puede no admitir la compresión en absoluto, o no admitir el algoritmo solicitado. Entonces devuelve una respuesta sin comprimir, lo cual es aceptable según el estándar.

1. Pide diferentes algoritmos por turno: primero gzip, luego br, luego zstd.
2. Observa con cuál aparece Content-Encoding en la respuesta.
3. Si no aparece con ninguno, el servidor no entrega compresión. En un servidor ajeno no puedes cambiarlo, pero puedes elegir otro endpoint o API si existe.

Consejo: Muchas APIs solo envían compresión para respuestas superiores a cierto tamaño. Las respuestas pequeñas a menudo se dejan sin comprimir a propósito, porque la sobrecarga de compresión supera el beneficio.

Tercer caso: un intermediario eliminó la cabecera

Entre tú y el servidor puede haber un nodo de caché, una puerta de enlace o un proxy que elimina o modifica las cabeceras de compresión. A veces el intermediario descomprime la respuesta para sus propios fines y te entrega la versión ya descomprimida.

1. Haz una solicitud directa y otra a través del proxy y compara las cabeceras Content-Encoding.
2. Si la compresión existe directamente pero no a través del intermediario, este está interfiriendo.
3. Al trabajar con el proxy Proxeon, la compresión se transmite de forma transparente, así que si ves una diferencia, busca el problema en el servidor de destino o su CDN.

Resultado esperado. Sabes exactamente en cuál de los tres eslabones se pierde la compresión y entiendes qué hacer al respecto.

✅ Verificación: Puedes explicar en una frase por qué una respuesta concreta llegó sin comprimir. Diagnóstico dominado.

Paso 5: Errores sutiles al trabajar con compresión

Objetivo de esta etapa. Evitar errores finos que rompen los datos o distorsionan las mediciones.

Doble compresión

A veces el contenido ya está comprimido a nivel de aplicación y el servidor lo comprime de nuevo. O al revés: tú comprimes el cuerpo de la solicitud y el proxy o la librería lo vuelven a comprimir. La doble compresión casi no da beneficio y a veces incluso aumenta el tamaño y desperdicia tiempo de procesador.

1. Verifica si no hay dos valores en Content-Encoding en la respuesta, por ejemplo, gzip dentro de br.
2. No comprimas manualmente lo que la librería ya comprimirá automáticamente.
3. Si ves una cadena de codificaciones, descomprímela en orden inverso.

Flujo dañado

Una interrupción de la conexión o un error del intermediario puede hacer que el flujo comprimido llegue incompleto. Al descomprimir, obtendrás un error o datos truncados.

1. Siempre envuelve la descompresión en un manejo de errores.
2. Ante un error de descompresión, repite la solicitud en lugar de intentar leer datos corruptos.
3. Compara el tamaño real con Content-Length, si está indicado.

Atención: Nunca guardes datos parcialmente descomprimidos como resultado. Un JSON corrupto parece plausible, pero provocará errores ocultos más adelante en el proceso.

Descompresión manual cuando la librería no lo hace

Si desactivaste la descompresión automática para medir con precisión o usas un cliente de bajo nivel, tendrás que descomprimir manualmente. Ejemplo en Python:

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

Consejo: Si la descompresión deflate falla, prueba llamar a zlib.decompress con el parámetro wbits igual a menos quince. Algunos servidores envían deflate crudo sin la envoltura de zlib.

Resultado esperado. Sabes descomprimir manualmente cualquiera de los formatos admitidos y gestionas correctamente los errores de flujo.

✅ Verificación: Tu script no se detiene ante una respuesta corrupta, sino que repite la solicitud. Resiliencia lograda.

Paso 6: Qué no tiene sentido comprimir

Objetivo de esta etapa. No desperdiciar procesador ni tiempo comprimiendo lo que ya está comprimido. Esto ahorra recursos sin perder beneficio en tráfico.

Formatos ya comprimidos

Algunos datos se almacenan en formatos que internamente ya usan compresión. Intentar comprimirlos de nuevo no tiene sentido: el beneficio será de fracciones de punto porcentual y el procesador se cargará en vano.

• Imágenes: JPEG, PNG, WebP, AVIF ya están comprimidos internamente en su propio formato.
• Video: MP4, WebM, MKV contienen un flujo de video fuertemente comprimido.
• Audio: MP3, AAC, OGG están comprimidos por naturaleza.
• Archivos: ZIP, RAR, 7z, gz ya son contenedores comprimidos.

Para estos recursos, Accept-Encoding no dará ahorro en el cuerpo. Además, el servidor normalmente tampoco los comprime de nuevo, porque está configurado por lista de tipos MIME.

Qué tiene sentido comprimir

• HTML, CSS, JavaScript.
• Respuestas JSON y XML de APIs.
• Texto plano, CSV, registros.
• SVG, porque en esencia es texto.

Consejo: Si principalmente descargas archivos multimedia, el ahorro por compresión será casi nulo. Aquí el beneficio viene de otra parte: solicitar solo los tamaños y formatos necesarios, no del hecho de la compresión. Pero ese es un tema de gestión de tráfico, no de compresión en sí.

Resultado esperado. No gastas recursos comprimiendo formatos binarios y aplicas la compresión solo donde realmente ayuda.

✅ Verificación: Puedes decir en un segundo si vale la pena comprimir un tipo específico de respuesta. Comprensión lograda.

Verificación del resultado

Es hora de asegurarse de que todo está configurado correctamente. Recorre la lista de verificación.

Lista de verificación de funcionamiento

1. Tu cliente envía la cabecera Accept-Encoding con los algoritmos deseados.
2. En la respuesta aparece Content-Encoding con uno de esos algoritmos en recursos de texto.
3. El script de medición muestra un volumen de red menor que el sin comprimir, al menos en un setenta por ciento para texto.
4. A través del proxy Proxeon la compresión se conserva y las cifras coinciden con la solicitud directa.
5. La descompresión no da errores y los datos se leen correctamente.
6. No intentas comprimir formatos binarios.

Cómo probar

1. Toma tres endpoints diferentes: uno con JSON, uno con HTML y uno con una imagen.
2. Ejecuta cada uno con tu script de medición.
3. Confirma que en los dos primeros el ahorro es alto y en el tercero casi nulo.

Indicadores de éxito. Para una API de texto ves consistentemente un ahorro en el rango del setenta al noventa por ciento. Para medios, el ahorro es mínimo, y eso es normal. A través del proxy las cifras no empeoran.

✅ Verificación: Los seis puntos de la lista están cumplidos. La compresión está configurada y medida correctamente.

Errores típicos y soluciones

A continuación, se recogen problemas frecuentes en formato problema, causa, solución.

La respuesta no se comprime aunque Accept-Encoding se envió

Causa: el servidor no admite compresión para ese tipo de contenido o para respuestas de ese tamaño. Solución: prueba otro algoritmo y asegúrate de que el recurso sea de texto y lo suficientemente grande.

El ahorro no se ve en curl, size_download no cambia

Causa: la bandera --compressed muestra el tamaño después de descomprimir. Solución: mide el volumen de red con un script aparte sin descompresión automática, como en los pasos de Python y Node.

La librería devuelve basura en lugar de texto

Causa: desactivaste la descompresión automática, pero no descomprimiste el flujo manualmente. Solución: determina Content-Encoding y aplica la función de descompresión correspondiente.

Error al descomprimir deflate

Causa: el servidor envió deflate crudo sin envoltura. Solución: llama a la descompresión con el parámetro wbits igual a menos quince.

A través del proxy la compresión desaparece

Causa: hay un nodo en el camino que modifica cabeceras, generalmente el CDN del sitio de destino. Solución: compara la solicitud directa y la proxied y determina el eslabón. El proxy Proxeon transmite las cabeceras de forma transparente, por lo que el problema suele estar en el servidor.

Tamaño de respuesta diferente en mediciones repetidas

Causa: el contenido es dinámico y cambia de una solicitud a otra. Solución: promedia varias mediciones y compara con los mismos parámetros de solicitud.

Falta Content-Length

Causa: la transferencia en chunks no indica la longitud de antemano. Solución: cuenta los bytes manualmente mientras lees el flujo, como en los ejemplos de scripts.

La doble compresión infla el procesador

Causa: el contenido se comprime dos veces en diferentes niveles. Solución: elimina la compresión manual donde la librería o el servidor ya la hacen.

Oportunidades adicionales

Cuando domines el escenario básico, hay margen para avanzar.

Elección de prioridad de algoritmos

En la cabecera Accept-Encoding se puede indicar el peso con valores q, sugiriendo al servidor preferencias. Por ejemplo

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

Caché de datos descomprimidos

Si accedes repetidamente al mismo recurso, almacena en caché el resultado descomprimido en tu lado. Esto reduce tanto el tráfico como la carga del procesador por descompresión repetida.

Medición masiva por lista de URL

Envuelve el script de medición en un bucle sobre una lista de endpoints y recopila una tabla de ahorro. Así encontrarás las respuestas sin comprimir más pesadas en tu proyecto y te ocuparás primero de ellas.

Consejo: Lleva un registro del ahorro en bytes por día. Multiplicado por el precio del gigabyte, obtendrás una cifra clara del beneficio económico de tener la compresión activada al trabajar a través de un proxy.

✅ Verificación: Puedes recopilar una tabla resumen de ahorro en varios recursos con una sola ejecución del script.

Preguntas frecuentes

¿Debo pedir siempre brotli en lugar de gzip?

Si solo descargas, la descompresión es rápida en todos los algoritmos, así que puedes pedir el más eficiente. En la práctica, indica los tres en Accept-Encoding: gzip, br, zstd. El servidor elegirá el mejor disponible.

¿Cuánto tráfico ahorra la compresión en una API de texto?

Normalmente del setenta al noventa por ciento. Es decir, una respuesta que pesaba un gigabyte viajará por la red como ciento cincuenta o doscientos megabytes. El ahorro al pagar por gigabytes es directo y notable.

¿Influye la compresión en la velocidad de respuesta?

Un menor volumen de datos se transmite más rápido, especialmente en canales lentos. El pequeño retraso por la compresión en el servidor generalmente se compensa con creces por la reducción del tiempo de transferencia.

¿Por qué curl muestra el mismo tamaño con y sin la bandera de compresión?

Porque --compressed muestra el tamaño del cuerpo ya descomprimido. El volumen real de red es menor. Mide el flujo crudo con un script aparte.

¿Se puede comprimir el cuerpo de una solicitud POST?

Sí, para eso el cliente coloca Content-Encoding en la solicitud, pero el servidor debe poder descomprimirlo. No todos los servidores lo admiten, así que verifica la documentación de la API.

¿Funciona la compresión a través del proxy Proxeon?

Sí. El proxy transmite las cabeceras Accept-Encoding y Content-Encoding de forma transparente, por lo que todo el ahorro se conserva. Por eso conviene medir directamente a través del proxy, en condiciones reales.

¿Qué hago si el servidor no envía compresión?

Asegúrate de que estás pidiendo compresión y que el recurso es de texto. Si el servidor sigue sin responder, no puedes cambiar un servidor ajeno, pero puedes elegir otro endpoint o comprimir los datos en tu capa de caché.

¿Vale la pena comprimir imágenes con Accept-Encoding?

No. Formatos como JPEG y WebP ya están comprimidos. La compresión adicional no dará beneficio y solo cargará el procesador.

¿Cómo elegir entre zstd y brotli?

Para descargas, la diferencia en tráfico es de unos pocos puntos porcentuales. Indica ambos en Accept-Encoding y deja que el servidor decida. Si el servidor solo admite uno, recibirás precisamente ese.

¿Necesito Vary al trabajar del lado del cliente?

Como cliente no estableces Vary, lo hace el servidor. Pero entenderlo es útil: explica por qué el caché a veces devuelve una versión comprimida y otras una sin comprimir.

Conclusión

Recorriste el camino desde la teoría hasta las mediciones prácticas. Ahora entiendes cómo se negocia la compresión mediante Accept-Encoding, Content-Encoding y Vary. Sabes pedir compresión en curl, Python y Node.js y, lo más importante, medir el volumen real de red antes y después. Conoces por qué a veces la respuesta llega sin comprimir y cómo diagnosticarlo según tres causas típicas. Dominaste los errores sutiles: doble compresión, flujo dañado y descompresión manual. Y ya no desperdicias recursos comprimiendo imágenes, videos y archivos.

Qué hacer ahora. Ejecuta el script de medición en todos los endpoints principales de tu proyecto. Encuentra aquellos donde la compresión no está activada y pídela explícitamente. Lleva un registro de los bytes ahorrados para ver el beneficio económico al trabajar con el proxy Proxeon. Cuando domines el escenario básico, pasa a la medición masiva por lista de URL y a las prioridades de algoritmos con valores q.

La compresión es una de las formas más baratas de reducir tu factura de tráfico. Una sola cabecera enviada correctamente puede reducir el volumen de datos varias veces. Ahora tienes esta herramienta en tus manos y puedes aplicarla con conciencia y con cifras exactas.