Cloudflare reduce su caché a un tercio con Zstandard y Pingora

Cloudflare recorta su caché a un tercio con Zstandard y Pingora

Cloudflare publicó el prototipo Cache Transcoding: una capa de compresión con Zstandard (zstd) aplicada dentro de su proxy Pingora que reduce el tamaño en disco de los activos elegibles a un tercio del original. En pruebas internas, el sistema comprimió los archivos de texto unos 2,834x y la empresa habla de ahorros de petabytes de capacidad efectiva de caché a cambio de unos puntos porcentuales extra de CPU en el origen.

Para un founder hispanohablante, esto importa menos por el detalle técnico y más por lo que señala: cuando el operador de uno de los CDNs más grandes del mundo empieza a renegociar su economía del almacenamiento, la presión de costes que vive la capa cloud en 2026 es real, y la propia Cloudflare ya lo tradujo en carne propia.

Por qué Cloudflare necesitaba un nuevo truco para su caché

El post arranca con un dato que condiciona toda la decisión: el coste de la memoria, tanto RAM como disco, se ha disparado en el último año. Cloudflare opera varios productos de almacenamiento distribuidos a escala (incluido su CDN, presente según W3Techs en aproximadamente el 21,3% de todos los sitios web en enero de 2026, según recoge Wikipedia). En esa escala, cada byte que se almacena o se mueve entre data centers multiplica el coste.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La idea de Cache Transcoding es directa: cuando un activo elegible entra al caché, se codifica con zstd antes de escribirse a disco. Mientras vive en el caché y se mueve entre data centers vía Tiered Cache, se mantiene comprimido. Solo se decodifica en el último salto, justo antes de salir hacia el cliente. El resultado es que la representación en disco cambia, pero el contenido que recibe el usuario es idéntico al original.

Qué es Zstandard y por qué ganó la pulse con Brotli y gzip

Zstandard es un algoritmo de compresión sin pérdida desarrollado por Yann Collet en Facebook y liberado como open source en 2016. Su diseño busca el equilibrio entre ratio de compresión y velocidad, algo crítico cuando la compresión se aplica a tráfico masivo.

En pruebas previas de Cloudflare sobre compresión en navegador, zstd comprimió los datos un 42% más rápido que Brotli produciendo archivos de tamaño casi idéntico, y generó archivos un 11,3% más pequeños que gzip a velocidad comparable. En Cache Transcoding usan zstd nivel 3: un punto intermedio que captura la mayor parte del beneficio sin convertir el llenado del caché en un cuello de botella de CPU.

El detalle operativo que cuenta: comprimir una vez al llenar el caché cuesta más CPU por byte (4,31 ns por byte, unos 232 MB/s) que decodificar al servir (1,56 ns por byte, unos 641 MB/s). Pero los activos se sirven muchas más veces de las que se llenan, así que pagar el coste de编码 una vez y cobrar el beneficio cada vez es la clave del modelo económico.

Cómo funciona Cache Transcoding dentro de Pingora

Pingora es el proxy interno basado en Rust que Cloudflare utiliza como columna vertebral de su tráfico. Cache Transcoding añade una capa más dentro de ese proxy. El flujo en cada caso:

Cache miss: el proxy Pingora codifica el cuerpo con zstd antes de escribirlo a disco. Los metadatos del caché registran que la representación guardada está comprimida y conservan el Content-Length original.
Cache hit con Tiered Cache: el objeto comprimido se transfiere del nivel superior al inferior ya comprimido. La decodificación ocurre solo en el último salto, el que ve el cliente.
Cache hit en el nivel inferior: no hay transferencia de red ni codificación extra. Se lee el objeto comprimido de disco, se decodifica y se entrega.

Un marcador de codificación en los metadatos evita que un objeto se comprima dos veces al pasar entre tiers: si un objeto ya entra como zstd, la capa receptora lo conserva en esa forma.

Qué se comprime y qué no: el criterio detrás del 4 KiB

Cloudflare no comprime todo a lo loco. La propia empresa midió su tráfico y encontró un corte claro:

Imágenes, vídeo y fuentes: ya están comprimidos. En la muestra de Cloudflare representaban el 21,4% de las peticiones pero el 63,3% de los bytes. Recomprimirlos quemaría CPU para ganar casi nada.
HTML, JSON, CSS y JavaScript: el 67,3% de las peticiones y el 22,3% de los bytes. Dentro de este bloque, aproximadamente el 71% llegaba sin Content-Encoding, es decir, sin comprimir. Aquí zstd aporta de verdad.

