Si tienes un VPS barato o un WordPress en hosting compartido y delante has puesto Cloudflare porque «va gratis», seguramente llevas meses sin mirar la configuración de caché. A mi me pasa. Y justo ahí está el problema: aunque no cambies tú nada en el panel, la red por la que pasan tus visitas sí cambia. En mayo de 2026 Cloudflare ha dejado claro que su caché ya no va sobre el mismo motor de siempre, sino sobre Pingora, el proxy que llevan tiempo cocinando en Rust.
Yo no te voy a vender Rust ni mucho menos a ti te importa el lenguaje. Lo que sí te debería importar es que cuando alguien mueve el «motor» del CDN, lo que cambia son detalles minúsculos de HTTP que en un proyecto grande son ruido y en una pyme con WooCommerce o un login sencillo se convierten en un «pero si ayer iba».
Según el changelog oficial, la idea es menos latencia, mejor reutilización de conexiones y menos MISS ridículos que te obligan a pegarle al origen cada dos por tres. Eso suena bien. También dice que hay stale-while-revalidate de verdad, asíncrono: puedes servir una copia algo vieja mientras en segundo plano se refresca. Para un blog estático o un JS cacheable, bien. Para una página donde el usuario está logueado o donde tu proveedor mezcla cabeceras como si fueran ingredientes de cocina, ya no es tan obvio.
Y aquí entro en lo que me mosquea del relato «transparente». Cloudflare lista cambios de comportamiento que antes podían pasar desapercibidos y ahora no: por ejemplo, ciertos patrones de Vary o cómo se tratan cookies en respuestas MISS o EXPIRED. Tú no tienes por qué saber RFC de memoria pero sí deberías saber si tu tema o tu plugin mete Set-Cookie donde no toca o si hay respuestas que dependen de la cookie de sesión para todo el HTML. Porque si el CDN decide no cachear algo que tú creías cacheable, el síntoma será más TTFB y no un error bonito en rojo.
En paralelo, la propia compañía está empujando otra pieza del puzzle: compresión con diccionarios compartidos (beta abierta en el anuncio del 30 de abril de 2026). Ahí hablan de recortes brutales en el peso de bundles grandes cuando el navegador y el edge se entienden. Suena a milagro, y puede serlo, pero también es otro eje donde Chrome y Edge van por delante y donde el soporte real de tu audiencia importa. No es que debas parchear tú el protocolo; es que si tu analítica no separa navegadores y versiones vas a achacar a la plantilla lo que es un gradiente tecnológico normal en 2026.
¿Y el vínculo con Pingora «open source»? Hace tiempo Cloudflare ya publicó material en español presentando Pingora como marco para servicios de red programables. Bonito pitch, pero no te confundas: poder toquetear el código en GitHub no es lo mismo que tener control sobre tu zona de la red global de Cloudflare. Tú sigues siendo quien pincha «nube naranja sí» y espera que el tráfico se comporte. Por eso me resulta más útil leer cosas como su entrada sobre endurecer la red tras incidentes recientes: te recuerda que el mapa no es neutro, que hay prioridades de ingeniería que no siempre coinciden con las prioridades de tu factura mensual.
Si lo resumo como lo contaría en un café con un colega: la mejora de caché es real pero viene con matices de cabeceras y cookies que un WordPress con plugins de terceros puede activar sin que te des cuenta. La compresión avanzada es prometedora, pero depende del ecosistema del cliente. Y el relato «open source» es sobre todo cultura de proyecto, no garantía de simplicidad para el usuario final.
Asi que sí, Cloudflare sigue siendo competitivo en su capa gratuita para muchos casos. Pero gratis ya no significa «cero mantenimiento mental» cuando el edge avanza más rápido que tu hoja de ruta. Si tu negocio vive de la web, tocar revisar reglas de caché, exclusiones por cookie y pruebas con sesión iniciada debería estar en el mismo saco que actualizar plugins, solo que con otro tipo de dolores de cabeza.
La pregunta que yo me haría después de leer el changelog no es si Rust mola sino si tu equipo sabe dónde mirar cuando un cambio invisible en el CDN hace que una URL «sienta» distinta sin tocar código. Si hoy abrieras las herramientas de desarrollador en una página catalogada como cacheable y otra con sesión, sabrías explicar en dos frases que cabeceras las separan y cuál es el riesgo de mezclarlas en tu stack concreto con WooCommerce o con el login que uses?