cdnjs, jsDelivr ou unpkg : ce qui les distingue vraiment depuis que le cache navigateur est cloisonné
- vuetelemetry
- Outils
- 8 min de lecture
Cloudflare vient de reconstruire cdnjs sur sa propre plateforme de développement sans changer une seule URL. L'occasion de reprendre le choix entre les trois CDN JavaScript publics, car l'argument que la plupart des développeurs invoquent encore a cessé d'être vrai en 2020.
Une migration que personne ne devait remarquer
Le 30 juillet 2026, Cloudflare a publié le récit de la reconstruction de cdnjs, le CDN public qu'il opère pour les bibliothèques JavaScript et CSS, sur sa propre plateforme de développement ; InfoQ l'a relayé le 14 août. Les chiffres donnés par Cloudflare méritent d'être posés tels quels : cdnjs sert environ 9 milliards de requêtes par jour, soit près de 108 000 requêtes par seconde réparties sur plus de 330 centres de données, avec un taux de succès de cache de 98,6 %, et il est utilisé par environ 12 % des sites web.
L'architecture a changé en dessous. R2 est devenu la source de vérité des fichiers publiés, KV stocke les métadonnées des paquets, les versions et les empreintes Subresource Integrity, et un Worker traite les requêtes avec Workers Cache devant. Ce qui n'a pas changé est précisément ce qui compte pour quiconque a déjà collé une balise script dans une page : Cloudflare indique que le contenu des paquets, les URLs et les empreintes SRI ont tous été préservés. La migration a été conçue pour être invisible.
Cette invisibilité est le vrai produit. Un CDN public ne fait qu'une seule promesse qui vaille : que l'URL collée dans votre <head> il y a cinq ans réponde encore les mêmes octets aujourd'hui. Tout le reste - le nombre de points de présence, le taux de cache, le runtime sur lequel il est bâti - relève du détail d'implémentation. Ces services se jugent à leur capacité à tout changer en dessous sans rien changer à ce dont vous dépendez.
Trois CDN, trois promesses différentes
Les trois candidats habituels ne sont pas de même nature, et les confondre est l'erreur la plus répandue. cdnjs sert un catalogue de bibliothèques curé : un processus humain décide de ce qui y entre. jsDelivr sert les paquets npm, les dépôts GitHub et des builds ESM, et fonctionne en multi-CDN, en répartissant les requêtes entre Cloudflare et Fastly. unpkg est le plus simple des trois : un miroir direct de npm, où tout ce qui est publié devient immédiatement joignable par URL.
L'argument qui a cessé d'être vrai en 2020
Vient maintenant l'argument dont il faut se défaire. Pendant des années, la justification standard d'un CDN public était le cache partagé : utilisez le CDN que tout le monde utilise, et votre visiteur aura déjà jQuery en cache depuis un autre site, donc cela ne coûte rien. Ce n'est plus vrai depuis longtemps. Les navigateurs cloisonnent désormais le cache HTTP par site visité - Safari depuis 2013, Chrome depuis sa version 86 en 2020, Firefox depuis sa version 85 en 2021.
- cdnjs - catalogue curé, opéré par Cloudflare ; la reconstruction de 2026 a préservé les URLs, le contenu des paquets et les empreintes SRI
- jsDelivr - npm, GitHub et ESM ; multi-CDN entre Cloudflare et Fastly ; les fichiers déjà servis sont conservés même si le paquet disparaît
- unpkg - un miroir direct de npm : le plus simple des trois, et le plus exposé aux changements en amont
- Le cache partagé entre sites n'existe plus : Safari 2013, Chrome 86 en 2020, Firefox 85 en 2021 - l'argument historique des CDN publics est caduc
- Ajoutez toujours integrity et crossorigin à une balise tierce ; avec un bundler moderne, l'auto-hébergement est souvent plus rapide et plus sûr que les trois
Ce cloisonnement signifie qu'un fichier téléchargé sur le site A est retéléchargé sur le site B, y compris pour l'URL identique sur le CDN identique. Le changement a été fait pour la vie privée : un cache partagé fuit l'historique de navigation, car un site peut chronométrer une requête et en déduire si vous êtes allé ailleurs. Le gain de performance était réel, il a été délibérément abandonné, et tout conseil qui s'y appuie encore décrit un web d'avant 2020.
Ce qui les sépare réellement aujourd'hui
Retirez cet argument et la comparaison devient plus étroite et plus honnête. Restent la disponibilité, l'immuabilité, et la quantité de surface tierce que vous acceptez d'attacher à votre page. Sur l'immuabilité, jsDelivr indique qu'un fichier déjà servi est stocké de façon permanente : un paquet retiré de npm continue donc de répondre au lieu de casser les sites qui le référençaient. unpkg, étant un miroir, suit npm de plus près. Qui se souvient de la disparition de left-pad de npm en 2016 sait que ce n'est pas un cas d'école.
Sur la disponibilité, la conception multi-CDN de jsDelivr fait qu'un fournisseur en difficulté n'emporte pas le service avec lui. cdnjs repose entièrement sur Cloudflare, et la migration de 2026 l'a rendu plus homogène, pas plus redondant. C'est un arbitrage plutôt qu'un défaut : un opérateur unique très large avec plus de 330 emplacements, contre plusieurs opérateurs aux modes de panne indépendants. Choisissez la panne que vous préférerez expliquer.
L'attribut integrity n'est pas optionnel
Quel que soit votre choix, utilisez Subresource Integrity. Un attribut integrity accompagné de crossorigin="anonymous" demande au navigateur de refuser un fichier dont l'empreinte ne correspond pas, ce qui fait toute la différence entre faire confiance à une URL et faire confiance à qui la contrôle. Sans lui, vous accordez à un tiers un droit d'exécution inconditionnel sur chaque page de votre site. La balise de la photo ci-dessus ne porte aucun attribut integrity, et c'est le cas courant plutôt que l'exception.
L'option que la plupart des comparatifs sautent
Reste l'option que la plupart des comparatifs sautent : ne pas utiliser de CDN public du tout. Servez le fichier de la bibliothèque depuis votre propre origine, avec le reste de vos assets. Puisque le cache est cloisonné, vous ne gagniez de toute façon rien au cache partagé, et l'auto-hébergement supprime une résolution DNS, une négociation TLS et une connexion vers un hôte que vous ne contrôlez pas. Votre bundler le fait déjà. Pour la plupart des sites en 2026, c'est à la fois le choix le plus rapide et le plus sûr.
Une dernière honnêteté sur les trois : ils sont fournis au mieux, sans engagement contractuel de disponibilité. Ce sont des infrastructures publiques généreuses, pas un service qui vous est dû. Si votre page devient inutilisable quand une bibliothèque ne se charge pas, cette dépendance n'a pas sa place sur l'offre gratuite d'un tiers, quel que soit son nombre de centres de données.
FAQ
Un CDN public accélère-t-il encore mon site parce que le fichier est déjà en cache depuis un autre site ?
Non. Les navigateurs cloisonnent le cache HTTP par site visité : un fichier récupéré sur un site est récupéré à nouveau sur un autre, même quand l'URL et le CDN sont identiques. Safari cloisonne depuis 2013, Chrome depuis sa version 86 en 2020 et Firefox depuis sa version 85 en 2021. Le changement a été fait pour la vie privée, car un cache partagé permet à un site de déduire quels autres sites vous avez visités en chronométrant une requête. Toute recommandation qui s'appuie encore sur le cache partagé décrit le web d'avant 2020.
La migration de cdnjs en 2026 a-t-elle cassé les URLs existantes ?
Non. Cloudflare a reconstruit cdnjs sur sa plateforme de développement - R2 comme source de vérité des fichiers publiés, KV pour les métadonnées, les versions et les empreintes SRI, et un Worker pour servir les requêtes - tout en préservant le contenu des paquets, les URLs et les empreintes SRI. Le service annonce environ 9 milliards de requêtes par jour, près de 108 000 requêtes par seconde sur plus de 330 centres de données, et un taux de succès de cache de 98,6 %. Les balises script et link existantes continuent de fonctionner sans modification.
cdnjs, jsDelivr ou unpkg : lequel choisir ?
Si vous voulez un catalogue de bibliothèques curé et acceptez de dépendre d'un opérateur unique très large, cdnjs est un choix par défaut raisonnable. Si vous voulez de la redondance entre fournisseurs et la garantie qu'un fichier déjà servi continuera de répondre même si le paquet est retiré de npm, la conception multi-CDN et le stockage permanent de jsDelivr conviennent mieux. unpkg est la voie la plus directe vers n'importe quel paquet npm et la plus simple à raisonner, au prix d'un suivi plus étroit des changements de npm. Pour la plupart des sites en production, auto-héberger le fichier reste une meilleure réponse que les trois.
Ai-je encore besoin de Subresource Integrity si je fais confiance au CDN ?
Oui. Subresource Integrity ne dit rien de la confiance que vous accordez aux intentions de l'opérateur ; c'est ce qui limite les dégâts si le fichier servi à cette URL vient à changer, pour quelque raison que ce soit. Ajoutez un attribut integrity avec l'empreinte attendue et crossorigin="anonymous", et le navigateur refusera d'exécuter un fichier qui ne correspond pas. Sans lui, un tiers détient un droit d'exécution inconditionnel sur chaque page qui porte la balise.
Quel que soit votre choix, utilisez Subresource Integrity. Un attribut integrity accompagné de crossorigin="anonymous" demande au navigateur de refuser un fichier dont l'empreinte ne correspond pas, ce qui fait toute la différence entre faire confiance à une URL et faire confiance à qui la contrôle. Sans lui, vous accordez à un tiers un droit d'exécution inconditionnel sur chaque page de votre site. La balise de la photo ci-dessus ne porte aucun attribut integrity, et c'est le cas courant plutôt que l'exception.