ZSTD vs Brotli vs GZIP: elegir la compresión de la API

Qué es la compresión de APIs (y cuándo merece la pena)

La compresión de respuestas de una API significa que tu servidor codifica el cuerpo de la respuesta (a menudo JSON) en un flujo de bytes más pequeño antes de enviarlo por la red. El cliente (navegador, app móvil, SDK u otro servicio) luego lo descomprime. Sobre HTTP, esto se negocia mediante encabezados como Accept-Encoding (qué soporta el cliente) y Content-Encoding (qué eligió el servidor).

Qué aporta a las APIs

La compresión te da principalmente tres cosas:

• Menos ancho de banda: respuestas más pequeñas consumen menos bytes en todo el trayecto.
• Menor latencia en enlaces restringidos: menos bytes suelen significar descargas más rápidas en móvil, Wi‑Fi congestionado y llamadas entre regiones.
• Menor coste de egreso: si pagas por datos salientes, reducir el tamaño de transferencia puede bajar facturas.

El intercambio es directo: la compresión ahorra ancho de banda pero cuesta CPU (comprimir/descomprimir) y a veces memoria (buffers). Si merece la pena depende de cuál sea tu cuello de botella.

Cuándo la compresión ayuda más

La compresión brilla cuando las respuestas son:

• Ricas en texto y repetitivas, como JSON, respuestas GraphQL, HTML o logs.
• Medianas a grandes, donde ahorrar decenas o cientos de KB importa.
• Servidas sobre redes lentas o caras, como clientes móviles, internacional o llamadas entre regiones.

Si devuelves grandes listas JSON (catálogos, resultados de búsqueda, analítica), la compresión suele ser una de las mejoras más sencillas.

Cuándo ayuda menos

La compresión suele ser un uso pobre de CPU cuando las respuestas son:

• Muy pequeñas (por ejemplo, unos cientos de bytes). El overhead de cabeceras y CPU puede superar el ahorro.
• Ya comprimidas (JPEG/PNG, MP4, ZIP, muchos PDFs). Recomprimir normalmente ofrece poco y puede incluso aumentar el tamaño.
• Servicios limitados por CPU (endpoints calientes ya con carga de compute). Añadir compresión puede aumentar la latencia en cola.

Las dimensiones de decisión que usarás en esta guía

Al elegir entre ZSTD vs Brotli vs GZIP para la compresión de APIs, la decisión práctica suele reducirse a:

1. Reducción de tamaño (ratio de compresión)
2. Latencia (tiempo del servidor hasta el primer byte más la descompresión en cliente)
3. Soporte en clientes (qué manejan tus llamantes e intermediarios)

Todo lo demás en este artículo trata de equilibrar esos tres factores para tu API y patrones de tráfico particulares.

ZSTD vs Brotli vs GZIP: Resumen rápido

Los tres reducen el tamaño del payload, pero optimizan para distintas restricciones: velocidad, ratio y compatibilidad.

Visión en una sola frase

• ZSTD (Zstandard): a menudo el mejor equilibrio para APIs cuando te importa baja latencia y CPU predecible. Buen ratio sin ser lento.
• Brotli: suele ganar en bytes mínimos en la red, especialmente para respuestas ricas en texto (JSON, HTML). Sus ajustes altos pueden costar más CPU.
• GZIP: la opción que “funciona en todas partes”. Muy soportado y fácil de operar, pero típicamente más lento y/o más grande que alternativas modernas con un presupuesto de CPU comparable.

Fortalezas típicas (y qué significan para APIs)

Velocidad de ZSTD: Excelente cuando tu API es sensible a la latencia en cola o tus servidores están limitados por CPU. Puede comprimir lo bastante rápido como para que el overhead sea despreciable frente al tiempo de red—sobre todo en respuestas JSON medianas a grandes.

Ratio de Brotli: Ideal cuando el ancho de banda es la principal limitación (clientes móviles, egreso caro, entrega vía CDN) y las respuestas son mayormente texto. Los payloads más pequeños a menudo justifican el coste extra de CPU.

Compatibilidad de GZIP: Mejor cuando necesitas soporte máximo de clientes sin riesgo de negociación (SDKs antiguos, clientes embebidos, proxies legacy). Es una base segura aunque no sea la mejor en rendimiento.

Qué cambia realmente un “nivel de compresión”

Los “niveles” de compresión son presets que intercambian tiempo de CPU por salida más pequeña:

