Comment réduire le JavaScript pour améliorer ses Core Web Vitals ?

Difficile de trouver un site Internet dont les pages ne regorgent pas de Javascript. Mais l'exécution des multiples scripts ralentit le chargement des pages en question et nuit in fine à leur référencement.

Le Javascript est un incontournable de l'un des trois piliers du SEO, à savoir son aspect technique. Pourtant, même s'il est davantage utilisé par les SEO techniques, n'importe quel SEO peut avoir affaire de temps en temps à lui. En effet, il est notamment présent sur un grand nombre de sites qui utilisent des Framework, ou infrastructure de développement JS comme Angular ou React.

Comment fonctionne-t-il ? Pour simplifier, ce langage de programmation vient s'exécuter dans le navigateur de la personne qui consulte un site Internet afin de changer certaines données d'une page. Il permet de modifier les éléments que l'on veut, comme des données entrées dans des formulaires. Cependant, cet enrichissement amène également le ralentissement du temps de chargement de la page pour le navigateur, car le JavaScript vient modifier les contenus originaux.

Cette situation peut poser des problèmes par rapport au Core Web Vitals. Pour rappel, ces indicateurs constituent des critères de positionnement à l'algorithme de Google. Lancés par Google pour évaluer les performances techniques des sites web en matière d'expérience utilisateur, ils se concentrent sur le temps de chargement de la page (LCP pour Large Contentful Paint), l'interactivité (FID pour First Input Delay) et la stabilité visuelle (CLS pourCumulative Layout Shift). 

Alors, comment faire pour que le JavaScript ne vienne pas baisser les notes des Core Web Vitals, sans trop dégrader l'animation du site ? Voici des éléments de réponse.

Une décision à prendre en fonction du site

La gestion du Javascript pour améliorer les Core Web Vitals se fait au cas par cas, selon les experts interrogés. "Sur un site où l'UX n'est pas vital, les techniques pour désactiver ou minimiser le JavaScript se règlent généralement dans une discussion interne entre développeur, un product owner et un SEO", explique Olivier Papon, fondateur de Seolyzer.io. Une fois prise la décision d'optimiser le JavaScript, l'idée générale, pour Arjen Karel, ingénieur web performance chez DPG media, "est de ne télécharger que les scripts dont vous avez réellement besoin au moment opportun. La plupart des sites se trompent en téléchargeant des scripts qui peuvent être actifs sur une page à tout moment," déplore-t-il.

Le code splitting et le tree shalking pour baisser le temps d'exécution du Javascript

Pour bien gérer le Javascript, Arjen Karel préconise d'abord le code splitting, ou fractionnement de code en français. Cette technique permet de proposer des fonctionnalités JavaScript uniquement sur les pages d'un site où cela est pertinent, comme la possibilité de zoomer sur un produit. "Le fait de spliter par fonctionnalité permet d'éviter d'exécuter du code inutile", confirme Olivier Papon. "Mais il s'agit d'un travail de fourmi, pour ne charger que les bons scripts JS par template" 

L'autre technique suggérée par Arjen Karel est le "tree shaking". Elle permet par exemple d'éliminer automatiquement le code mort lors du regroupement de plusieurs fichiers JavaScript dans des fichiers uniques. "Il s'agit de faire du sur-mesure", réagit Olivier Papon. "Ce sont davantage les anglo-saxons qui peuvent se le permettre, car cela nécessite généralement un budget conséquent. Mais c'est un vrai sujet."

En quoi ces techniques permettent-t-elles d'améliorer les Core Web Vitals ? Pour Arjen Karel, "avec le fractionnement de code et le tree shaking, il y aura moins de temps de blocage pour le LCP, si le Javascript est bloqué, et moins de concurrence sur les ressources, qui sont des scripts JavaScript inclus dans la page. Le FID sera plus rapide car il y aura moins de JavaScript, donc moins de travail sur le thread principal, qui est le processus pour afficher correctement la page sur le navigateur. Pour le CLS, c'est une question délicate. Cela ne l'améliore que si vous mettez à jour les composants de la page de manière asynchrone."

L'attribut balise "async" pour améliorer les Core Web vital

De son côté, le quickwin d'Olivier Papon consiste en l'utilisation de l'asynchrone. "On rajoute l'attribut balise "async" à la balise script, ce qui permet de renvoyer l'exécution du script après le premier rendu, et de profiter de la parallélisation au niveau du navigateur". Une façon de ne pas dégrader l'expérience utilisateur et de faciliter le rendering de Google selon lui.

Concernant l'amélioration des Core Web Vitals par l'attribut asynchrone, Olivier Papon explique : "Le LCP, le FID et le CLS sont des indicateurs de vitesse de rendu sur différents évènements. Un script JS lamba synchrone chargé avant l'arrivée de ces évènements viendra les retarder, puisque le navigateur devra "perdre" du temps à exécuter ce JS. En asynchrone, le script JS sera exécuté non prioritairement, après le premier rendu : les KPIs ne seront normalement pas impactés. Attention tout de même : il faut notamment que ces scripts JS soient indépendants et qu'ils n'attendent pas d'éléments d'autres scripts.

Gare aux solutions miracles

Attention à certaines solutions d'apparence rapides et très prometteuses pour améliorer ses Core Web Vitals. Par exemple, un plugin de webperf Wordpress a récemment été épinglé pour triche caractérisée. Afin d'améliorer ses performances, le plugin en question n'activait tout simplement pas le JavaScript lorsque le site était testé depuis Google Lighthouse, GTmetrix, Chrome headless ou Pingdom. Ce qui lui permettait d'afficher la note maximale de "100" sur les différents indicateurs des Core Web Vitals. Les fichiers JavasScript par contre étaient bien chargés lorsque les utilisateurs allaient sur le site.

Notons que le plugin en question est l'extension d'optimisation la plus installée de WordPress… Ce type de tromperie rappelle celle du Diesel gate, lorsque Volkswagen testait ses performances en laboratoire, pour afficher 40 fois moins d'émission de CO2 que les automobilistes réels.