cdnjs, jsDelivr o unpkg: qué los diferencia de verdad ahora que la caché del navegador está particionada
- vuetelemetry
- Herramientas
- 8 min de lectura
Cloudflare acaba de reconstruir cdnjs sobre su propia plataforma de desarrollo sin cambiar una sola URL. Es un buen momento para revisar la elección entre los tres CDN públicos de JavaScript, porque el argumento que la mayoría de desarrolladores sigue usando dejó de ser cierto en 2020.
Una migración que nadie debía notar
El 30 de julio de 2026 Cloudflare publicó cómo reconstruyó cdnjs, el CDN público que opera para bibliotecas JavaScript y CSS, sobre su propia plataforma de desarrollo; InfoQ lo recogió el 14 de agosto. Las cifras que da Cloudflare merecen enunciarse tal cual: cdnjs sirve unos 9 000 millones de peticiones al día, alrededor de 108 000 peticiones por segundo repartidas en más de 330 centros de datos, con una tasa de acierto de caché del 98,6 %, y lo usa aproximadamente el 12 % de los sitios web.
La arquitectura cambió por debajo. R2 pasó a ser la fuente de verdad de los ficheros publicados, KV guarda los metadatos de los paquetes, las versiones y los hashes de Subresource Integrity, y un Worker atiende las peticiones con Workers Cache delante. Lo que no cambió es justo lo que importa a quien alguna vez ha pegado una etiqueta script en una página: Cloudflare indica que el contenido de los paquetes, las URLs y los hashes SRI se preservaron. La migración se diseñó para ser invisible.
Esa invisibilidad es el verdadero producto. Un CDN público hace una sola promesa que valga la pena: que la URL que pegaste en tu <head> hace cinco años siga devolviendo los mismos bytes hoy. Todo lo demás - el número de puntos de presencia, la tasa de caché, el runtime sobre el que está construido - es detalle de implementación. Estos servicios se juzgan por su capacidad de cambiarlo todo por debajo sin cambiar nada de lo que dependes.
Tres CDN, tres promesas distintas
Los tres candidatos habituales no son la misma clase de cosa, y confundirlos es el error más común. cdnjs sirve un catálogo curado de bibliotecas: un proceso humano decide qué entra. jsDelivr sirve paquetes de npm, repositorios de GitHub y builds ESM, y funciona como multi-CDN, repartiendo las peticiones entre Cloudflare y Fastly. unpkg es el más simple de los tres: un espejo directo de npm, donde todo lo publicado es alcanzable de inmediato por URL.
El argumento que dejó de ser cierto en 2020
Ahora, el argumento del que hay que desprenderse. Durante años la justificación estándar de un CDN público fue la caché compartida: usa el CDN que usa todo el mundo y tu visitante ya tendrá jQuery en caché desde otro sitio, así que no cuesta nada. Hace tiempo que no es cierto. Los navegadores particionan la caché HTTP por el sitio que visitas - Safari desde 2013, Chrome desde su versión 86 en 2020, Firefox desde su versión 85 en 2021.
- cdnjs - catálogo curado, operado por Cloudflare; la reconstrucción de 2026 preservó las URLs, el contenido de los paquetes y los hashes SRI
- jsDelivr - npm, GitHub y ESM; multi-CDN entre Cloudflare y Fastly; los ficheros ya servidos se conservan aunque el paquete desaparezca
- unpkg - un espejo directo de npm: el más simple de los tres y el más expuesto a los cambios aguas arriba
- La caché compartida entre sitios ya no existe: Safari 2013, Chrome 86 en 2020, Firefox 85 en 2021 - el argumento histórico de los CDN públicos ya no aplica
- Añade siempre integrity y crossorigin a una etiqueta de terceros; con un bundler moderno, autoalojar suele ser más rápido y más seguro que los tres
La partición implica que un fichero descargado en el sitio A se vuelve a descargar en el sitio B, incluso con la misma URL en el mismo CDN. El cambio se hizo por privacidad: una caché compartida filtra el historial de navegación, porque un sitio puede cronometrar una petición y deducir si has estado en otro. La ganancia de rendimiento era real, se cedió deliberadamente, y cualquier consejo que aún se apoye en ella describe una web anterior a 2020.
Qué los separa realmente ahora
Quita ese argumento y la comparación se vuelve más estrecha y más honesta. Quedan la disponibilidad, la inmutabilidad y cuánta superficie de terceros aceptas colgar de tu página. Sobre la inmutabilidad, jsDelivr indica que un fichero ya servido se almacena de forma permanente, de modo que un paquete retirado de npm sigue respondiendo en lugar de romper los sitios que lo referenciaban. unpkg, al ser un espejo, sigue a npm más de cerca. Quien recuerde la desaparición de left-pad de npm en 2016 sabe que esto no es un caso teórico.
Sobre la disponibilidad, el diseño multi-CDN de jsDelivr hace que un proveedor con un mal día no se lleve el servicio por delante. cdnjs se apoya por completo en Cloudflare, y la migración de 2026 lo hizo más homogéneo, no más redundante. Es un compromiso más que un defecto: un único operador muy grande con más de 330 ubicaciones frente a varios operadores con modos de fallo independientes. Elige el fallo que prefieras tener que explicar.
El atributo integrity no es opcional
Elijas lo que elijas, usa Subresource Integrity. Un atributo integrity junto a crossorigin="anonymous" le pide al navegador que rechace un fichero cuyo hash no coincida, que es la diferencia entre confiar en una URL y confiar en quien la controla. Sin él, concedes a un tercero derechos de ejecución incondicionales en cada página de tu sitio. La etiqueta de la fotografía de arriba no lleva atributo integrity, y ese es el caso habitual más que la excepción.
La opción que la mayoría de comparativas se salta
Queda la opción que la mayoría de comparativas se salta: no usar ningún CDN público. Sirve el fichero de la biblioteca desde tu propio origen, junto al resto de tus assets. Como la caché está particionada, de todas formas no ganabas nada con la caché compartida, y el autoalojamiento elimina una resolución DNS, una negociación TLS y una conexión a un host que no controlas. Tu bundler ya lo hace. Para la mayoría de sitios en 2026 es a la vez la opción más rápida y la más segura.
Una última honestidad sobre los tres: se ofrecen en régimen de mejor esfuerzo, sin compromiso contractual de disponibilidad. Son infraestructura pública generosa, no un servicio que se te deba. Si tu página queda inservible cuando una biblioteca no carga, esa dependencia no debería vivir en el plan gratuito de otro, por muchos centros de datos que tenga.
FAQ
¿Un CDN público sigue acelerando mi sitio porque el fichero ya está en caché desde otro sitio?
No. Los navegadores particionan la caché HTTP por el sitio que visitas, así que un fichero descargado en un sitio se vuelve a descargar en otro aunque la URL y el CDN sean idénticos. Safari particiona desde 2013, Chrome desde su versión 86 en 2020 y Firefox desde su versión 85 en 2021. El cambio se hizo por privacidad, porque una caché compartida permite a un sitio deducir qué otros sitios has visitado cronometrando una petición. Cualquier recomendación que aún se apoye en la caché compartida describe la web anterior a 2020.
¿La migración de cdnjs en 2026 rompió las URLs existentes?
No. Cloudflare reconstruyó cdnjs sobre su plataforma de desarrollo - R2 como fuente de verdad de los ficheros publicados, KV para metadatos, versiones y hashes SRI, y un Worker sirviendo las peticiones - preservando el contenido de los paquetes, las URLs y los hashes SRI. El servicio declara unos 9 000 millones de peticiones al día, alrededor de 108 000 por segundo en más de 330 centros de datos, y una tasa de acierto de caché del 98,6 %. Las etiquetas script y link existentes siguen funcionando sin cambios.
cdnjs, jsDelivr o unpkg: ¿cuál elegir?
Si quieres un catálogo curado de bibliotecas y aceptas depender de un único operador muy grande, cdnjs es un valor por defecto razonable. Si quieres redundancia entre proveedores y la garantía de que un fichero ya servido seguirá respondiendo aunque el paquete se retire de npm, el diseño multi-CDN y el almacenamiento permanente de jsDelivr encajan mejor. unpkg es la vía más directa a cualquier paquete de npm y la más simple de razonar, a cambio de seguir más de cerca los cambios de npm. Para la mayoría de sitios en producción, autoalojar el fichero es mejor respuesta que los tres.
¿Necesito Subresource Integrity si confío en el CDN?
Sí. Subresource Integrity no dice nada sobre si confías en las intenciones del operador; es lo que limita el daño si el fichero servido en esa URL llega a cambiar, por el motivo que sea. Añade un atributo integrity con el hash esperado y crossorigin="anonymous", y el navegador se negará a ejecutar un fichero que no coincida. Sin él, un tercero tiene derechos de ejecución incondicionales en cada página que lleve la etiqueta.
Elijas lo que elijas, usa Subresource Integrity. Un atributo integrity junto a crossorigin="anonymous" le pide al navegador que rechace un fichero cuyo hash no coincida, que es la diferencia entre confiar en una URL y confiar en quien la controla. Sin él, concedes a un tercero derechos de ejecución incondicionales en cada página de tu sitio. La etiqueta de la fotografía de arriba no lleva atributo integrity, y ese es el caso habitual más que la excepción.