• Niveles bajos: compresión más rápida, payloads más grandes. Buenos para APIs en tiempo real.
• Niveles altos: payloads más pequeños, compresión más lenta (y a veces más memoria). Mejores para respuestas grandes y cacheables.

La descompresión suele ser mucho más barata que la compresión en los tres, pero niveles muy altos pueden aumentar la CPU/batería del cliente—importante en móvil.

Regla empírica simple

• Elección por defecto: usa ZSTD para la mayoría de APIs JSON/REST/GraphQL donde la latencia importa.
• Cambia a Brotli: cuando optimizas por bytes mínimos (respuestas de texto, entrega CDN, redes lentas) y puedes permitir CPU extra.
• Mantén GZIP: cuando necesitas máxima compatibilidad o tu tooling no soporta códecs nuevos.

Ratio de compresión vs latencia: El intercambio central

La compresión suele venderse como “respuestas más pequeñas = APIs más rápidas”. Eso es frecuentemente cierto en redes lentas o caras—pero no es automático. Si la compresión añade suficiente tiempo de CPU, puedes acabar con peticiones más lentas pese a menos bytes en la red.

Dónde se va el tiempo

Conviene separar dos costes:

• Tiempo de compresión (lado servidor): trabajo antes de que el servidor pueda empezar a enviar bytes. Esto puede añadir directamente al tiempo de respuesta (TTFB).
• Tiempo de descompresión (lado cliente): trabajo tras recibir bytes. Normalmente más barato que la compresión, pero importante en dispositivos poco potentes o clientes de alto rendimiento.

Un alto ratio puede reducir el tiempo de transferencia, pero si la compresión añade (por ejemplo) 15–30 ms de CPU por respuesta, puede que pierdas más tiempo del que ahorras—especialmente en conexiones rápidas.

La trampa de la latencia en cola bajo carga

Bajo carga, la compresión puede perjudicar la latencia p95/p99 más que la p50. Cuando el uso de CPU sube, las peticiones se encolan. El encolamiento amplifica pequeños costes por petición en grandes retardos: la latencia media puede parecer bien, pero los usuarios más lentos sufren.

Mídelo como una característica de rendimiento

No adivines. Haz pruebas A/B o despliegues graduados y compara:

• p50 y p95 (y mejor aún p99) de latencia
• Uso y saturación de CPU en instancias API
• Tamaños de respuesta y tiempo hasta el primer byte

Prueba con patrones de tráfico y payloads realistas. El mejor nivel es el que reduce el tiempo total, no solo los bytes.

Costes de CPU y memoria en servidor y cliente

La compresión no es “gratis”—traslada trabajo de la red a CPU y memoria en ambos extremos. En APIs, eso se traduce en más tiempo de manejo de peticiones, mayor uso de memoria y a veces ralentización en clientes.

Dónde se consume la CPU

La mayor parte de la CPU se gasta en comprimir respuestas. La compresión identifica patrones, construye estados/diccionarios y escribe la salida codificada.

La descompresión suele ser más barata, pero sigue siendo relevante:

• Servidores pueden descomprimir requests (raro para JSON API, más común en uploads o lotes).
• Clientes descomprimen respuestas en la ruta crítica antes de parsear JSON.

Si tu API ya está limitada por CPU (servidores de aplicaciones ocupados, auth pesado, consultas costosas), activar un nivel alto de compresión puede aumentar la latencia en cola aunque los payloads sean más pequeños.

Consideraciones de memoria

La compresión puede aumentar el uso de memoria en varios aspectos:

• Buffers: las implementaciones pueden necesitar buffers de entrada/salida; payloads grandes significan buffers mayores.
• Buffering completo vs streaming: la compresión en streaming puede empezar a enviar antes y mantener la memoria más plana, mientras que el buffering completo puede inflar el pico por petición.

En entornos conteinerizados, picos de memoria mayores pueden traducirse en OOM kills o límites más estrictos que reduzcan densidad.

Impacto en autoscaling y límites de contenedores

La compresión añade ciclos de CPU por respuesta, reduciendo el throughput por instancia. Eso puede disparar el autoscaling antes y aumentar costes. Un patrón común: el ancho de banda baja, pero el gasto en CPU sube—la elección correcta depende de cuál recurso sea escaso para ti.

Por qué la velocidad de descompresión importa para clientes

