La plupart des équipes découvrent les Core Web Vitals comme un bulletin de notes. Un outil fait passer trois lettres au rouge, on demande à quelqu'un de redresser le score avant le lancement, quelques images sont compressées, et tout le monde passe à autre chose. Le score repasse au vert et la leçon est complètement ratée.

La performance n'est pas une note qu'on remonte à la fin. C'est une propriété de la façon dont le produit est construit, et elle se dégrade dès l'instant où vous cessez d'y prêter attention. Les équipes dont les sites restent rapides ne sont pas celles qui réussissent le meilleur audit de dernière minute. Ce sont celles qui ont traité la vitesse comme une fonctionnalité dès le premier commit.

Ce que veulent vraiment dire ces trois lettres

Les vitals ne sont pas arbitraires. Le Largest Contentful Paint demande combien de temps il faut avant que l'élément principal apparaisse. Le Cumulative Layout Shift demande si la page sautille pendant son chargement. L'Interaction to Next Paint demande si la page réagit quand un utilisateur la touche réellement. Retirez les acronymes et tous posent la même question humaine. Est-ce que ça donne une impression de rapidité et de stabilité à une vraie personne, sur un vrai téléphone.

Ce recadrage compte, car il transforme un score abstrait en quelque chose que l'on ressent. Vous n'avez pas besoin d'un tableau de bord pour remarquer une page qui tressaute en se chargeant. Vos utilisateurs encore moins.

Un bon score sur un ordinateur portable rapide n'est pas un résultat. C'est une façon de se mentir à soi-même.

Où passent réellement les secondes

Quand une page est lente, la cause est rarement un mystère, et c'est rarement celle vers laquelle on se tourne en premier. Ce sont des images livrées bien plus grandes que leur taille d'affichage. C'est une mise en page qui se décale parce que rien n'a réservé d'espace pour une image ou une police. C'est le thread principal qui s'étrangle sous du JavaScript dont la page n'avait pas encore besoin. C'est un script tiers, ajouté pour satisfaire un seul interlocuteur, qui tire toute l'expérience vers le bas.

Aucun de ces problèmes ne se règle par une unique optimisation héroïque. Ils se règlent par cent petits choix par défaut. Dimensionnez vos images. Réservez de l'espace pour tout ce qui charge tardivement. Envoyez moins de JavaScript. Soyez impitoyable avec les scripts tiers. La vitesse est la somme de décisions, pas un interrupteur.

Mesurez là où sont vos utilisateurs

Le mensonge le plus courant qu'on se raconte en travaillant sur la performance, c'est de tester sur la mauvaise machine. Le site paraît instantané sur l'ordinateur du développeur, en wifi de bureau, donc tout doit aller bien. Puis il arrive entre les mains de quelqu'un avec un téléphone de trois ans sur une connexion capricieuse, qui est l'utilisateur réel, et il rame.

Mesurez sur le matériel et le réseau dont dispose votre vrai public. Les chiffres qui comptent viennent du terrain, pas du laboratoire. Un score de laboratoire est un test de fumée. Les données de terrain sont la vérité.

Intégrez-la, ne la rajoutez pas par-dessus

La raison pour laquelle la performance devrait être une fonctionnalité et non un audit final, c'est que le moment le moins cher pour être rapide, c'est pendant la construction. Choisir la bonne stratégie d'images dès le départ ne coûte rien. La réintégrer dans un site terminé coûte un sprint. Réserver l'espace de mise en page au fil de la construction est une habitude. Traquer chaque décalage après coup est une chasse au trésor.

Nous traitons donc les vitals comme des critères d'acceptation, et non comme une tâche de nettoyage. Une fonctionnalité n'est pas terminée quand elle marche. Elle est terminée quand elle marche et qu'elle est rapide sur l'appareil que votre utilisateur tient réellement en main. Faites-en votre définition du « terminé » et le bulletin de notes se gère tout seul, durablement, au lieu de repasser au rouge dès que vous regardez ailleurs.