Chapitre 8.13La performance web

Un site lent n'est pas un site cassé. C'est pire, c'est un site que les gens abandonnent sans jamais te dire pourquoi.

Tu as sans doute déjà croisé des chiffres chocs sur le sujet, du genre "au-delà de trois secondes, la moitié des visiteurs partent". Ces statistiques circulent depuis des années, elles varient énormément d'un secteur à l'autre et beaucoup datent d'une époque où le web mobile ressemblait à autre chose. Je préfère donc te donner la version prudente, qui est largement documentée et sur laquelle tout le monde s'accorde. Quand un site accélère, le taux d'abandon baisse et les conversions montent. Quand il ralentit, l'inverse se produit.

La performance web n'est donc pas un caprice de développeur. Un site lent perd des clients, perd des positions sur Google et coûte souvent plus cher en infrastructure, parce qu'un serveur mal optimisé se rattrape à coups de machines supplémentaires.

Ce qui ralentit un site

Avant de parler de solutions, il faut comprendre ce qui se passe entre le moment où tu tapes une adresse et celui où la page s'affiche. Ton navigateur enchaîne les étapes suivantes.

1. Résoudre le nom de domaine pour obtenir une adresse IP, via le DNS.
2. Établir la connexion avec le serveur, TCP puis la poignée de main HTTPS.
3. Attendre que le serveur fabrique la page, puis télécharger le HTML.
4. Découvrir dans ce HTML les ressources à récupérer, CSS, JavaScript, images, polices.
5. Exécuter le JavaScript.
6. Calculer la mise en page, dessiner le résultat, rendre la page interactive.

Chaque étape coûte du temps, et surtout chaque étape dépend de la précédente. Sur un réseau mobile où un simple aller-retour prend déjà cent millisecondes, ces délais s'additionnent très vite. Voici les coupables les plus fréquents.

• Les images non optimisées : une photo de 5 Mo là où une version de 200 Ko aurait suffi. C'est le problème numéro un sur la majorité des sites, et c'est aussi le plus facile à corriger.
• Le JavaScript excessif : des frameworks entiers chargés pour afficher une page qui aurait pu être statique. Le poids n'est même pas le pire, car le navigateur doit ensuite analyser et exécuter tout ce code, ce qui monopolise le processeur du téléphone.
• Les scripts tiers : chat en ligne, tests A/B, régies publicitaires, outils d'analytics. Chacun paraît anodin, mais ils s'accumulent au fil des années et personne n'ose les retirer. De mon expérience, c'est le premier endroit où regarder quand un site s'est mystérieusement alourdi.
• Les requêtes trop nombreuses : chaque fichier demande au minimum un aller-retour réseau. HTTP/2 et HTTP/3 ont beaucoup atténué le problème en permettant de multiplexer plusieurs téléchargements sur une seule connexion, mais deux cents fichiers restent deux cents fichiers à récupérer, décoder et assembler.
• Le serveur lent : une requête de base de données mal écrite, un calcul refait à chaque visite, un hébergement sous-dimensionné pour le trafic. Le visiteur regarde alors une page blanche, sans même savoir si quelque chose arrive.

Les Core Web Vitals

Longtemps, mesurer la performance voulait dire regarder le temps de chargement total. L'indicateur était mauvais, parce qu'une page peut être parfaitement utilisable alors qu'un script publicitaire continue de charger en arrière-plan.

Google a donc défini un petit ensemble d'indicateurs centrés sur le ressenti réel de l'utilisateur, les Core Web Vitals. Ils sont au nombre de trois et répondent chacun à une question simple.

• LCP (Largest Contentful Paint) : au bout de combien de temps le plus gros élément visible, en général l'image principale ou le titre, apparaît-il à l'écran ? C'est la question "est-ce que je vois quelque chose d'utile ?". Le seuil considéré comme bon est de 2,5 secondes.
• INP (Interaction to Next Paint) : quand je clique ou que je tape, au bout de combien de temps la page réagit-elle visuellement ? C'est la question "est-ce que ça répond ?". Le seuil est de 200 millisecondes.
• CLS (Cumulative Layout Shift) : est-ce que le contenu bouge tout seul pendant le chargement ? C'est la question "est-ce que je peux cliquer sans me faire piéger ?". Le seuil est de 0,1, sur une échelle sans unité.

L'INP a remplacé le FID (First Input Delay) en mars 2024. Si tu tombes sur un article ou une présentation qui parle encore du FID comme d'un Core Web Vital, c'est qu'il date d'avant ce changement. L'INP est plus sévère, parce qu'il mesure la réaction complète de la page et pas seulement le délai avant que le navigateur commence à traiter le clic.

Le CLS est celui que les équipes produit comprennent le plus vite, parce que tout le monde l'a vécu.

Ces seuils ne sont pas gravés dans le marbre. Google les a déjà fait évoluer, a remplacé un indicateur par un autre et continuera sans doute. Retiens surtout la logique, on mesure la vitesse d'affichage, la réactivité et la stabilité visuelle, plutôt qu'un chronomètre global qui ne veut rien dire.

Mesures en laboratoire et mesures sur le terrain

