Réussir les Core Web Vitals : guide pratique

Si votre score Lighthouse est à 98 et que la Search Console affiche toujours « à améliorer », rien n'est cassé. Vous lisez deux mesures différentes, et une seule compte.

Nous avons expliqué pourquoi la vitesse est un levier de croissance. Voici la suite pratique : comment réussir concrètement.

D'abord, ce que la plupart des équipes se trompent

Lighthouse est un test de laboratoire. Les Core Web Vitals sont des données de terrain.

Lighthouse s'exécute sur un appareil simulé, depuis votre machine, à la demande. Les Core Web Vitals proviennent de vrais utilisateurs Chrome, sur de vrais appareils et de vrais réseaux, agrégés sur une fenêtre glissante de 28 jours, et vous êtes évalué au 75e centile — trois visites sur quatre doivent atteindre la cible.

Trois conséquences qui expliquent l'essentiel de la confusion :

1. Votre moyenne ne compte pas. Il faut corriger le quart le plus lent. Une médiane rapide avec une traîne lente échoue quand même. Optimiser pour votre propre portable rapide, c'est optimiser le mauvais bout de la distribution.
2. Les corrections mettent des semaines à apparaître. Déployez aujourd'hui : la fenêtre de 28 jours contient encore quatre semaines d'anciennes données. Rien d'anormal — patientez.
3. Les outils de laboratoire servent au diagnostic, les données de terrain à la note. Utilisez Lighthouse pour trouver les causes, pas pour décider si vous avez réussi.

Les cibles, au 75e centile : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.

LCP : quel élément, puis quelle phase ?

Le Largest Contentful Paint mesure l'apparition du contenu principal. Deux étapes, dans cet ordre.

Étape un : identifier l'élément. Généralement l'image de couverture ou le titre. Tous les outils de développement vous le nomment. Ne devinez pas — les équipes optimisent régulièrement une image qui n'est pas l'élément LCP.

Étape deux : déterminer quelle phase est lente. Le LCP se décompose en quatre, et la correction dépend entièrement de celle qui domine :

L'erreur la plus fréquente : différer le chargement de l'image LCP. C'est un réglage global facile à appliquer, et sur l'image de couverture il retarde directement la métrique évaluée. Tout ce qui est au-dessus de la ligne de flottaison doit se charger immédiatement, et la couverture devrait généralement être préchargée.

Deuxième erreur la plus fréquente : une couverture qui attend JavaScript pour s'afficher. Si le plus grand élément n'existe qu'après hydratation, le LCP inclut tout cela. Rendez-le côté serveur.

INP : libérer le fil principal

L'Interaction to Next Paint mesure la réactivité de la page au tap ou au clic. Il a remplacé le FID avec une définition bien plus stricte : il mesure toutes les interactions, pas seulement la première, et couvre tout le chemin jusqu'à la mise à jour visuelle.

La cause est presque toujours trop de JavaScript sur le fil principal :

• Les tâches longues. Toute tâche dépassant 50 ms retarde chaque interaction qui survient pendant. Découpez le travail et rendez la main entre les morceaux.
• Le coût de l'hydratation. Une page qui hydrate un large arbre interactif reste insensible pendant ce temps, quelle que soit sa rapidité d'affichage.
• Les gestionnaires d'événements coûteux. Du travail exécuté de façon synchrone dans un clic avant le rendu. Mettez d'abord l'interface à jour, faites le travail ensuite.
• Les scripts tiers. Widgets de chat, gestionnaires de balises, outils d'A/B testing. Auditez-les honnêtement : ils sont souvent le premier contributeur et le moins examiné.

La correction structurelle consiste à livrer moins de JavaScript : rendre côté serveur et n'hydrater que ce qui doit réellement être interactif.

CLS : réserver la place

Le Cumulative Layout Shift mesure les mouvements inattendus. C'est généralement le plus simple à corriger, et il provient d'une courte liste :

• Images et vidéos sans dimensions. Définissez width et height explicites (ou un ratio) pour que le navigateur réserve la place avant l'arrivée du fichier. Cela seul règle l'essentiel du CLS.
• Publicités, intégrations et iframes sans conteneur réservé.
• Bandeaux injectés en haut de page — les avis cookies en particulier. Superposez-les, ou réservez leur hauteur.
• Les polices. Une police de repli aux métriques différentes fait bouger le texte au chargement de la police web. Utilisez font-display: swap avec un repli aux métriques proches, ou préchargez la police.
• Contenu inséré au-dessus du contenu existant après chargement. Si c'est indispensable, insérez sous la ligne de flottaison ou réservez la place.

Notez que le CLS s'accumule pendant toute la vie de la page, pas seulement au chargement. Un décalage provoqué par du contenu différé à mi-page compte aussi.

L'ordre de travail

1. Récupérez les données de terrain. Le rapport Core Web Vitals de la Search Console, groupé par motif d'URL. Corrigez d'abord le motif qui touche le plus de pages.
2. Corrigez le CLS. Le moins cher, le plus mécanique, le plus rapide à vérifier.
3. Corrigez le LCP. Identifiez l'élément, trouvez la phase dominante, corrigez cette phase seulement.
4. Corrigez l'INP. Généralement le plus difficile, car il s'agit de livrer moins de JavaScript, pas de régler un paramètre.
5. Attendez. Quatre semaines minimum avant de juger du résultat.

Testez sur un téléphone Android de milieu de gamme avec une connexion bridée, pas sur votre portable. C'est bien plus proche du 75e centile de votre trafic réel, c'est-à-dire du chiffre sur lequel vous êtes noté.

Intégrer plutôt que rajouter

Greffer la performance après coup coûte cher et n'aboutit que rarement complètement. Un rendu orienté serveur, un JavaScript discipliné et des images correctement dimensionnées dès le départ ne coûtent presque rien pendant le projet et sont pénibles à ajouter ensuite — le même argument que tout ce que le devis le moins cher omet.

Si vous voulez un diagnostic de la métrique réellement en échec et de sa cause, plutôt qu'un audit générique, c'est un travail que nous faisons. Découvrez notre approche du développement web, ou contactez-nous.