Core Web Vitals : pourquoi un site lent vous coûte des clients

La performance web n'est pas un sujet d'ingénieurs. C'est un sujet commercial : au-delà de trois secondes de chargement, une part significative des visiteurs abandonne avant même d'avoir vu votre offre. Google mesure cette expérience à travers trois indicateurs, les Core Web Vitals, et les intègre à son classement.

Les trois métriques et leurs seuils

LCP : Largest Contentful Paint. Le temps avant l'affichage du plus grand élément visible, généralement l'image ou le titre du hero. Bon : moins de 2,5 s.

INP : Interaction to Next Paint. Le délai entre un clic et la réaction visible de la page. Il a remplacé le FID en 2024 et il est plus sévère. Bon : moins de 200 ms.

CLS : Cumulative Layout Shift. La quantité de mouvement inattendu de la mise en page pendant le chargement : le bouton qui se déplace au moment où vous cliquez. Bon : moins de 0,1.

Ces seuils sont mesurés sur les données réelles de vos visiteurs, pas en laboratoire. Un score parfait sur votre fibre professionnelle ne dit rien de l'expérience en 4G dans un train.

Les causes qu'on retrouve systématiquement

Dans la grande majorité des audits, les mêmes coupables reviennent :

• Des images non optimisées. Une photo de 3 Mo servie en pleine résolution pour être affichée dans un cadre de 400 px. Le passage en WebP ou AVIF, avec les bonnes dimensions, divise souvent le poids par dix.
• Des polices bloquantes. Une police web chargée sans font-display: swap masque le texte pendant tout son téléchargement.
• Les scripts tiers. Un chat en direct, deux outils d'analyse, un pixel publicitaire et une bannière de cookies : chacun ajoute des dizaines de kilooctets de JavaScript exécuté avant que la page ne réagisse. C'est la première cause de mauvais INP.
• L'absence de dimensions sur les images. Sans width et height, le navigateur ne réserve pas la place : le contenu saute quand l'image arrive. C'est le CLS.
• Un hébergement mutualisé saturé. Aucune optimisation front-end ne compense un serveur qui met 800 ms à répondre.

Par où commencer

L'ordre a de l'importance, parce que les gains ne sont pas égaux :

1. Mesurer le réel : PageSpeed Insights donne les données terrain (CrUX) en plus du laboratoire. Ce sont les données terrain qui comptent.
2. Traiter les images : presque toujours le plus gros gain pour le moins d'effort.
3. Auditer les scripts tiers : retirer un outil d'analyse redondant coûte zéro et rapporte beaucoup.
4. Réserver l'espace des images, iframes et bannières.
5. Vérifier le temps de réponse serveur (TTFB) avant d'optimiser quoi que ce soit d'autre.

Le vrai principe

La performance ne se rattrape pas à la fin d'un projet. Un site rapide est un site dont on a refusé, à chaque étape, d'ajouter du poids sans raison : une police de plus, une bibliothèque de carrousel pour trois images, un script pour animer un compteur.

C'est une discipline de conception, pas une phase d'optimisation.