Cloudflare prueba compresión de caché con Zstandard

En pocas palabras: Cloudflare probó Cache Transcoding, un prototipo que comprime con Zstandard sobre su proxy Pingora el contenido de texto sin comprimir (HTML, JSON, CSS, JavaScript) de al menos 4 KiB, logrando reducir su tamaño unas 2.8 veces y liberando así espacio de almacenamiento en sus servidores de caché.

Cloudflare probó un prototipo llamado Cache Transcoding que comprime contenido de caché elegible (HTML, JSON, CSS y JavaScript sin comprimir) usando Zstandard antes de guardarlo en disco. Según el reporte de InfoQ publicado el 13 de septiembre de 2026, la compresión redujo el tamaño del contenido elegible unas 2.8 veces.

La idea de fondo no es nueva (comprimir texto antes de guardarlo siempre ahorra espacio), pero la escala de Cloudflare cambia la ecuación: un ahorro de 2.8x aplicado a petabytes de caché distribuido en cientos de data centers no es lo mismo que aplicarlo en un servidor propio. Por eso vale la pena mirar tanto el mecanismo técnico como los criterios que Cloudflare usó para decidir qué comprimir y qué no, porque esos criterios sí son trasladables a infraestructura más chica.

¿Qué contenido comprime Cache Transcoding y cuáles quedan excluidos?

Cache Transcoding solo comprime respuestas que cumplen tres condiciones a la vez: son texto sin comprimir, retornan de forma exitosa y pesan al menos 4 KiB. Todo lo demás queda afuera del proceso, sin excepción.

Cloudflare excluye range requests, contenido que ya llega precomprimido o binario, y respuestas de tamaño desconocido. El umbral de 4 KiB evita procesar montañas de objetos chiquitos que no justifican el costo de CPU. Según Aashi Patel en el blog oficial de Cloudflare, ese recorte sacrifica apenas un 1% de los datos elegibles. Tanto el umbral como el nivel de compresión de Zstandard son ajustables según la relación entre CPU disponible y espacio de almacenamiento que Cloudflare quiera priorizar.

¿Cómo funciona técnicamente la compresión con Zstandard y Pingora?

El contenido se comprime una sola vez cuando entra al caché y se descomprime cada vez que se sirve. Cloudflare usa Zstandard, el algoritmo de compresión sin pérdida que desarrolló Facebook para uso en tiempo real, corriendo sobre Pingora, el framework de proxy en Rust que la propia Cloudflare construyó.

Patel lo resume así: “A small increase in CPU gives Cloudflare petabytes of effective cache capacity and reduces the data transferred between our data centers. The encoding cost is paid once when an asset enters the cache. The storage and bandwidth savings continue every single time that asset is reused” (traducción: un pequeño aumento de CPU le da a Cloudflare petabytes de capacidad de caché efectiva y reduce los datos transferidos entre data centers; el costo de codificación se paga una vez, y el ahorro de almacenamiento y ancho de banda se repite cada vez que ese activo se reutiliza).

El detalle que explica por qué esto funciona a favor de Cloudflare y no siempre a favor de un servidor chico es la frecuencia de reuso. Si un objeto se sirve miles de veces desde el mismo nodo de caché, el costo de comprimirlo una vez se diluye rápido. Si un objeto casi no se vuelve a pedir, ese mismo costo de CPU se paga sin sacarle provecho después, lo que conecta con la crítica de MayeulC que se ve más abajo.

¿Cuánto espacio de almacenamiento ahorra Cloudflare Cache Transcoding?

La compresión redujo el tamaño del contenido elegible unas 2.8 veces, según los datos que Cloudflare publicó en su blog. Con esa relación, la compañía estima que podría ganar petabytes de capacidad de caché efectiva adicional en su infraestructura actual, sin sumar servidores nuevos.

Los números de tráfico ayudan a entender la escala del problema. El contenido comprimible (HTML, JSON, CSS, JavaScript) representó 67.3% de los requests pero solo 22.3% de los bytes totales en la muestra que analizó Cloudflare. De ese contenido, cerca del 71% llegaba sin comprimir, es decir, con margen real para aplicar Zstandard.

