Si vous avez recherché « évaluation Core Web Vitals : échec » malgré un score de vitesse vert, commencez par vérifier quelles données décrit chaque résultat. PageSpeed Insights (PSI) associe des observations de visites réelles à un test contrôlé distinct. Notez l’adresse, l’appareil, le périmètre des données et la métrique en échec avant d’acheter un outil ou de demander une refonte du site.
Nous commençons par ces informations, car « passer le score au vert » laisse trop de questions ouvertes. Le développeur doit savoir quelle expérience améliorer et quels éléments permettront de juger la correction utile.
Évaluation Core Web Vitals : échec, qu’a mesuré le rapport ?
L’évaluation décrit les expériences enregistrées des visiteurs, tandis que la section Lighthouse exécute un test de diagnostic. La documentation de Google sur PageSpeed Insights précise que les données terrain proviennent du Chrome User Experience Report, ou CrUX, sur une période de collecte glissante de 28 jours. Un nouveau test de diagnostic et cet historique peuvent donc donner des résultats différents.
Les conditions de test diffèrent. Un test contrôlé ne peut pas couvrir tous les appareils, connexions et gestes des visites réelles. Utilisez-le pour examiner une cause possible, tout en conservant les données visiteurs à ses côtés pour déterminer ce qui reste à résoudre.
Le résultat peut couvrir un périmètre plus large. Lorsque les données de la page précise sont trop peu nombreuses, PSI peut utiliser celles de l’origine, soit, dans les grandes lignes, la même adresse de site avec son protocole et son nom d’hôte. Un résultat à l’échelle de l’origine regroupe des visites de plusieurs pages. Lisez le périmètre affiché avant d’en faire une preuve concernant une page produit ou service particulière.
La période inclut des visites anciennes. Une modification apportée aujourd’hui ne réécrit pas les observations d’hier. Conservez sa date de mise en ligne pour distinguer la vérification immédiate de la correction des observations ultérieures des visiteurs.
Ces différences donnent aux rapports des rôles distincts : les observations visiteurs désignent une expérience à examiner ; le test contrôlé aide à la reproduire et à l’étudier.
Quelle métrique demande une intervention ?
Examinez LCP, INP et CLS séparément avant de choisir une correction. Le guide Web Vitals de Google distingue chargement, réactivité et stabilité visuelle. Le tableau ci-dessous reprend ses seuils « bon », évalués au 75e percentile pour la population d’appareils concernée. Le guide de Google sur les seuils explique ce percentile : au moins 75 % des pages vues mesurées doivent atteindre le seuil « bon » pour la métrique considérée. Cela diffère d’une moyenne ou du score global Lighthouse.
| Métrique | Ce qu’elle décrit | Seuil « bon » | Question à poser au responsable technique |
|---|---|---|---|
| LCP, Largest Contentful Paint | Le moment où apparaît le plus grand élément de contenu visible | Au plus 2,5 secondes | Quel élément est retardé et à quelle étape de son chargement ? |
| INP, Interaction to Next Paint | La rapidité de réaction de la page aux interactions | Au plus 200 millisecondes | Quel toucher, clic ou appui sur une touche est lent dans les conditions concernées ? |
| CLS, Cumulative Layout Shift | Les déplacements inattendus de la mise en page | Au plus 0,1 | Quel élément se déplace et à quel moment de la visite ? |
Lorsque toutes ces métriques disposent de données suffisantes, PSI exige que leurs valeurs au 75e percentile soient bonnes pour valider l’évaluation. Si les données INP sont insuffisantes, de bons LCP et CLS peuvent néanmoins permettre une validation. Si les données LCP ou CLS sont insuffisantes, PSI ne peut pas évaluer cette page ou cette origine.
Traitez les données manquantes comme une incertitude. La méthodologie CrUX de Google exige des visites éligibles et une popularité suffisante ; elle ne publie aucun nombre minimal universel de visiteurs. L’absence de résultat ne signifie ni que personne ne visite la page, ni que l’expérience est bonne, ni qu’une correction a échoué.
Que pouvez-vous vérifier avant de payer des travaux ?
Enregistrez un rapport de référence et suivez le même parcours client sur un téléphone avant de choisir un outil. Il vous faut une description claire du problème : la page, les données à l’origine de l’alerte et le comportement que vous pouvez reproduire. Si vous n’arrivez pas à le reproduire, notez cette limite au lieu de combler le manque par une supposition.
- Ouvrez la page métier précise dans PSI. Conservez son adresse et la date du rapport. Incluez la page de destination ou le modèle de page qui compte pour la demande ou l’achat étudié.
- Notez le choix mobile ou ordinateur et le périmètre des données. Relevez si la section terrain représente l’URL, l’origine ou des données insuffisantes. Gardez la même sélection pour les comparaisons ultérieures.
- Nommez la métrique à traiter. Partez des résultats individuels des Core Web Vitals, puis cherchez des indices dans la section de diagnostic. Laissez apparaître les mesures manquantes.
- Effectuez une vraie tâche sur un téléphone. Ouvrez le menu, utilisez le filtre concerné ou remplissez le formulaire utile. Notez ce qui charge tard, répond lentement ou se déplace de façon inattendue.
- Reliez un indice à un test. Demandez au responsable technique de reproduire l’action ou le retard de chargement concerné et d’expliquer ce que le test peut établir.
Pour vérifier plus largement images, widgets, cache et hébergement, consultez notre guide des causes fréquentes d’un site lent. Gardez cette intervention centrée sur l’échec de l’évaluation et sur les éléments nécessaires pour juger une correction.
Que doit comprendre la correction ?
Choisissez la modification la plus limitée que justifie le diagnostic, puis convenez de la façon de la vérifier. Commencez avec les rapports et fonctionnalités déjà disponibles. Les travaux techniques deviennent plus faciles à évaluer lorsque le responsable nomme la page ou le modèle concerné, explique le point de blocage et maintient des conditions comparables avant et après la modification.
- Reliez la proposition à la métrique. Le guide LCP de web.dev distingue les délais de réponse, de découverte, de chargement et de rendu du plus grand élément. Son guide INP concentre l’enquête sur les interactions lentes. Le guide CLS inclut les déplacements survenant après le chargement initial. Demandez les éléments pertinents plutôt qu’une promesse générale d’amélioration de la vitesse.
- Corrigez la cause identifiée et testez à nouveau le comportement. Une intervention ciblée sur une ressource ou un modèle peut relever du développement et de la maintenance de sites web. Consignez ce qui a changé et quand, ainsi que la manière de revenir en arrière lorsque c’est possible.
- Vérifiez que la tâche du client fonctionne toujours. Testez la navigation, les formulaires et les étapes d’achat pertinentes pour la page. Maintenez le bon fonctionnement des mécanismes de consentement ; examinez leur comportement et leur mise en page en préservant un consentement conforme au droit.
- Décidez si d’autres données sont nécessaires. Si les rapports disponibles ne permettent pas d’identifier l’interaction ou la page touchée, des mesures supplémentaires peuvent aider. Demandez à quelle question répond la surveillance proposée avant d’ajouter un service payant.
Si la priorité technique reste floue, une prestation de SEO technique peut commencer par un diagnostic et une liste de travaux vérifiable. Une refonte ou un forfait d’optimisation demande sa propre justification.
Vous pouvez copier cette fiche d’intervention et laisser vides les champs inconnus :
Page et tâche métier :
Appareil et périmètre des données terrain :
Métrique à traiter :
Comportement observé et conditions de test :
Cause envisagée et modification proposée :
Date de mise en ligne :
Vérification comparable après modification :
Observation terrain ultérieure et incertitude restante :Comment vérifier que les travaux ont aidé ?
Examinez d’abord le comportement modifié, puis comparez les observations terrain ultérieures à périmètre égal. D’après sa documentation, PSI actualise ses données terrain quotidiennement tout en conservant une fenêtre de collecte glissante. Gardez la date de mise en ligne dans votre relevé. Cette fenêtre ne constitue pas un compte à rebours garanti jusqu’à une évaluation réussie.
Comparez la métrique ciblée et la tâche du client dans des conditions de test similaires. Si le symptôme persiste, reprenez le diagnostic. Si le test s’améliore mais que les observations terrain ultérieures ne confirment pas l’effet de la modification, examinez à nouveau les pages touchées et les conditions des visiteurs. L’absence de données terrain doit rester une limite explicite.
Notre rôle
Nous partons du rapport, des pages importantes et d’une tâche que nous pouvons reproduire. Nous distinguons la correction proposée, sa vérification et les observations ultérieures des visiteurs afin que chaque décision repose sur une base que vous pouvez examiner. Un brief sur les performances de votre site peut commencer par la fiche ci-dessus ; laissez visibles les champs inconnus.
