Voici une vérité inconfortable sur la performance web. Une grande partie du JavaScript que tu charges ne sert pas à faire fonctionner ton produit. Elle sert à le décorer. Des apparitions en fondu au défilement, des compteurs qui s'animent, un effet de parallaxe, un curseur qui suit la souris. Des effets que ton visiteur ne réclamerait jamais, qu'il ne remarquerait même pas s'ils disparaissaient, et qui pourtant retardent le moment où il peut lire ton offre.
Sur Copyboost, une librairie d'animation de 116 Ko servait uniquement à faire apparaître des sections en fondu pendant le défilement. Elle était chargée sur toutes les pages, y compris les pages légales que personne ne fait défiler. 116 Ko de code pour un effet décoratif, embarqués partout. Voici comment ce genre de JavaScript bloque ta page, et comment t'en débarrasser.
Le JavaScript se met en travers du premier affichage
Pour afficher ta page, le navigateur suit un chemin précis. Il lit le HTML, construit l'arbre du document, applique le CSS, puis peint. Le problème, c'est qu'un script placé dans l'en tête sans précaution interrompt ce chemin. Le navigateur s'arrête, télécharge le script, l'exécute, et seulement ensuite reprend la construction de la page. Pendant tout ce temps, ton visiteur fixe un écran blanc.
C'est ça, le JavaScript bloquant. Pas du code lent en lui même, du code qui se met en travers de la route du premier affichage. Et le plus absurde, c'est quand ce code bloquant sert à une animation. Tu fais attendre ton visiteur devant une page vide pour avoir le droit, une seconde plus tard, de lui montrer un joli fondu sur du contenu qu'il aurait préféré voir tout de suite.
L'effet se paie deux fois. Une fois en téléchargement, parce que c'est du poids à transférer. Une fois en exécution, parce que c'est du travail sur le fil principal du navigateur, celui là même qui devrait répondre aux premiers gestes de ton visiteur. Tu retardes l'affichage et tu alourdis la réactivité, pour une décoration.
Et les pires coupables ne sont même pas les tiens. Ce sont les scripts tiers. Un gestionnaire de balises qui en charge dix autres, un outil d'A/B testing qui bloque l'affichage le temps de décider quelle version montrer, un widget de chat qui s'invite sur chaque page. Tu ne les vois pas dans ton propre code, parce qu'ils s'injectent depuis l'extérieur, mais ils s'exécutent sur le fil principal de ton visiteur exactement comme les tiens. Un site peut être impeccable côté code et crouler sous cinq scripts tiers que personne n'a réévalués depuis leur installation.
Deux mots techniques valent le détour, parce qu'ils désamorcent une grande partie du problème. Un script en defer se télécharge en parallèle et ne s'exécute qu'une fois la page construite, dans l'ordre. Un script en async se télécharge en parallèle aussi, mais s'exécute dès qu'il est prêt, sans ordre garanti. Dans les deux cas, le navigateur ne s'arrête plus pour eux le temps de peindre. La règle simple : defer pour ce qui dépend de la page, async pour ce qui est indépendant, et jamais un script nu dans l'en tête sans l'un des deux.
Avant d'optimiser ton JavaScript, supprime le
La plupart des conseils de performance te disent comment charger ton JavaScript plus intelligemment. Async, defer, découpage, chargement différé. Tout ça est utile. Mais c'est la deuxième question. La première est plus radicale, et personne ne la pose : est ce que ce script doit exister ?
Le JavaScript le plus rapide est celui que tu n'envoies pas. Un effet de fondu au défilement ne convertit personne. Un compteur animé n'a jamais signé un contrat. Une parallaxe n'a jamais réduit un churn. Ces effets se vendent en interne sur l'idée qu'ils font moderne, mais ils ne portent aucun argument, et ils coûtent un délai réel à chaque visiteur. Quand tu hésites entre optimiser un script et le supprimer, supprime. Tu ne reviendras pas dessus, et personne ne le remarquera, ce qui est précisément la preuve qu'il ne servait à rien.
Copyboost, 116 Ko pour un fondu
Voilà ce que mon propre diagnostic a montré, et la correction.
- Le constat. Une librairie d'animation de 116 Ko était importée globalement, pour un seul usage, faire apparaître des sections en fondu au défilement. Comme elle était dans la chaîne partagée, elle se chargeait sur la page d'accueil, sur le blog, et même sur les pages de mentions légales où il n'y a rien à animer.
- La question. Est ce que ce fondu portait quoi que ce soit ? Non. Le contenu était lisible sans lui. L'effet ne faisait que retarder son apparition de quelques centaines de millisecondes, sur chaque page.
- La correction. La librairie a été sortie de la chaîne marketing et confinée aux seuls composants de l'application qui en avaient un vrai besoin fonctionnel, le réflexe d'isoler les librairies lourdes. Les pages de contenu et les pages légales ne la chargent plus du tout.
Résultat, les pages les plus vues n'embarquent plus 116 Ko de décoration. Le contenu s'affiche plus tôt, le fil principal est plus libre, et aucun visiteur ne s'est plaint de la disparition du fondu. Personne ne l'a remarqué. C'était bien là le problème.
Le tri en 3 questions
Pour chaque script que charge ta page, pose les trois questions, dans l'ordre. Tu sauras quoi en faire.
- Garde. Est ce que ce script est nécessaire au premier affichage ou à une interaction réelle de ton visiteur ? Si oui, il reste, mais tu le charges proprement, le plus bas possible, sans bloquer le rendu.
- Diffère. Est ce qu'il sert à quelque chose de réel mais pas tout de suite ? Analytics, widget de chat, scripts tiers. Si oui, charge le en async ou en defer, après le premier affichage, pour qu'il ne se mette jamais en travers de la peinture initiale.
- Supprime. Est ce qu'il alimente un effet purement décoratif que ton visiteur ne réclamerait pas ? Si oui, supprime le. Pas plus tard, maintenant. C'est le seul des trois qui te fait gagner sur les deux tableaux à la fois, poids et réactivité.
Où tu repères les coupables : l'audit Lighthouse "éliminer les ressources qui bloquent le rendu" te liste les scripts en travers du premier affichage. L'onglet Coverage de Chrome te montre, ligne par ligne, quel pourcentage de ton JavaScript n'est jamais exécuté sur la page. Quand un fichier est utilisé à 12 pour cent, tu tiens ton premier candidat à la suppression.
Ce qu'il faut retenir
Le JavaScript bloquant n'est pas d'abord un problème d'optimisation, c'est un problème de discipline. Avant de te demander comment charger un script plus vite, demande toi s'il doit exister. La plupart du temps, la moitié de ton code sert des effets que personne ne réclame et que personne ne regretterait. Supprime ceux là, diffère ceux qui peuvent attendre, et garde proprement le reste. Ouvre l'onglet Coverage sur ta page d'accueil, regarde combien de ton JavaScript ne tourne jamais, et commence ta liste de suppressions par le haut. Et n'oublie pas tes scripts tiers dans le compte, ce sont souvent eux qui pèsent le plus pour le moins de valeur. Chaque script que tu retires est un visiteur qui voit ta page plus tôt, et un fil principal plus disponible quand il décide enfin de cliquer. C'est la performance, premier levier CRO, gagnée par soustraction.