Ejemplo hipotético para dimensionarlo: pensemos en un caché que almacena 100 TB de HTML y JSON sin comprimir. Si se aplicara una reducción de 2.8x como la que reporta Cloudflare, ese mismo contenido ocuparía cerca de 36 TB, liberando unos 64 TB en los mismos discos. Este número es solo ilustrativo (no proviene de una medición real) y sirve únicamente para visualizar el orden de magnitud del ahorro que describe la fuente, no como una proyección para un caso concreto.

¿Por qué Cloudflare no comprime imágenes, video ni fuentes?

Porque ese contenido ya suele venir comprimido de origen, y comprimirlo de nuevo gasta CPU sin devolver casi nada a cambio. Patel lo dice sin vueltas: “Transcoding does not mean compressing everything. Images, video, and fonts are usually compressed already.”

En la muestra de tráfico de Cloudflare, la porción de medios (imágenes, video, fuentes) representó 21.4% de los requests pero 63.3% de los bytes transferidos. Es la mayor parte del peso, pero aplicarle Zstandard encima de un JPEG o un MP4 ya comprimido “would burn CPU for nothing” (quemaría CPU para nada), en palabras de Patel. Comprimir dos veces algo que ya está en un formato eficiente casi no reduce el tamaño y sí consume ciclos de procesador.

¿Qué dudas y críticas generó Cache Transcoding en la comunidad técnica?

El debate en Hacker News se centró en dos puntos: la precisión del término “transcoding” y la lógica detrás de qué contenido priorizar. Algunos practicantes cuestionan que Cloudflare llame “transcoding” a lo que en rigor es un esquema de encode/decode con compresión, no una conversión de formato en el sentido clásico (pensá en convertir un video de un códec a otro).

El usuario MayeulC planteó una objeción sobre la estrategia de priorización: “Weird, I would have compressed cold content instead, if the goal was to save on CPU time during decode” (raro, yo habría comprimido contenido frío en lugar de popular, si el objetivo era ahorrar tiempo de CPU en la descompresión). Es un punto que tiene lógica propia: si comprimís contenido popular, lo vas a descomprimir seguido, lo que suma costo de CPU en cada request. Comprimir contenido frío, que se sirve poco, minimizaría ese costo acumulado de descompresión, aunque también reduciría el ahorro de almacenamiento en el corto plazo, porque el contenido frío suele pesar menos en el total.

CodesInChaos preguntó algo técnico y concreto sobre range requests: “I’m confused by how this affects range requests. Without compression, those can be easily satisfied by reading the relevant part of the cached complete file. But how are they handled now?” (no entiendo cómo afecta esto a los range requests; sin compresión, se resuelven leyendo la parte relevante del archivo completo cacheado, ¿pero cómo se manejan ahora?). Cloudflare no dio una respuesta pública detallada a esto en el material disponible, aunque el propio diseño ya excluye los range requests del proceso de transcodificación, lo que en parte explica por qué: comprimir un archivo con Zstandard rompe la posibilidad de leer directamente un rango de bytes específico sin descomprimir todo antes.

¿En qué etapa de desarrollo está el prototipo y qué falta probar?

Cache Transcoding sigue siendo un prototipo, no una función disponible para todos los usuarios de Cloudflare. La compañía corrió pruebas con y sin Tiered Cache para medir el impacto de la compresión tanto en el caché local como en las transferencias entre niveles de caché.

Falta testear distintos niveles de compresión de Zstandard, distintos tipos de contenido, tamaños de objeto variados y escenarios de caché más amplios. Nada de esto está confirmado para producción todavía.

Qué está confirmado / Qué no

• Confirmado: la reducción de 2.8x en el tamaño del contenido elegible, según los datos publicados por Cloudflare.
• Confirmado: el umbral de 4 KiB y las exclusiones (range requests, binarios, precomprimidos).
• Confirmado: el uso de Zstandard sobre Pingora como stack técnico.
• No confirmado: fecha de disponibilidad general para todos los usuarios de Cloudflare.
• No confirmado: cómo se resuelven en la práctica los range requests una vez que el contenido está comprimido en disco.

Errores comunes al interpretar Cache Transcoding

• Pensar que comprime todo el tráfico de Cloudflare. Solo aplica a texto sin comprimir de al menos 4 KiB; imágenes, video y fuentes quedan fuera por diseño.
• Confundirlo con compresión gzip/brotli en tránsito. Cache Transcoding comprime lo que se guarda en disco en el caché, no necesariamente lo que viaja al navegador del usuario final.
• Asumir que ya está en producción para todos. Es un prototipo en fase de pruebas, con testeo pendiente en varios escenarios según el propio reporte de InfoQ.
• Ignorar el trade-off de CPU. El ahorro de almacenamiento no es gratis: hay un costo de procesamiento al codificar, aunque Cloudflare lo describe como “small increase in CPU”.

