Méfiance avec les CDN de librairies JS
Quand on cherche à optimiser son site web, on se voit souvent conseiller d’utiliser des CDN de librairies JavaScript, par exemple Google Hosted Libraries. C’est une bonne idée, a priori, elles permettent :
- de diminuer la charge sur son serveur
- d’améliorer le temps de chargement pour les clients distants du serveur
- avec un peu de chance, la librairie a déjà été chargée par le navigateur du client
C’est du moins la théorie. Dans la pratique, conserver les librairies sur son propre serveur permet d’être certain qu’elles seront toujours disponibles, en tous cas, au moins autant que son propre site. J’utilise HighCharts intensivement pour un autre WordPress et aujourd’hui mauvaise surprise, quelques uns de mes graphiques ne fonctionnaient plus… Après vérification du code, j’avais oublié de remplacer les url des libraires highcharts par celles hébergées sur mon serveur.
1 2 3 4 5 6 | <script src="http://code.highcharts.com/3.0.8/adapters/standalone-framework.js"></script> <script src="http://code.highcharts.com/3.0.8/highcharts.js"></script> <script src="http://code.highcharts.com/3.0.8/highcharts-more.js"></script> <script src="http://code.highcharts.com/3.0.8/modules/exporting.js"></script> <script src="http://code.highcharts.com/3.0.8/modules/no-data-to-display.js"></script> <script src="http://cloud.highcharts.com/resources-0.1.2/js/data.src.js"></script> |
Je ne sais pas très bien pourquoi, mais l’url de la ligne 6 ne fonctionne plus depuis 2 jours (au moins) et renvoie le message d’erreur » The chart could not be found. » au lieu du JS. Et pourtant, cette url était utilisée par le site cloud.highcharts.com dans ses templates !
Bref, je ne suis pas en train de dire qu’il ne faut pas utiliser ces CDN de librairies. Comme toutes optimisations, elles ont leurs avantages et inconvénients, mais les utiliser à l’aveugle, sans s’être demandé si son site pouvait en bénéficier réellement, est absurde.