Cloudflare migró cdnjs a Workers y R2: qué cambia
En pocas palabras: Cloudflare completó el 14 de agosto de 2026 la migración de cdnjs —su CDN open source de librerías JavaScript y CSS— a su Developer Platform. Ahora corre íntegro sobre Workers, R2 y Durable Objects, sirviendo 9.000 millones de pedidos por día desde más de 330 centros de datos.
Cloudflare completó la migración de cdnjs, su CDN open source para librerías JavaScript y CSS, a su Developer Platform. La movida, que la empresa anunció el 14 de agosto de 2026, unificó una infraestructura que antes se repartía entre Cloudflare y Google Cloud, y ahora corre entera sobre Workers, R2, Workflows, Queues, Durable Objects, KV y Containers.
Si alguna vez pegaste un <script src="https://cdnjs.cloudflare.com/..."> en un HTML, ya usaste esto sin pensarlo. La novedad es cómo se sirve por debajo, no qué recibís vos.
cdnjs es una red de distribución de contenido (CDN) open source operada por Cloudflare que entrega librerías JavaScript y CSS a cualquier sitio web sin costo. Con esta migración, cdnjs pasó a servir unos 9.000 millones de pedidos por día (108.000 por segundo) desde más de 330 centros de datos, usando R2 como fuente única de verdad y preservando las URLs, los contenidos y los hashes SRI que ya existían.
En resumen
- Cloudflare movió cdnjs entero a su Developer Platform: Workers, R2, Workflows, Queues, Durable Objects, KV y Containers.
- Escala real: 9.000 millones de requests/día, 108.000 por segundo, 330+ data centers, 98,6% de cache hit rate.
- cdnjs lo usa cerca del 12% de los sitios web del mundo.
- R2 ahora es la fuente única de verdad de los archivos publicados.
- Para vos que lo consumís: cero trabajo. Las URLs, los contenidos y los hashes SRI quedaron igual.
Cloudflare es una plataforma de infraestructura web que proporciona servicios de red de distribución de contenidos (CDN), protección DDoS y seguridad web, fundada en 2009 por Matthew Prince, Lee Holloway y Michelle Zatlyn.
¿Qué es cdnjs y para qué lo usan los desarrolladores?
cdnjs es un repositorio público de librerías front-end (jQuery, Bootstrap, React, Font Awesome y miles más) que Cloudflare sirve desde su red global sin cobrar nada. En vez de hostear vos mismo esos archivos, apuntás a la URL de cdnjs y el navegador del visitante los baja del data center más cercano.
El caso de uso típico es simple: querés meter una librería en tu sitio sin sumar peso a tu propio hosting ni configurar un pipeline de build. Ponés el link y listo. En gestión segura de secretos en Workers profundizamos sobre esto.
La escala explica por qué esto es noticia. Según los datos que publicó Cloudflare, cdnjs aparece en cerca del 12% de todos los sitios web. Cuando un servicio así toca esa cantidad de tráfico, cualquier cambio de arquitectura se vuelve delicado: un error se multiplica por miles de millones.
¿Por qué Cloudflare decidió esta migración de cdnjs?
La razón principal es que la infraestructura estaba partida en dos nubes. El servicio de archivos ya vivía en Cloudflare desde 2020, pero el camino de publicación (lo que pasa cuando un mantenedor sube una versión nueva de una librería) seguía apoyado en Google Cloud Functions. Dos proveedores, dos lugares donde algo se puede romper, dos facturas.
Consolidar todo en la Developer Platform tiene una lógica clara para Cloudflare: menos piezas móviles, un solo lugar para operar y, de paso, una demostración pública. Corren su propia plataforma de desarrolladores en un servicio con tráfico de verdad, no en una demo de laboratorio.
¿Es también una jugada de marketing? Obvio que sí. Cloudflare describió la migración como un ejemplo de su Developer Platform “a la escala de un servicio público ampliamente usado”. Traducido: mirá lo que aguanta esto. Tomalo con pinzas, igual, porque el benchmark es del propio fabricante.
¿Cuáles son los componentes de la arquitectura nueva?
La arquitectura nueva reemplaza la infraestructura dispersa por siete servicios de la Developer Platform, cada uno con un rol. Workers hace el cómputo en el borde, R2 guarda los archivos como fuente de verdad, y el resto orquesta la publicación. Acá va el mapa de quién hace qué. Lo explicamos a fondo en infraestructura DNS confiable globalmente.
| Componente | Rol en cdnjs |
|---|---|
| Workers | Cómputo en el borde: atiende cada request de librería |
| R2 | Object storage y fuente única de verdad de los archivos publicados |
| Workflows | Orquestación del proceso de publicación |
| Queues | Mensajería entre etapas del pipeline |
| Durable Objects | Estado persistente y coordinación |
| KV | Caché de lectura rápida para metadata |
| Containers | Tareas de publicación que necesitan un entorno completo |
El punto interesante es que antes esto era un rejunte: máquinas de origen dedicadas al principio, Cloudflare para el servicio desde 2020, Google Cloud para publicar. Ahora es un stack solo.
| Aspecto | Antes | Ahora (2026) |
|---|---|---|
| Servido de archivos | Workers + origin externo de fallback | Workers + R2 |
| Publicación | Google Cloud Functions | Workflows, Queues, Containers |
| Fuente de verdad | Infraestructura distribuida | R2 |
| Proveedores | Cloudflare + Google Cloud | Solo Cloudflare |
¿Qué mejoras de performance y disponibilidad trae?
Los números que dio Cloudflare son concretos: 98,6% de cache hit rate y 108.000 requests por segundo de promedio, repartidos en más de 330 data centers. Un cache hit rate de casi 99% quiere decir que la enorme mayoría de los pedidos se resuelven sin tocar el almacenamiento de origen. El archivo ya está caliente cerca del usuario.
Para vos, eso es latencia baja. El visitante de tu sitio baja jQuery del nodo más cercano, no de un server que quizás está a un océano de distancia.
La disponibilidad se apoya en la misma red. Con 330+ ubicaciones, la caída de un data center no tumba el servicio. Y como las URLs y los hashes SRI se preservaron, la integridad de los archivos sigue verificándose igual que antes. Nadie tuvo que reescribir un integrity="sha384-...".
¿Cómo funciona R2 como fuente única de verdad?
R2 es el object storage de Cloudflare, y en cdnjs pasó a ser el lugar canónico donde viven los archivos publicados. Cuando un Worker recibe un pedido y el contenido no está en caché, lo busca en R2. Un solo origen, sin la ambigüedad de “¿cuál copia es la buena?” que traía la infraestructura distribuida anterior. Tema relacionado: rendimiento en contenedores Cloudflare.
La ventaja práctica es doble. Primero, consistencia: hay una verdad, no varias que se pueden desincronizar. Segundo, integración: R2 vive dentro de la misma plataforma que los Workers, así que servir un archivo no cruza fronteras entre nubes.
Si estás pensando en montar tu propia estrategia de storage y CDN para un proyecto, esta es la clase de arquitectura que conviene mirar. Y si necesitás hosting o infraestructura administrada en Argentina para la parte de tu stack que no va al borde, donweb.com es una opción local.
¿Qué cambia para los desarrolladores que usan cdnjs?
Para vos que consumís cdnjs, no cambia nada. Ese es el logro real de la migración: fue transparente. Las URLs siguen siendo las mismas, los contenidos son idénticos y los hashes SRI no se movieron, así que no hay ni una línea de código para tocar.
Ponele que tenés un sitio con 40 páginas que apuntan a cdnjs.cloudflare.com. No abriste el editor, no desplegaste nada, y sin embargo tu sitio ya está sirviéndose desde la arquitectura nueva. Ese tipo de migración “invisible” es lo más difícil de lograr a esta escala, y acá salió bien.
El beneficio que sí notás con el tiempo es indirecto: una plataforma más consolidada tiende a ser más fácil de mantener y evolucionar. Menos deuda operativa del lado de Cloudflare, en teoría, se traduce en un servicio más estable del tuyo.
¿Cuál es el historial de optimizaciones de cdnjs?
Esta migración no salió de la nada. Se apoya en un cambio de 2020, cuando Cloudflare movió el servido de archivos de cdnjs a Workers y reemplazó las máquinas de origen dedicadas para el tráfico normal, dejando un origen externo solo como fallback. En esa misma etapa metió assets precomprimidos en Brotli y gzip para bajar el peso de la transferencia. Relacionado: integración con almacenamiento distribuido.
Subís una librería, se comprime en Brotli, se cachea en 330 nodos, se sirve con un hit rate de casi 99% y el usuario ni se entera del recorrido. Esa cadena se fue armando de a pedazos entre 2020 y 2026.
Lo que faltaba cerrar era la publicación, que seguía colgada de Google Cloud. La movida de 2026 completó el círculo: ahora todo el ciclo de vida de un archivo, desde que un mantenedor lo sube hasta que llega al navegador, vive dentro de la Developer Platform.
Errores comunes al pensar en cdnjs y esta migración
- Creer que tenés que migrar algo en tu sitio. No. La migración fue del lado de Cloudflare. Tus URLs de cdnjs funcionan igual y tocar el código “por las dudas” solo te expone a romper lo que anda.
- Confundir cdnjs con un CDN para tus propios archivos. cdnjs sirve librerías open source públicas, no tus imágenes ni tu JavaScript privado. Para eso necesitás un CDN o storage propio, como R2 u otro servicio.
- Sacar el atributo SRI porque “ya está en Cloudflare”. El hash SRI (
integrity) verifica que el archivo no fue alterado. Se preservó justo para que lo sigas usando. Sacarlo te deja sin esa red de seguridad. - Asumir 100% de disponibilidad. El cache hit rate es 98,6%, altísimo, pero ningún servicio externo está garantizado al 100%. Para dependencias críticas, tener un fallback local sigue siendo buena práctica.
Preguntas Frecuentes
¿Qué es cdnjs y para qué sirve?
cdnjs es una CDN open source operada por Cloudflare que sirve librerías JavaScript y CSS de forma gratuita a cualquier sitio web. Sirve para incluir librerías como jQuery, Bootstrap o Font Awesome sin hostearlas vos mismo, apuntando a una URL pública que se entrega desde la red global de Cloudflare.
¿Por qué Cloudflare migró cdnjs a su Developer Platform?
Para consolidar una infraestructura que antes se repartía entre Cloudflare y Google Cloud Platform. El camino de publicación todavía dependía de Google Cloud Functions; la migración de 2026 lo movió a Workers, R2, Workflows, Queues, Durable Objects, KV y Containers, unificando todo en un solo proveedor.
¿Cómo afecta la migración a los usuarios de cdnjs?
No los afecta: fue transparente. Cloudflare preservó las URLs existentes, los contenidos de los paquetes y los hashes SRI, así que quienes usan cdnjs no tienen que cambiar ni una línea de código. El servicio sigue funcionando igual, solo que sobre una arquitectura nueva.
¿Qué es R2 en Cloudflare?
R2 es el servicio de object storage de Cloudflare. En cdnjs cumple el rol de fuente única de verdad: guarda los archivos publicados de las librerías y los Workers los sirven desde ahí cuando no están en caché. Reemplaza la lógica de almacenamiento distribuida que existía antes.
¿Cuántos pedidos maneja cdnjs por día?
cdnjs sirve unos 9.000 millones de pedidos por día, un promedio de 108.000 requests por segundo, distribuidos en más de 330 centros de datos de Cloudflare. El servicio reporta un 98,6% de cache hit rate y aparece en cerca del 12% de los sitios web.
Conclusión
Lo que cambió es la ingeniería, no la experiencia. Cloudflare terminó de mudar cdnjs a su Developer Platform y borró la última dependencia de Google Cloud que quedaba en el camino de publicación. Ahora Workers, R2 y el resto del stack manejan 9.000 millones de requests diarios con 98,6% de cache hit rate.
¿Por qué te importa a vos? Porque si usás cdnjs, ya estás corriendo sobre esto sin haber hecho nada, y porque es un caso de estudio concreto de cómo se opera storage y cómputo en el borde a escala real. Si estás diseñando tu propia arquitectura, mirá cómo separaron el servido (Workers) de la verdad (R2). Y no saques el SRI de tus tags: sigue siendo tu mejor defensa contra un archivo alterado.