Sobre ese slice, los activos elegibles se comprimieron unas 2,8 veces en el corpus de prueba. El sistema además aplica tres filtros duros: la respuesta tiene que ser 200 OK, Content-Encoding no establecido y Content-Length conocido de al menos 4 KiB. Ese umbral mínimo descarta una masa enorme de peticiones minúsculas eliminando solo alrededor del 1% de los bytes elegibles, según los datos del prototipo.

Un detalle contraintuitivo: Cloudflare probó a limitar la transcompresión al contenido más popular esperando ahorrar CPU, pero no funcionó. Como la decodificación ocurre en cada serve, restringir a los hot assets reducía el ahorro de almacenamiento sin recortar CPU en la misma proporción. La política simple (todo el texto elegible por encima de 4 KiB) rindió mejor dentro del presupuesto de CPU que habían marcado.

Los números del test con un millón de peticiones

Cloudflare ejecutó la batería contra una zona de prueba controlada, correlacionando cada petición con logs, métricas de Prometheus y trazas de Jaeger. La campaña de rendimiento envió más de un millón de peticiones a través de 10 servidores de caché: la mitad con Tiered Cache desactivado, la otra mitad con Tiered Cache activo, para poder separar el comportamiento local del coste de transferir entre tiers.

Los dos activos de prueba rondaban los 195 KiB y 272 KiB, ambos comprimiendo unas 2,8 veces. La empresa aclara que el corpus era deliberadamente comprimible: daba una señal limpia para validar la arquitectura, pero no representa todo el texto que circula en internet. Para tratar ese 2,8x como una constante de flota habría que probarlo sobre un corpus más amplio.

El presupuesto de CPU extra quedó en pocos puntos porcentuales bajo las condiciones de tráfico y reuso que modelaron, según el post.

Qué significa esto para tu startup

Si tu producto corre sobre Cloudflare (o sobre cualquier CDN con Tiered Cache), esta arquitectura no cambia tu factura de inmediato: la compresión la paga Cloudflare, no el cliente. Pero sí cambia dos cosas que sí te tocan:

Densidad de caché y命中率 (hit rate): al guardar más objetos por servidor con la misma cantidad de disco, es menos probable que un activo se evicte por quedarse sin espacio. Si publicas contenido que cambia poco y se sirve mucho (documentación, dashboards, assets estáticos de marketing, JSON cacheado de APIs), puedes esperar un mejor hit rate cuando Cloudflare active la transcompresión a escala.
Latencia del primer byte en cross-region: como el objeto viaja comprimido entre data centers, el tiempo para poblar cachés fríos en una región nueva baja. Para productos con audiencia distribuida entre LATAM, España y Estados Unidos, esa mejora es operativa, no teórica.

Dos acciones concretas:

Audita tu Content-Encoding: si hoy sirves HTML, JSON, CSS o JS sin comprimir en origen, estás pagando a Cloudflare ancho de banda que podrías comprimir gratis en tu edge con Brotli o gzip. Actívalo antes de que la transcompresión interna de Cloudflare te dé el ahorro sin que tú muevas nada.
Mide tu hit rate por asset: abre el dashboard de Cloudflare y mira qué tanto se sirve desde caché cada categoría de contenido. Identifica los objetos grandes y repetidos (PDFs, JSONs pesados, bundles JS) que hoy no llegan al 90% de hit rate; son los candidatos naturales a políticas de cache más agresivas ahora que Cloudflare puede guardar más por servidor.

El contexto detrás: por qué Cloudflare está tan obsesionada con ahorrar

El post llega en un momento incómodo para la empresa. En mayo de 2026, Cloudflare anunció el recorte de unas 1.100 posiciones, aproximadamente el 20% de su plantilla, en una reestructuración que el CEO Matthew Prince atribuyó a la rápida adopción de herramientas de IA. El anuncio coincidió con los resultados del Q1 2026, con US$639,8M de facturación, un 34% más interanual, según reportó TechCrunch en mayo de 2026 (recogido por Wikipedia).

Prince insistió en que los recortes no respondían a problemas de rendimiento, sino a roles que la IA había vuelto prescindibles, y señaló que esperaban contratar a más gente a finales de 2027 que en cualquier momento de 2026. Cuando un operador del tamaño de Cloudflare publica simultáneamente que elimina el 20% de su workforce por la IA y que su CDN ahora ahorra petabytes de almacenamiento gracias a un truco ingenioso de un interno, el mensaje implícito es claro: la presión de costes operativos en infraestructura cloud en 2026 es estructural, no cíclica.

Los siguientes pasos que Cloudflare adelantó en el post son evaluación de niveles más altos de zstd, pruebas con más tipos de contenido y objetos, ajuste de los criterios de elegibilidad, y explorar el paso del objeto comprimido directo a componentes downstream que ya lo soporten, sin decodificar. Trabajo abierto, pero la dirección ya está marcada.