En móvil o dispositivos de baja potencia, la descompresión compite con renderizado, ejecución de JavaScript y batería. Un formato que ahorre unos KB pero tarde más en descomprimirse puede sentirse más lento, particularmente cuando importa el “tiempo hasta datos utilizables”.

ZSTD para APIs: Fortalezas, límites y valores por defecto sensatos

Zstandard (ZSTD) es un formato moderno pensado para ofrecer buen ratio sin ralentizar tu API. Para muchas APIs con mucho JSON, es un fuerte “por defecto”: respuestas notoriamente más pequeñas que GZIP con latencia similar o menor, además de descompresión muy rápida en clientes.

Para qué es mejor ZSTD

ZSTD es más valioso cuando te importa el tiempo de extremo a extremo, no solo bytes mínimos. Suele comprimir rápido y descomprimir extremadamente rápido—útil en APIs donde cada milisegundo de CPU compite con el manejo de peticiones.

Funciona bien en una amplia gama de tamaños: JSON pequeño a mediano suele ver ganancias, y las respuestas grandes incluso más.

Niveles sensatos para APIs

Para la mayoría de APIs, empieza con niveles bajos (comúnmente 1–3). A menudo ofrecen el mejor equilibrio latencia/tamaño.

Usa niveles más altos solo cuando:

• Los payloads son grandes (centenas de KB a MB)
• El ancho de banda es caro o está restringido
• Has medido que la CPU no es el cuello de botella

Un enfoque pragmático: un valor bajo global, y aumentar selectivamente el nivel en endpoints con respuestas grandes.

Streaming y modo diccionario

ZSTD soporta streaming, lo que reduce la memoria pico y permite empezar a enviar antes para respuestas grandes.

El modo diccionario puede ser una gran mejora para APIs que devuelven muchos objetos similares (claves repetidas, esquemas estables). Es más efectivo cuando:

• Los payloads son relativamente pequeños pero frecuentes
• Puedes gestionar diccionarios versionados con seguridad

Límites de compatibilidad a vigilar

El soporte servidor es sencillo en muchas pilas, pero la compatibilidad cliente puede decidir la elección. Algunos clientes HTTP, proxies y gateways aún no anuncian o aceptan Content-Encoding: zstd por defecto.

Si sirves a consumidores terceros, mantén un fallback (normalmente GZIP) y habilita ZSTD solo cuando Accept-Encoding lo incluya claramente.

Brotli para APIs: cuándo gana y cuándo no

Brotli está diseñado para exprimir texto al máximo. En JSON, HTML y otros payloads “verbales”, suele superar a GZIP en ratio—especialmente con niveles altos.

Dónde gana Brotli

Las respuestas ricas en texto son el punto fuerte de Brotli. Si tu API envía JSON grandes (catálogos, resultados de búsqueda, blobs de configuración), Brotli puede reducir bytes notablemente, lo que ayuda en redes lentas y puede reducir costes de egreso.

Brotli también es fuerte cuando puedes comprimir una vez y servir muchas veces (respuestas cacheables, recursos versionados). En esos casos, Brotli a alto nivel suele merecer la pena porque el coste de CPU se amortiza.

Dónde decepciona Brotli

Para respuestas dinámicas (generadas por petición), los mejores ratios de Brotli suelen requerir niveles altos que son caros en CPU y añaden latencia. Contando el tiempo de compresión, la ganancia real frente a ZSTD (o incluso GZIP bien afinado) puede ser menor de lo esperado.

Tampoco resulta atractivo para payloads que no se comprimen bien (datos ya comprimidos, muchos binarios). Ahí solo consumes CPU.

Guía práctica de niveles

• Compresión en tiempo de ejecución: usa niveles bajos (comúnmente 1–4) para evitar picos de CPU.
• Precomprimido/estático: niveles más altos (a menudo 8–11) valen la pena cuando se amortizan sobre muchas peticiones.

Notas de soporte en clientes

Los navegadores suelen soportar bien Brotli sobre HTTPS, por eso es popular en tráfico web. Para clientes no navegador (SDKs móviles, IoT, stacks HTTP antiguos), el soporte puede ser inconsistente—negocia correctamente vía Accept-Encoding y mantén fallback (normalmente GZIP).

GZIP para APIs: compatibilidad y rendimiento práctico

