Faut-il externaliser ses scripts
C'est la règle numéro 8 des principes YSLOW dans le cadre de l'amélioration de la vitesse d'un site.
Elle se résume au dilemme suivant faut-il limiter le nombre de requêtes faites au serveur, ou faut-il privilégier la bande passante.
La situation est simple, le webmaster dispose de page web composées de contenu que nous appellerons page html, il dispose également de script avec les feuilles de style (css), les script en javascript (par exemple). Ces derniers scripts s'exécutent côté client et ce via le navigateur de l'internaute. Une fois chargés, ces scripts sont disponibles pour les pages html qui les utilisent. Pour que les scripts aillent côté client, l'internaute les télécharge via une requête web dans la page html qu'il visualise. Nous venons de traiter le cas ou le script (css ou javascript est externalisé).
Le webmaster dispose de
- page.html
- feuille.css
- script.js
L'alternative est tout aussi simple, le code css ou javascript n'est pas dans un fichier externalisé, mais dans le code de la page html. Le nombre de requêtes faites au serveur est ainsi limité (une requête contre trois précédemment), mais la page est plus importante en taille puisque tout le code est dans un fichier unique.
Le webmaster dispose de
- page.html
Une fois le problème posé, il convient d'y répondre.
A vrai dire, il convient à chaque webmaster d'y répondre. Il y a quelques années, l'hébergement web se faisait via des systèmes limités en ressources, c'est-à-dire tant de requêtes par jour, ou tant de bande passante. Selon le type d'hébergement choisi, la réponse était choisie et adaptée à l'hébergement. Une limite en bande passante impose d'externaliser ses fichiers scripts et feuilles de style, alors que la limite en nombre de requêtes impose d'intégrer ses scripts dans les pages html.
Aujourd'hui, les limites se portent plus sur les bases SQL, que sur la capacité des serveurs ou la limitation de la bande passante.
La question reste toutes fois posée, car le temps de réponse n'est pas identique selon l'architecture du site.
L'intérêt de l'externalisation repose sur le fait qu'une fois dans le cache du navigateur, le fichier téléchargé et qui a couté 1 requête serveur n'a pas a être téléchargé de nouveau. L'internaute peut changer de page html, le fichier n'est pas téléchargé de nouveau, son cout est toujours de 1.
Mais imaginons que ce fichier, la feuille de style, soit différent car l'internaute ayant changé de rubrique, charge alors un nouveau look de page, codé dans une seconde feuille css. Notre cout d'acquisition est alors à 2, et ainsi de suite pour chaque rubrique.
Dans ce cas alors où une feuille de style est spécifique à chaque rubrique avec une navigation naturelle inter-rubrique, le webmaster aurait intérêt à insérer ses codes css dans ses pages html et non à les externaliser.
Coté programmation, il n'est pas plus difficile avec un langage dynamique d'aller chercher une inclusion de code css spécifique, plutôt qu'un script externalisé.
C'est donc l'architecture même du site et la structure de navigation dans le site qui vont faire que l'on optimise le nombre de requêtes au serveur, ou bien l'utilisation de la bande passante. Il n'y a donc pas une réponse générique, mais des réponses spécifiques à chaque site web.
Le site ci présent utilise une feuille de style unique, et un script ou deux côté javascript, le choix s'est donc porté vers de l'externalisation.