Criterios para evaluar si conviene aplicar esta misma lógica en infraestructura propia

Si administrás tu propio caché o servidor de archivos estáticos (no un CDN de la escala de Cloudflare), el criterio que usó la compañía sirve como checklist, aunque los números concretos de Cloudflare no sean trasladables sin más:

• Frecuencia de reuso. Comprimir tiene sentido cuando un objeto se sirve muchas veces desde caché; si un archivo casi no se vuelve a pedir, el costo de comprimirlo puede no justificarse.
• Tipo de contenido. Priorizá texto (HTML, JSON, CSS, JS) sin comprimir. Evitá recomprimir imágenes, video o fuentes que ya llegan en formatos optimizados.
• Tamaño mínimo. Un umbral de tamaño (Cloudflare usa 4 KiB) evita gastar CPU en objetos chicos donde la ganancia es marginal.
• Disponibilidad de CPU vs. espacio en disco. Si tu cuello de botella es almacenamiento y te sobra CPU, la compresión rinde. Si es al revés, quizás no.
• Uso de range requests. Si tu contenido se sirve parcialmente (streaming, descargas por rangos), comprimir puede complicar esa funcionalidad, tal como señaló CodesInChaos.

Este tipo de análisis de costo-beneficio es el mismo que aplica cualquier proveedor de hosting al diseñar su capa de caché, más allá de la escala. Si estás evaluando dónde alojar un proyecto con foco en infraestructura local, donweb.com es una alternativa que vale la pena comparar en cuanto a soporte y ubicación de datacenters, aunque eso sea independiente de la técnica de compresión que describe este artículo.

Preguntas Frecuentes

¿Qué es Cache Transcoding de Cloudflare?

Es un prototipo de Cloudflare que comprime con Zstandard el contenido de texto sin comprimir (HTML, JSON, CSS, JavaScript) antes de guardarlo en el caché en disco, para ahorrar espacio de almacenamiento sin afectar lo que recibe el usuario final.

¿Cómo reduce Cloudflare el almacenamiento en caché?

Comprime el contenido elegible una vez al entrar al caché y lo descomprime al servirlo, logrando una reducción de tamaño de aproximadamente 2.8 veces según datos de Cloudflare, lo que libera espacio en disco en sus servidores existentes.

¿Qué tipo de contenido comprime Cloudflare con esta técnica?

Comprime respuestas de texto sin comprimir de al menos 4 KiB que retornan exitosamente, como HTML, JSON, CSS y JavaScript. Excluye range requests, contenido precomprimido o binario, y respuestas de tamaño desconocido.

¿Qué algoritmo de compresión usa Cloudflare para el caché?

Usa Zstandard, el algoritmo de compresión sin pérdida que desarrolló Facebook para uso en tiempo real, ejecutado sobre Pingora, el framework de proxy en Rust construido por Cloudflare.

¿Cache Transcoding ya está disponible para todos los usuarios de Cloudflare?

No, es un prototipo en desarrollo. Cloudflare todavía tiene pendiente probar distintos niveles de compresión, tipos de contenido, tamaños de objeto y escenarios de caché antes de un lanzamiento más amplio.

Conclusión

Cache Transcoding es una optimización de infraestructura interna, no una función que vos como usuario de Cloudflare tengas que activar o configurar. Lo que cambia es la eficiencia de almacenamiento del lado del proveedor: menos espacio en disco por la misma cantidad de contenido cacheado, y menos datos moviéndose entre data centers.

Para equipos técnicos, el dato útil no es tanto la implementación específica de Cloudflare sino el criterio: separar contenido comprimible de contenido que ya llega optimizado, medir la frecuencia de reuso antes de decidir qué comprimir, y aplicar compresión solo donde rinde según la relación entre CPU disponible y espacio en disco. Antes de asumir que esto se traduce en beneficios directos para tu sitio, valdría la pena esperar a que Cloudflare confirme resultados de las pruebas pendientes con distintos escenarios de caché, algo que todavía no está sobre la mesa.

Fuentes

• InfoQ – Cloudflare Tests Cache Transcoding to Reduce Storage Requirements