3 façons de charger une librairie JavaScript populaire

En règle générale, chaque fois que j'ai à utiliser une librairie JavaScript, je télécharge la dernière version du composant et je la dépose dans l'arborescence du projet (en milieu professionnel, nous créons une référence pour que le fichier puisse être partagé dans n'importe quel projet et pour faciliter le processus de mise à jour). La copie locale demeure la façon de faire la plus répandue chez les programmeurs web. Même si elle demande un peu plus d'efforts, elle apporte la certitude d'avoir le contrôle absolu sur la librairie. D'autres préféreront la simplicité de charger un script externe sur demande, même si ça peut comprendre certains inconvénients. Explorons les alternatives pour inclure une librairie JavaScript populaire à un projet web (jQuery, Prototype, Scriptaculous, YUI, Dojo, MooTools, etc).

1. Télécharger une copie de la librairie et la placer sur votre serveur

Ici, c'est votre responsabilité de maintenir les librairies en téléchargeant manuellement les nouvelles versions qui sont lancées (bug fixes, nouvelles fonctionnalités, compatibilité de fureteurs, etc). Un avantage est de pouvoir compresser vous-même les librairies, les empaqueter en un fichier unique pour pouvoir minimiser les requêtes HTTP et accélérer le téléchargement des ressources et l'affichage du contenu.

<script type="text/javascript" src="/js/jquery-1.4.min.js"></script>

Sur une page vide, j'ai testé le temps de chargement de chaque type d'inclusion. Dans ce cas-ci, YSlow indiquait :

Score : 96, Grade A
Temps de chargement : 0,258 seconde

La note n'est pas parfaite car je n'ai pas pris le temps d'optimiser ces éléments sur mon serveur de développement :

B : Add Expires headers
B : Compress components with gzip

2. Service de distribution externe

C'est l'équivalent d'inclure un fichier local sauf que plutôt d'être hébergé sur votre serveur, il se trouve sur un serveur externe auquel vous avez confiance, par exemple le service offert par Google Libraries API.

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

YSlow score : 99, Grade A
Temps de chargement :0,292 seconde

Le temps de chargement est rapide et les librairies sont optimisées convenablement mais chaque script nécessitera une requête HTTP sur le serveur, ce qui rend impossible d'empaquetage groupé des fichiers. Les scripts cross-sites ne pourront pas fonctionner sur un intranet web offline (reposant sur la technologie web sans toutefois avoir un accès externe).

Le bon fonctionnement est aussi dépendant de la disponibilité du service, ce qui rendrait le site inutilisable si le serveur distant est en panne. Si le service est fourni par un géant comme Google, le risque est faible, sauf en cas d'attaques par les chinois ! Certains craindront aussi la brèche XSS possible si le serveur distant est attaqué.

3. Par le loader de Google AJAX Libraries API

Plutôt que de lier directement chaque script par le service de distribution, on peut utiliser le chargeur prévu à cet effet. Une librairie principale (loader) récupérera elle-même chaque librairie demandée. Google suggère d'obtenir une clé (gratuite) pour avoir accès à certaines librairies, comme Google Maps par exemple.

<script type="text/javascript" src="http://www.google.com/jsapi?key=VOTRE-CLE"></script>
<script type="text/javascript">
google.load("jquery", "1.4.2");
</script>

YSlow score : 95, Grade A
Temps de chargement :0,395 seconde

Le script de chargement demandera 5.4 kb supplémentaires à charger et rend le temps d'exécution légèrement plus lent.

C : Use a Content Delivery Network (CDN)
B : Add Expires headers
B : Compress components with gzip

YSlow suggère parfois de mettre les scripts le plus près possible de la balise de fermeture du BODY plutôt que dans le HEAD pour que la page s'affiche le plus rapidement. Un problème courant est que si l'utilisateur voit apparaître le contenu de la page en premier et qu'un des composants JavaScript soit plus lent que les autres à charger, les événements JavaScript ne seront pas initialisés immédiatement, ce qui pourrait laisser croire à un mauvais fonctionnement des contrôles qui n'auraient aucune réaction au moment de les utiliser (par exemple, un bouton ayant un événement attaché par JS). Personnellement, je préfère les laisser en entête, quitte à ce que ça soit plus long au premier chargement. De toute façon, les scripts iront immédiatement dans la cache du fureteur.