GZIP sigue siendo la respuesta por defecto para compresión de APIs porque es la opción más universalmente soportada. Casi todo cliente HTTP, navegador, proxy y gateway entiende Content-Encoding: gzip, y esa predictibilidad importa cuando no controlas lo que hay entre tu servidor y los usuarios.

Por qué sigue siendo común

La ventaja no es que GZIP sea “el mejor”, sino que raramente es la elección equivocada. Muchas organizaciones tienen años de experiencia operando con él, defaults sensatos en servidores web y menos sorpresas con intermediarios que podrían manejar mal códecs nuevos.

Niveles prácticos para APIs

Para payloads de API (a menudo JSON), niveles medios a bajos suelen ser el punto óptimo. Niveles como 1–6 entregan la mayor parte de la reducción de tamaño manteniendo la CPU razonable.

Niveles muy altos (8–9) exprimen un poco más, pero el CPU adicional raramente compensa en tráfico dinámico donde la latencia importa.

Cómo se compara en CPUs modernas

En hardware moderno, GZIP suele ser más lento que ZSTD para ratios comparables, y a menudo no alcanza los mejores ratios de Brotli en texto. En cargas reales de API, eso normalmente significa:

• ZSTD frecuentemente gana en velocidad por byte ahorrado.
• Brotli puede ganar en tamaño para texto muy compresible, pero a coste de CPU según configuración.
• GZIP sigue siendo competitivo porque es “suficientemente rápido” y está muy optimizado.

Casos de compatibilidad extremos (clientes antiguos e intermediarios)

Si debes soportar clientes antiguos, dispositivos embebidos, proxies corporativos estrictos o gateways legacy, GZIP es la apuesta más segura. Algunos intermediarios pueden eliminar codificaciones desconocidas, no reenviarlas o romper la negociación—problemas menos comunes con GZIP.

Si tu entorno es mixto o incierto, empezar con GZIP (añadiendo ZSTD/Brotli solo donde controlas toda la ruta) suele ser la estrategia más fiable.

Tipos de payload: qué se comprime bien (y qué no)

Las ganancias de compresión no dependen solo del algoritmo; el mayor determinante es el tipo de datos que envías. Algunos payloads se reducen mucho con ZSTD, Brotli o GZIP; otros apenas cambian y solo consumen CPU.

Candidatos excelentes (alto retorno)

Las respuestas ricas en texto suelen comprimirse extremadamente bien por las claves repetidas, espacios y patrones predecibles.

• JSON (respuestas REST típicas)
• GraphQL (a menudo verborreico con nombres de campo repetidos)
• XML y HTML
• Logs y trazas de error en texto grandes

Como regla, cuanta más repetición y estructura, mejor el ratio.

Binarios: “quizá” (mide primero)

Formatos binarios como Protocol Buffers y MessagePack son más compactos que JSON, pero no son aleatorios. Pueden contener etiquetas repetidas, layouts de registro similares y secuencias predecibles.

Eso significa que con frecuencia son todavía comprimibles, especialmente en respuestas grandes o endpoints con listas. La única respuesta fiable es probar con tráfico real: mismo endpoint, mismos datos, compresión on/off y comparar tamaño y latencia.

Normalmente no vale la pena (ya comprimidos)

Muchos formatos ya usan compresión interna. Aplicar compresión HTTP encima suele aportar ahorros minúsculos y puede aumentar tiempos.

• Imágenes: JPEG, PNG, WebP
• Vídeo/audio: MP4 (y similares)
• Archivos: ZIP, gzip
• PDF: a menudo ya usa compresión

Para estos es común desactivar compresión por tipo de contenido.

Heurísticas prácticas (manténlo simple)

Un enfoque sencillo: comprimir solo si la respuesta supera un tamaño mínimo.

• Establece un umbral mínimo de respuesta (por ejemplo, unos pocos KB) antes de habilitar Content-Encoding.
• Siempre comprime respuestas de texto grandes; considera omitirlo para JSON pequeño donde las cabeceras dominan.

Esto mantiene la CPU enfocada en payloads donde la compresión realmente reduce ancho de banda y mejora el tiempo de extremo a extremo.

Encabezados HTTP y negociación: hacerlo bien

La compresión solo funciona suavemente cuando cliente y servidor acuerdan una codificación. Ese acuerdo sucede mediante Accept-Encoding (envíalo el cliente) y Content-Encoding (lo envía el servidor).

Accept-Encoding y Content-Encoding (ejemplos simples)

