La valeur d'un CDN réside dans la probabilité que l'utilisateur ait déjà visité un autre site appelant ce même fichier à partir de ce CDN, et devient de plus en plus précieux en fonction de la taille du fichier. La probabilité que ce soit le cas augmente avec l'ubiquité du fichier demandé et la popularité du CDN.
Dans cet esprit, extraire un fichier relativement volumineux et populaire d'un CDN populaire a un sens absolu. jQuery et, dans une moindre mesure, jQuery UI, correspondent à ce projet de loi.
Pendant ce temps, la concaténation de fichiers a du sens pour les fichiers plus petits qui ne sont pas susceptibles de changer beaucoup - vos plugins couramment utilisés conviendront à cette facture, mais votre code spécifique à l'application de base ne le fait probablement pas: il peut changer d'une semaine à l'autre, et si vous ' En le concaténant avec tous vos autres fichiers, vous devrez forcer l'utilisateur à tout télécharger à nouveau.
Le passe-partout HTML5 fait un très bon travail en fournissant une solution générique pour cela:
- Modernizr est chargé à partir du local dans la tête: il est très petit et diffère beaucoup d'une instance à l'autre, donc cela n'a pas de sens de le trouver à partir d'un CDN et cela ne blessera pas trop l'utilisateur de le charger à partir de votre serveur. Il est mis dans la tête parce que CSS peut l'utiliser, vous voulez donc que ses effets soient connus avant le rendu du corps. Tout le reste va en bas, pour empêcher vos scripts plus lourds de bloquer le rendu pendant qu'ils se chargent et s'exécutent.
- jQuery du CDN, car presque tout le monde l'utilise et c'est assez lourd. L'utilisateur l'aura probablement déjà mis en cache avant de visiter votre site, auquel cas il le chargera instantanément à partir du cache.
- Toutes vos petites dépendances tierces et extraits de code qui ne sont pas susceptibles de changer beaucoup sont concaténés dans un
plugins.js
fichier chargé depuis votre propre serveur. Cela sera mis en cache avec un en-tête d'expiration distant la première fois que l'utilisateur visite et chargé à partir du cache lors des visites suivantes.
- Votre code principal entre
main.js, avec un en-tête d'expiration plus proche pour tenir compte du fait que la logique de votre application peut changer de semaine en semaine ou de mois en mois. De cette façon, lorsque vous corrigez un bogue ou avez introduit de nouvelles fonctionnalités lorsque l'utilisateur visite dans quinze jours, cela peut être chargé à nouveau tandis que tout le contenu ci-dessus peut être importé du cache.
Pour vos autres bibliothèques majeures, vous devriez les regarder individuellement et vous demander si elles doivent suivre l'exemple de jQuery, être chargées individuellement à partir de votre propre serveur ou être concaténées. Un exemple de la façon dont vous pourriez prendre ces décisions:
- Angular est incroyablement populaire et très grand. Obtenez-le du CDN.
- Twitter Bootstrap a un niveau de popularité similaire, mais vous avez une sélection relativement mince de ses composants, et si l'utilisateur ne l'a pas déjà, il ne vaut peut-être pas la peine de lui faire télécharger le tout. Cela dit, la façon dont il s'intègre dans le reste de votre code est assez intrinsèque, et il est peu probable que vous le changiez sans reconstruire l'ensemble du site - vous voudrez peut-être le garder hébergé localement mais garder ses fichiers séparés de votre main
plugins.js. De cette façon, vous pouvez toujours mettre à jour vos plugins.jsextensions avec Bootstrap sans forcer l'utilisateur à télécharger tout le noyau Bootstrap.
Mais il n'y a aucun impératif - votre kilométrage peut varier.