Il existe deux façons de mesurer, et les confondre mène à des réunions pénibles.

La mesure en laboratoire simule une visite dans des conditions fixées d'avance, avec un appareil et un réseau choisis. C'est ce que fait Lighthouse, l'outil intégré au navigateur Chrome. C'est reproductible, donc idéal pour comparer avant et après une optimisation.

La mesure sur le terrain agrège ce que vivent les vrais visiteurs, avec leurs vrais téléphones et leurs vraies connexions. C'est cette donnée que Google utilise pour son classement, et elle est souvent bien moins flatteuse que le laboratoire. Une note de 95 sur 100 sur ton MacBook en fibre ne dit rien de l'expérience d'un visiteur en 4G capricieuse avec un téléphone de quatre ans.

Les solutions

Côté images

Les images représentent souvent plus de la moitié du poids d'une page, et c'est donc le levier le plus rentable.

• Utiliser des formats modernes comme WebP ou AVIF, qui produisent des fichiers nettement plus légers que le JPEG à qualité équivalente. Le gain dépend beaucoup de l'image, mais il se compte en dizaines de pour cent.
• Adapter la taille de l'image à l'écran. Inutile d'envoyer une image de 4000 pixels de large à un téléphone qui n'en affichera que 400. Les navigateurs savent choisir tout seuls parmi plusieurs versions si on les leur fournit.
• Utiliser le lazy loading, c'est-à-dire ne charger les images que lorsque l'utilisateur fait défiler la page jusqu'à elles. Attention toutefois à ne jamais l'appliquer à l'image principale du haut de page, sous peine de dégrader le LCP au lieu de l'améliorer.
• Réserver la place des images en indiquant leurs dimensions, ce qui évite les sauts de mise en page et donc le mauvais CLS.

Côté code

• La minification, qui supprime les espaces et les commentaires et raccourcit les noms de variables dans les fichiers CSS et JavaScript. Un fichier peut y perdre la moitié de son poids sans rien changer à son comportement.
• Le code splitting, qui découpe le JavaScript en morceaux pour ne charger que celui dont la page en cours a réellement besoin.
• La compression, gzip ou brotli, où le serveur compresse les fichiers avant de les envoyer et où le navigateur les décompresse à l'arrivée. Sur du texte, le gain est spectaculaire et la mise en place ne prend que quelques lignes de configuration.
• Le chargement différé des scripts non essentiels, pour que le chat en ligne et le pixel publicitaire cessent de retarder l'affichage du contenu.

Côté infrastructure

Comme nous l'avons vu dans les chapitres sur le cache et sur les CDN, la plus grande optimisation reste de ne pas refaire un travail déjà fait.

• Mettre en cache les ressources statiques pour éviter de les retélécharger à chaque visite.
• Mettre en cache côté serveur les pages ou les résultats de requêtes coûteuses, plutôt que de les recalculer pour chaque visiteur.
• Utiliser un CDN pour servir les fichiers depuis un point de présence géographiquement proche de l'utilisateur.
• Servir le site en HTTP/2 ou HTTP/3, ce qui est aujourd'hui une simple case à cocher chez la plupart des hébergeurs.

Mesurer et surveiller

Deux outils suffisent pour commencer, et ils sont gratuits. PageSpeed Insights, accessible depuis n'importe quel navigateur, analyse une URL et affiche à la fois les mesures de laboratoire et, si le site a assez de trafic, les mesures issues des vrais utilisateurs de Chrome. Lighthouse, intégré aux outils de développement du navigateur, fait la même analyse en local et classe les recommandations par impact estimé.

L'erreur classique consiste à faire une passe d'optimisation, à célébrer le score, puis à laisser le site se réalourdir tranquillement pendant deux ans. La performance est un acquis fragile, chaque nouvelle fonctionnalité ajoute son poids. La parade s'appelle le budget de performance, une limite fixée d'avance, par exemple un poids maximal de page ou un LCP à ne pas dépasser, que l'on vérifie automatiquement à chaque livraison via la chaîne d'intégration continue.

Méfie-toi du score sur 100 affiché par ces outils. Il est utile comme repère, mais il agrège des critères pondérés arbitrairement et il varie d'une exécution à l'autre. Ce qui compte, ce sont les trois indicateurs mesurés sur tes vrais visiteurs, pas la couleur du camembert.

Performance et référencement

Google utilise les Core Web Vitals comme critère de classement, et c'est souvent l'argument qui débloque un budget d'optimisation en réunion. Il faut cependant garder le sens des proportions. La pertinence du contenu pèse infiniment plus lourd qu'une demi-seconde de LCP, et un site rapide qui ne répond pas à la question de l'internaute ne remontera jamais. La performance départage deux pages de qualité comparable, elle ne rattrape pas un contenu médiocre. Nous avons détaillé ce classement dans le chapitre sur le référencement.

Le vrai argument est ailleurs, et il est plus simple. Une page rapide respecte le temps et le forfait data de la personne qui la consulte. C'est aussi, accessoirement, une question d'accessibilité, car les visiteurs aux connexions lentes et aux appareils modestes sont précisément ceux qu'on oublie quand on développe depuis un bureau bien équipé.