Les trois métriques et ce que chacune attrape
Chaque métrique couvre une façon différente dont une page peut mal se comporter, et elles échouent indépendamment. Une page peut charger vite et pourtant se dérober sous le pouce du lecteur ; une page peut être parfaitement stable et mettre quatre secondes à afficher quoi que ce soit.
| Métrique | Couvre | Bon | À corriger au-delà de |
|---|---|---|---|
| LCP | Chargement | ≤ 2,5 s | 4,0 s |
| INP | Réactivité | ≤ 200 ms | 500 ms |
| CLS | Stabilité visuelle | ≤ 0,1 | 0,25 |
Largest Contentful Paint marque l'instant où le plus grand élément de la fenêtre finit de s'afficher — le plus souvent une image d'en-tête ou un bloc de titre. C'est le substitut de « la page a l'air arrivée », et c'est pour cela qu'il l'emporte sur des marqueurs plus anciens comme le premier affichage : une image blanche peinte vite n'est pas une page chargée vite.
Interaction to Next Paint a remplacé First Input Delay comme Core Web Vital stable en mars 2024, et le remplacement comptait. FID ne mesurait que le délai avant le traitement de la première interaction, ce qui flattait les pages répondant vite au premier appui puis s'enlisant. INP considère la latence complète des interactions sur toute la visite et rapporte une valeur proche de la pire.
Cumulative Layout Shift mesure le contenu qui bouge après avoir été affiché. C'est la métrique derrière l'expérience universelle qui consiste à viser un lien et à toucher une publicité arrivée juste en dessous. Comme il s'agit d'un score et non d'une durée, un seul décalage sévère en fin de page peut dominer le chiffre.
Évalué au 75e centile, sur des données de terrain
C'est la partie qui prend les équipes de court. L'évaluation utilise le 75e centile des chargements sur une fenêtre glissante de 28 jours, segmentée séparément pour mobile et ordinateur. Une médiane confortable avec une queue lente échoue quand même, et c'est voulu. La métrique parle du quart de visiteurs qui souffre le plus, pas du visiteur typique.
Cela signifie aussi que les données viennent du terrain, récoltées sur des visites réelles, et non d'une exécution en laboratoire. Les outils de laboratoire sont des instruments de diagnostic : ils vous disent quelle ressource retient l'affichage, et c'est l'outil qu'il faut pour cela. Ils ne constituent pas l'évaluation, et un score vert en laboratoire à côté d'une évaluation de terrain en échec n'est pas une contradiction — cela veut dire que vos vrais visiteurs ne sont pas sur la machine depuis laquelle vous avez testé.
Ce qui fait vraiment bouger chaque métrique
Les causes sont peu spectaculaires et se répètent d'un site à l'autre. L'essentiel du travail consiste à décider ce que le navigateur doit avoir avant le premier affichage utile, et à refuser à tout le reste une place dans cette file.
| Métrique | Cause habituelle | Correction habituelle |
|---|---|---|
| LCP | Réponse serveur lente | Mettre le document en cache ; raccourcir les redirections |
| LCP | Image d'en-tête découverte tard | La précharger ; jamais de chargement différé |
| LCP | CSS ou polices bloquant l'affichage | CSS critique en ligne ; utiliser font-display |
| INP | Longues tâches JavaScript sur le fil principal | Les découper ; différer le travail non essentiel |
| INP | Scripts tiers lourds | Les charger tard, ou les supprimer |
| CLS | Images et intégrations sans dimensions | Fixer width et height, ou aspect-ratio |
| CLS | Polices qui permutent et recomposent le texte | Aligner les métriques de repli ; précharger la fonte |
| CLS | Bandeaux insérés au-dessus du contenu | Réserver la place avant qu'elle se remplisse |
Les scripts tiers méritent une mention à part, car ils sont la cause la plus fréquente d'un problème d'INP et celle dont personne n'assume la charge. Chaque balise ajoutée pour la mesure, le chat, les tests ou le consentement se dispute le fil principal dont l'appui du lecteur a besoin. La bonne question d'audit n'est pas de savoir si chacune est utile, mais ce qu'elle coûte au 75e centile.
La place de l'expérience de page parmi les signaux
Google indique que ses principaux systèmes de classement utilisent les Core Web Vitals, mais qu'il n'existe pas de « signal d'expérience de page » unique. La pertinence reste prioritaire, et de bons Core Web Vitals ne garantissent pas une première position.
Donnez la priorité aux problèmes rencontrés par les utilisateurs, en particulier sur les modèles importants, sans considérer un seuil de réussite comme une garantie de classement. Une page pertinente avec une mauvaise expérience peut toujours être classée ; une page rapide qui manque la requête ne devient pas pertinente car elle est rapide.
Un ordre de marche qui tient
Si vous partez d'une évaluation en échec, cette séquence évite le gaspillage le plus courant : peaufiner ce qui passe déjà, ou réparer une page sans trafic.
- Lisez d'abord les données de terrain, séparées mobile et ordinateur. Le mobile échoue souvent seul, et réparer l'ordinateur ne change rien.
- Cherchez quelle métrique échoue et sur quels groupes de pages. Les gabarits échouent ensemble ; une URL isolée dit rarement grand-chose.
- Reproduisez la cause en laboratoire, sur une connexion bridée. Le laboratoire dit ce qui est lent ; le terrain avait dit que cela comptait.
- Corrigez le plus gros contributeur et livrez. Ces métriques bougent par améliorations partielles ; il y a rarement un seul interrupteur.
- Attendez la fenêtre de 28 jours avant de juger. L'évaluation est une moyenne glissante : une correction livrée aujourd'hui apparaît progressivement.