Un cliente anuncia lo que puede decodificar:

GET /v1/orders HTTP/1.1
Host: api.example
Accept-Encoding: zstd, br, gzip

El servidor elige uno y declara lo que usó:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: zstd

Si el cliente envía Accept-Encoding: gzip y respondes con Content-Encoding: br, ese cliente podría fallar al parsear el cuerpo. Si el cliente no envía Accept-Encoding, lo más seguro suele ser enviar sin compresión.

Orden de prioridad en el servidor

Un orden práctico para APIs suele ser:

• zstd primero (buen equilibrio velocidad/ratio)
• luego br (a menudo más pequeño, a veces más lento)
• luego gzip (máxima compatibilidad)

En otras palabras: zstd > br > gzip.

No lo trates como universal: si tu tráfico es mayormente navegadores, br puede merecer prioridad; si tienes clientes móviles antiguos, gzip puede ser la opción más segura.

Vary: Accept-Encoding y caching

Si una respuesta puede servirse en varias codificaciones, añade:

Vary: Accept-Encoding

Sin esto, un CDN o proxy podría cachear la variante gzip (o zstd) y servirla a un cliente que no pidió (o no puede manejar) esa codificación.

Casos límite y fallback seguros

Algunos clientes anuncian soporte pero tienen decodificadores defectuosos. Para ser resiliente:

• Prefiere un fallback conocido: si aumentan los errores de decodificación para zstd, cae temporalmente a gzip.
• Considera listas blancas por agentes problemáticos o versiones de SDK.
• Para endpoints críticos (auth, webhooks), considera desactivar compresión o usar solo la opción más compatible.

La negociación se trata menos de exprimir cada byte y más de no romper un cliente.

HTTP/2, HTTP/3, CDNs y gateways

La compresión de API no ocurre en el vacío. Tu protocolo de transporte, overhead TLS y cualquier CDN o gateway entre medias pueden cambiar el resultado real—o incluso romper cosas si hay mala configuración.

HTTP/2 y HTTP/3: multiplexación, head-of-line y qué cambia la compresión

Con HTTP/2, múltiples peticiones comparten una conexión TCP. Eso reduce overhead de conexión, pero la pérdida de paquetes puede bloquear todos los streams por head-of-line a nivel TCP. La compresión puede ayudar al reducir cuerpos de respuesta, disminuyendo la cantidad de datos “atascados” tras un evento de pérdida.

HTTP/3 usa QUIC (UDP) y evita el head-of-line a nivel TCP entre streams. El tamaño del payload sigue importando, pero la penalización por pérdida suele ser menor por conexión. En la práctica, la compresión sigue siendo valiosa—espera beneficios más en ahorro de ancho de banda y en “time to last byte” que en drops dramáticos de latencia.

TLS: no ignores el presupuesto de CPU

TLS ya consume CPU (handshakes, cifrado/descifrado). Añadir compresión (especialmente en niveles altos) puede llevarte por encima del límite de CPU en picos. Por eso las configuraciones de “compresión rápida con ratio decente” suelen superar a las de “ratio máximo” en producción.

CDNs y gateways: auto-comprimir, pasar o eliminar

Algunos CDNs/gateways comprimen automáticamente ciertos MIME types, otros pasan lo que origina el servidor. Algunos incluso normalizan o eliminan Content-Encoding si están mal configurados.

Verifica comportamiento por ruta y asegúrate de que Vary: Accept-Encoding se preserve para que las caches no sirvan una variante comprimida incorrectamente.

Estrategia de caching: edge vs origin (y múltiples variantes)

Si cacheas en el edge, considera almacenar variantes separadas por codificación (gzip/br/zstd) en lugar de recomprimir en cada hit. Si cacheas en el origen, quizá quieras que el edge negocie y cachee múltiples codificaciones.

La clave es consistencia: Content-Encoding correcto, Vary correcto y claridad sobre dónde ocurre la compresión.

Valores por defecto recomendados y playbook de afinado

Valores por defecto sugeridos según escenario

Para APIs orientadas a navegadores, prefiere Brotli cuando el cliente lo anuncia (Accept-Encoding: br). Los navegadores decodifican Brotli eficientemente y suele dar mejor reducción en texto.

Para APIs internas servicio-a-servicio, prefiere ZSTD cuando controlas ambos extremos. Suele ser más rápido a ratio similar que GZIP y la negociación es directa.

