Marzo de 2026 ha sido un mes raro de tranquilo en el sentido de que no ha habido un apagón masivo en las noticias tech, pero Cloudflare ha seguido metiendo piezas en el tablero del edge. Si gestionas webs o tiendas online, dos anuncios del changelog oficial me parecen los que más te pueden tocar la fibra: uno va al control del caché sin tocar el origen, y el otro abre la puerta a Workers que se arrancan en milisegundos y se pueden encadenar. Te lo cuento con mano izquierda, como si estuviéramos en la barra del congreso.
Cache Response Rules: el CDN que negocia por ti
Hasta hace poco, si querías que el CDN respetara o reinterpretara cabeceras Cache-Control, muchas veces tenías que tocar el servidor de origen o montar reglas a medida. En el changelog del 24 de marzo de 2026 Cloudflare presenta Cache Response Rules: básicamente puedes decidir cómo reacciona el edge frente a lo que devuelve tu origen, sin modificar ese origen. Eso incluye ajustar directivas como no-store, max-age o s-maxage, separar lo que ve el navegador de lo que usa la red de Cloudflare por dentro, y trabajar con etiquetas de caché o incluso convertir formatos si vienes de otro proveedor CDN.
Para una pyme que está migrando de un hosting clásico a algo más moderno, esto es oro: reduces fricción en el cambio y evitas la típica reunión donde el desarrollador dice que no puede tocar el .htaccess hasta pasado el puente. En mi experiencia el cuello de botella no es solo la velocidad, es la política de caché mal alineada entre capas. Si puedes alinearla desde el panel del edge, ahorras tickets y llamadas.
Dynamic Workers: beta abierta y casos que ya no suenan a demo
El mismo día, Dynamic Workers pasó a beta abierta para usuarios de Workers de pago. La idea es que un Worker pueda lanzar otros Workers en entornos aislados que arrancan en milisegundos. Cloudflare enlaza esto con ejecutar código generado por IA, modos tipo «code mode» para LLMs y previsualizaciones rápidas de desarrollo. En el blog corporativo profundizan en el sandboxing y en cómo reducir coste de tokens al ejecutar código en el edge en lugar de mandarlo todo al modelo otra vez.
¿Te va a cambiar la vida mañana si solo tienes un WordPress con WooCommerce? Probablemente no de golpe. Pero si ya estás en Workers para rutas API, transformaciones o edge middleware, sí te cambia el abanico de lo que puedes automatizar sin montar otro Kubernetes en tu vida. Yo lo miro como una pieza más para quien ya está en ese ecosistema, no como excusa para meter complejidad donde un plugin bien configurado basta.
Un apunte de seguridad: Pingora y el request smuggling
No es una funcionalidad nueva de producto, pero el 9 de marzo Cloudflare publicó detalles sobre vulnerabilidades de request smuggling en HTTP/1.x en el framework Pingora en código abierto, con CVEs concretas y la recomendación de actualizar a Pingora 0.8.0. Dejan claro que su propia red CDN no se vio afectada, pero si en tu stack usas Pingora fuera de ese entorno, el aviso te interesa directamente. A veces el titular «Cloudflare» te hace pensar solo en DNS y caché, y la realidad es que el software de infraestructura también pide parches.
Qué haría yo en un proyecto real esta semana
Si ya usas Cloudflare delante de tu web, revisaría si las nuevas reglas de respuesta de caché te permiten simplificar algo en origen o cerrar una migración pendiente. Si pagas Workers, le echaría un vistazo a la documentación de Dynamic Workers antes de que tu equipo proponga otra capa intermedia en un VPS. Y si no usas nada de esto, al menos ten presente que el mercado del edge sigue apretando: no es solo «poner un CDN y listo», es decidir dónde vive la lógica y quién la paga.
Al final lo que me preocupa no es la lista de features, es que muchos clientes sigan creyendo que un plan gratis resuelve lo mismo que uno de pago con soporte y límites claros. Las herramientas nuevas ayudan, pero la deuda técnica no desaparece porque el panel tenga más toggles.
Si mañana tuvieras que elegir entre seguir con un plan gratuito de CDN y dedicar horas a reglas a mano, o pasar a un plan de pago con menos fricción en Workers y caché, ¿en qué parte de tu stack pondrías el dinero primero: en el edge o en el hosting de origen?