Lors du processus d’affichage d’une page web, la première phase consiste au téléchargement de la page web : le document HTML ainsi que les images, mais aussi les feuilles CSS de styles et les scripts JS liés.
Le contenu HTML, c’est ce qu’on voit : le texte, les images, les champs de recherche, etc.
Les styles CSS, c’est comment le HTML sera vu : disposition, couleurs polices et taille du texte, couleur du fond de la page.
Le CSS et le HTML sont donc nécessaires à l’affichage de la page web et donc au visiteur qui souhaite lire votre site.
Les scripts JS, en revanche, ce sont des instructions destinées au navigateur, pas à l’internaute. Le navigateur les traite en tâche de fond et l’utilisateur de voit pas de différence s’ils sont là où pas (normalement).
Le problème, c’est la capacité du JS de modifier le HTML et le CSS. Du coup, le navigateur qui reçoit une page HTML+CSS n’aura en réalité la totalité de la page web qu’une fois qu’il aura terminé d’exécuter les scripts JS. Avant cela, il ne peut (presque) rien faire : il va bien commencer à afficher les différents éléments de la page (menu, titres, liens…) mais si le JS supprime le menu entre temps, il devra tout recommencer.
La solution du navigateur pour le problème du JS ?
Commencer d’effectuer le rendu (l’affichage) de la page et mettre ce rendu en pause quand il détecte un script JS : à ce moment là, il doit télécharger tout le script JS et l’exécuter entièrement (ce qui a des chances de modifier le HTML et le CSS, souvenez-vous) avant de reprendre de rendu (et au besoin le recommencer, si le JS a beaucoup modifié le HTML ou le CSS).
Le fait pour le navigateur d’avoir à se mettre en pause lorsqu’il rencontre un script, nous fait dire que le JS est bloquant.
Le CSS, le HTML et même les images sont non-bloquant : le navigateur peut continuer à décoder la page web même quand il est encore en train de télécharger du CSS, par exemple. Il peut donc télécharger du CSS en parallèle avec le HTML. Une fois qu’il a tout le CSS, il commence le rendu tel qu’il est décrit par le CSS. Le décodage du HTML, lui, se poursuit durant tout ce temps.
Un document HTML simple, sans CSS ni JS, s’affiche quand même : c’est le rendu par défaut d’une page web : le fond est blanc, le texte est noir et tous les éléments sont à la suite les uns des autres. Bref, c’est moche, mais ça reste lisible.
Le navigateur, quand il reçoit le document HTML, commence par effectuer le rendu par défaut. Lorsqu’il reçoit le CSS, ce rendu par défaut continu (de façon à ce que la page soit lisible — même si c’est moche). Le rendu par défaut est stoppé quand tout le CSS est arrivé : à ce moment là, c’est le rendu tel qu’il est décrit dans le CSS qui est appliqué : les couleurs, les fonds, les bordures, les ombres… tout ça est alors affiché. Le traitement du CSS ne bloque pas le téléchargement du reste du contenu de la page.
Pour l’instant je n’ai pas vraiment répondu à la question « pourquoi mettre le JS à la fin et le CSS au début ? », mais j’y viens.
On sait que l’affichage des données (texte, images…) dans la page web commence dès que le HTML est en train d’être téléchargé : ceci permet à l’internaute d’accéder à l’information contenue dans la page le plus rapidement possible, même si le CSS et le JS ne sont pas encore arrivés. Une fois que tout le CSS est obtenu, l’information est alors restructurée, organisée sur la page et coloriée.
Lorsque le navigateur reçoit un script JS, l’affichage est mis en pause : le JS doit finir de s’exécuter avant que l’affichage puisse continuer.
L’intérêt de placer le CSS en haut et le JS en bas se trouve à ce niveau.
Si on met le CSS en haut, c’est pour que l’affichage « colorié » se fasse le plus vite possible : pour que la page web soit « jolie » et « organisée » tout de suite, avant que l’utilisateur ne puisse se trouver face à une page web dans son rendu par défaut. Cela tombe d’ailleurs bien : le téléchargement du CSS n’est pas bloquant : l’information dans la page web continue d’arriver pendant ce temps : l’affichage de la page web n’est pas ralentie par le CSS. C’est juste mieux de l’avoir avant, pour que l’affichage se fasse directement comme la page doit être, sans à avoir un rendu par défaut entre-temps.
Parallèlement si on met le JS en bas du document, toute l’information contenue dans la page web sera déjà affichée (car déjà téléchargée et déjà rendue à l’écran). Au moment où le navigateur rencontre le JS, l’écran ne sera pas tout vide ni tout blanc : l’internaute pourra commencer à lire la page web pendant que le navigateur traite le script JS et effectue les derniers changements.
Si on mettait le JS tout en haut, la page n’aurait encore aucune donnée que l’affichage et le téléchargement seraient déjà bloqués : l’internaute n’aurait alors qu’une simple page blanche et rien à lire. Si le script est gros, cela peur prendre plusieurs secondes. Si ça ne semble pas long dit comme ça, croyez-moi, ça l’est : si toutes les pages web mettaient 2 secondes de plus pour s’afficher, vous le verriez très rapidement. Placer le JS en haut n’est donc pas génial, car il oblige le navigateur à tout mettre en pause et l’internaute à attendre devant une page vide.
Mettre le CSS en bas de la page n’est pas avantageux non plus : le CSS n’est pas bloquant. Il peut être téléchargé en parallèle avec le reste. Si on le met en bas de la page, il sera téléchargé en dernier et tout seul, donc sans tirer profit de la possibilité de télécharger deux choses en même temps. De plus, tout le document HTML sera déjà là mais affiché avec le rendu par défaut du navigateur, donc tout moche. Si l’internaute a déjà commencé à lire, il verrait alors la page se modifier sous ses yeux à l’instant même où tout le CSS aura fini de télécharger et que le rendu se fasse.
Il convient donc naturellement de mettre le CSS le plus tôt possible dans la page (dans le head) pour tirer profit du téléchargement en parallèle du CSS avec d’autres ressources et pour que le rendu se fasse directement de façon voulue ; et il faut placer le JS en bas du document pour que quand le navigateur le trouve, tout le reste de la page soit déjà affiché à l’écran et que l’internaute puisse commencer à lire votre page pendant le traitement du script JS par le navigateur en tâche de fond.
Quelques liens :
- Visualisation de l’affichage d’une page web au ralenti. Normalement le navigateur fait tout ceci en quelques millisecondes seulement.
- Un navigateur, comment ça marche ?
- High Performance Web Sites: Rule 5 – Put Stylesheets at the Top
- High Performance Web Sites: Rule 6 – Move Scripts to the Bottom