Para APIs públicas usadas por SDKs diversos, mantén GZIP como baseline universal y añade ZSTD opcionalmente para clientes que lo soporten explícitamente. Así evitas romper stacks HTTP antiguos.

Niveles conservadores de inicio

Empieza con niveles que sean fáciles de medir y poco propensos a sorpresas:

• Brotli: nivel 4–6 para respuestas dinámicas (niveles más altos pueden añadir CPU notable)
• ZSTD: nivel 3–5 para payloads de propósito general
• GZIP: nivel 5–6 (niveles más altos suelen dar retornos decrecientes)

Si necesitas mayor ratio, valida con muestras de payload en entorno parecido a producción y sigue p95/p99 antes de subir niveles.

Umbrales mínimos de tamaño (y afinado)

Comprimir respuestas diminutas puede costar más CPU que el ahorro en la red. Un punto de partida práctico:

• No comprimir por debajo de 1–2 KB para la mayoría de APIs
• Considera 4 KB si estás limitado por CPU o eres muy "talkative"

Ajusta comparando: (1) bytes ahorrados, (2) tiempo servidor añadido, (3) cambio en latencia end-to-end.

Formas seguras de exponer controles

Despliega la compresión detrás de un feature flag, luego añade config por ruta (habilitar para /v1/search, deshabilitar para endpoints ya pequeños). Proporciona una opt-out del cliente usando Accept-Encoding: identity para depuración y clientes en el edge. Siempre incluye Vary: Accept-Encoding para mantener caches correctas.

Dónde aparece esto en flujos modernos de build-and-ship

Si generas APIs rápidamente (por ejemplo, frontends React con backends Go + PostgreSQL y depuras con tráfico real), la compresión es uno de esos "pequeños ajustes con gran impacto". En Koder.ai, los equipos suelen llegar a este punto temprano porque prototipan y despliegan full‑stack rápido, y afinan comportamiento en producción (compresión, cache headers) una vez que los endpoints y shapes de payload se estabilizan. La conclusión práctica: trata la compresión como una característica de rendimiento, lánzala detrás de una flag y mide p95/p99 antes de darla por buena.

Despliegue, monitorización y resolución de problemas

Los cambios de compresión son fáciles de desplegar y sorprendentemente fáciles de romper. Trátalos como una característica de producción: despliega gradualmente, mide impacto y mantén rollback sencillo.

Plan de despliegue seguro

Empieza con un canary: habilita el nuevo Content-Encoding (por ejemplo, zstd) para una pequeña porción de tráfico o un solo cliente interno.

Luego rampa progresivamente (ej.: 1% → 5% → 25% → 50% → 100%), pausando si las métricas clave se mueven en la dirección equivocada.

Mantén una ruta de rollback rápida:

• Un feature flag en gateway/servicio para desactivar compresión (o caer a gzip).
• Una forma de excluir endpoints específicos (descargas de archivos, medios ya comprimidos).
• Un deploy de configuración rápido, no un deploy de código.

Qué monitorizar (y por qué)

Controla la compresión tanto como feature de rendimiento como de fiabilidad:

• CPU (servidor y, si puedes, cliente): niveles altos pueden disparar CPU.
• Percentiles de latencia (p50/p95/p99): la compresión suele ayudar la media pero puede perjudicar la cola.
• Tamaños de respuesta: bytes en la red por endpoint y delta comprimido vs sin comprimir.
• Tasas de error: vigila 4xx/5xx, errores de decodificación cliente y timeouts.

Checklist de resolución de problemas

Cuando algo falla, los culpables habituales son:

• Doble compresión: un servicio upstream comprime y luego el gateway comprime de nuevo.
• Cabeceras incorrectas: Content-Encoding indica compresión pero el cuerpo no lo está (o al revés).
• Negociación mala: ignorar Accept-Encoding o devolver una codificación no anunciada.
• Streams corruptos: cuerpos truncados, Content-Length incorrecto o interferencia de proxy/CDN.

Documentar expectativas para clientes

Explica en la documentación los códecs soportados, incluyendo ejemplos:

• Qué deben enviar los clientes: Accept-Encoding: zstd, br, gzip
• Qué recibirán: Content-Encoding: zstd (o fallback)

Si publicas SDKs, añade ejemplos copiable para decodificar y declara claramente las versiones mínimas que soportan Brotli o Zstandard.