Un audit Core Web Vitals mené sérieusement prend deux heures. Fait correctement, il vous livre trois chiffres, une liste de coupables et un plan d'action priorisé. Fait à la hâte, il produit un score PageSpeed Insights pris en capture d'écran, sans rien comprendre de ce qui tire vos métriques vers le bas.
Ce guide déroule la méthode que j'applique lorsque j'audite un site, étape par étape, en commençant par les données qui comptent vraiment pour Google.
Comprendre les trois métriques Core Web Vitals
Les Core Web Vitals sont trois signaux de performance définis par Google. Ils mesurent l'expérience réelle de vos visiteurs sur trois dimensions : vitesse de chargement, réactivité aux interactions et stabilité visuelle. Les seuils officiels publiés par Google sont les suivants.
| Métrique | Mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Chargement du plus grand élément visible | ≤ 2,5 s | 2,5 à 4 s | > 4 s |
| INP (Interaction to Next Paint) | Réactivité aux interactions utilisateur | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle de la mise en page | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
Le seuil s'applique au 75e percentile de vos visiteurs : 75 % des chargements de page doivent atteindre le niveau "bon" pour que l'URL soit classée performante par Google. Cette notion de percentile change tout, parce qu'un site rapide en laboratoire peut échouer sur le terrain si une minorité d'utilisateurs mobiles fait exploser la distribution.
Depuis le 12 mars 2024, INP a remplacé le First Input Delay comme métrique officielle. Ce changement rend l'audit plus exigeant, car INP mesure l'ensemble des interactions d'une session, pas seulement la première.
Étape 1, collecter les données terrain dans la Search Console
Un audit Core Web Vitals commence toujours par Google Search Console. C'est là que vous trouvez les données CrUX (Chrome User Experience Report), les seules utilisées par Google pour le classement.
Rendez-vous dans le rapport "Core Web Vitals" sous "Expérience", puis ouvrez successivement l'onglet Mobile et l'onglet Desktop. Google y regroupe vos URL par score. Les catégories à surveiller sont "Médiocre" et "À améliorer", parce que ce sont elles qui pénalisent votre ranking. Cliquez sur chaque problème détecté pour afficher la liste des URL concernées et la métrique fautive.
Une erreur que je vois souvent : se limiter à la homepage. La Search Console regroupe les URL par gabarit similaire, mais chaque template (homepage, article, fiche produit, page service) peut avoir des signaux différents. Auditez chaque type de page, pas seulement celle qui ressort en premier.
Si la Search Console n'affiche pas encore de données, deux hypothèses : votre site n'a pas assez de trafic pour alimenter CrUX (environ 150 visites Chrome par 28 jours sont nécessaires par URL regroupée), ou la propriété est trop récente. Dans ce cas, basculez directement sur PageSpeed Insights pour un premier diagnostic.
Étape 2, diagnostiquer chaque métrique avec PageSpeed Insights
PageSpeed Insights combine données terrain CrUX et analyse laboratoire Lighthouse. Testez au minimum trois URL représentatives : une homepage, un article et une page de service ou de catégorie. Les résultats diffèrent quasiment toujours.
Un point crucial sur l'interprétation : la section "Découvrez ce que ressentent vos utilisateurs" en haut du rapport contient les données terrain sur 28 jours. C'est ce que Google utilise pour vous classer. La section "Diagnostiquer les problèmes de performance" en dessous est une simulation laboratoire, utile pour identifier les causes mais pas pour juger votre SEO.
Analyser le LCP
Cherchez la ligne "Largest Contentful Paint" dans le détail. PageSpeed Insights identifie précisément l'élément déclencheur, souvent une image hero ou un bloc de texte principal. Regardez ensuite la décomposition LCP en quatre phases : TTFB (réponse serveur), délai de chargement, durée de téléchargement, délai de rendu. La phase dominante vous indique le levier prioritaire.
Un TTFB supérieur à 800 ms rend quasi impossible un LCP inférieur à 2,5 secondes, peu importe les optimisations d'images que vous appliquerez ensuite. Commencez toujours par là.
Analyser l'INP
INP est la métrique la plus délicate à auditer, parce qu'elle nécessite de l'interaction réelle. Le rapport PageSpeed Insights affiche votre score terrain, mais ne détaille pas quelle interaction spécifique pose problème. Pour ça, installez l'extension Chrome Web Vitals (gratuite, maintenue par Google), puis naviguez sur votre site en cliquant, tapant, scrollant. L'extension remonte en temps réel la durée de chaque interaction.
Les coupables habituels : scripts d'analytics lourds, gestionnaires de consentement mal optimisés, filtres de recherche qui recalculent le DOM à chaque frappe, animations déclenchées au clic qui bloquent le thread principal.
Analyser le CLS
Le CLS est souvent le plus simple à corriger, mais il nécessite un œil attentif. Dans PageSpeed Insights, la section "Éviter les décalages de mise en page importants" liste les éléments responsables. Les coupables classiques : images sans dimensions width et height, publicités injectées dynamiquement, polices web sans font-display: swap, bannières cookies qui poussent le contenu vers le bas.
Un test visuel rapide : enregistrez une vidéo de chargement sur mobile en 3G simulé (DevTools > Network > Slow 3G). Si vous voyez du contenu sauter pendant les deux premières secondes, votre CLS est élevé.
Étape 3, prioriser les corrections avec un tableau d'impact
Une fois les trois métriques diagnostiquées, résistez à la tentation de tout corriger en même temps. Un audit Core Web Vitals utile se traduit par une liste priorisée par ratio impact/effort.
Ma grille personnelle sur une centaine d'audits :
- Gain rapide (moins d'une heure) : ajouter
widthetheightsur les images, passer l'image LCP enfetchpriority="high", ajouterdeferaux scripts non critiques, activerfont-display: swap. - Gain modéré (demi-journée) : inliner le CSS critique, compresser les images en WebP ou AVIF, réserver de l'espace fixe pour les publicités et iframes, différer les scripts d'analytics via
requestIdleCallback. - Gain structurel (projet dédié) : migration vers un CDN, mise en cache serveur, refonte du JavaScript pour découper les tâches longues, pré-rendu statique des pages les plus consultées.
Sur mon propre site matthieutexier.fr, l'audit que j'ai mené en mars 2026 a identifié quatre chantiers prioritaires : preload de l'image LCP, preconnect sur googletagmanager.com, différer GA4 via requestIdleCallback, et suppression de will-change: border-radius sur les animations. Les trois premiers actions ont gagné un estimé de 300 à 500 ms sur le LCP mobile, pour environ une heure de travail cumulé.
Étape 4, valider en laboratoire avec Lighthouse
Après chaque correction, validez en laboratoire avec Lighthouse (Chrome DevTools > onglet Lighthouse). Cochez "Performance" et lancez un audit en mode mobile avec throttling 4G simulé, qui reflète les conditions réelles de la majorité de vos visiteurs.
Pour INP spécifiquement, Lighthouse propose depuis 2024 un mode "Timespan" qui enregistre les interactions pendant votre navigation. Cliquez "Start timespan", interagissez avec votre page pendant 10 à 15 secondes, puis stoppez l'enregistrement. Le rapport détaille chaque interaction et sa durée.
Attention : les données laboratoire et terrain divergent souvent. Lighthouse simule un appareil mobile moyen avec une connexion standardisée, alors que vos vrais utilisateurs couvrent une distribution bien plus large. Un score Lighthouse à 95 avec un terrain CrUX à 60 signifie simplement que vos utilisateurs réels ont des conditions plus difficiles que le test. Pour un audit plus large couvrant l'ensemble de la couche technique, le guide sur l'audit technique SEO décrit la méthode complète dont les Core Web Vitals ne sont qu'un pilier.
Étape 5, suivre l'impact sur 28 jours
Le piège final de l'audit Core Web Vitals, c'est l'impatience. Google utilise les données CrUX collectées sur 28 jours glissants. Après une optimisation, il faut environ un mois pour que les nouvelles données remplacent les anciennes dans le rapport Search Console et dans PageSpeed Insights.
Ma méthode pour suivre l'impact sans céder à la tentation de "voir trop tôt" :
- Noter les scores terrain avant déploiement (date, LCP, INP, CLS, URL testées).
- Valider en laboratoire immédiatement après déploiement pour confirmer que la correction n'a pas régressé autre chose.
- Reprendre les données terrain à J+14 (tendance intermédiaire), puis à J+30 (bilan définitif).
- Documenter chaque changement dans un tableau partagé, parce que six mois plus tard, vous ne vous souviendrez plus qui a fait quoi.
Les Core Web Vitals sur mobile méritent une attention particulière, car Google utilise l'index mobile-first pour le classement. L'audit SEO mobile étend cette logique à l'ensemble des signaux spécifiques à la navigation smartphone, au-delà des seules métriques de performance.
Les erreurs fréquentes dans un audit Core Web Vitals
Sur la centaine d'audits que j'ai menés, cinq erreurs reviennent en boucle. Vérifiez que vous ne tombez dans aucune.
La première : ignorer la variable "type de page". Un site WordPress peut avoir une homepage rapide et des articles catastrophiques à cause de plugins injectés seulement sur le blog. Testez plusieurs templates.
La deuxième : se fier uniquement au score global PageSpeed (sur 100). Ce score agrège plusieurs métriques et peut masquer un INP problématique derrière un LCP excellent. Regardez chaque métrique individuellement.
La troisième : auditer en desktop seulement. Google classe d'abord sur mobile. Un site performant sur desktop mais lent sur mobile perd du ranking, pas l'inverse.
La quatrième : corriger sans mesurer avant. Sans ligne de base, impossible de savoir si votre correction a vraiment apporté un gain.
La cinquième : attendre des miracles SEO. Les Core Web Vitals sont un facteur de départage, pas un levier de croissance principal. Corriger un LCP à 3 secondes pour atteindre 2 secondes n'augmentera pas votre trafic de 50 %. En revanche, sur une niche concurrentielle à autorité équivalente, c'est souvent la ligne de fracture entre page 1 et page 2.
FAQ
Quelle fréquence pour auditer ses Core Web Vitals ?
Un audit complet tous les trimestres suffit pour un site stable. Si vous déployez du code régulièrement, mettez en place un monitoring continu via un outil comme DebugBear, SpeedCurve ou l'API CrUX, avec une alerte dès qu'une métrique bascule en zone orange. Sur un site en refonte ou en phase de croissance rapide, un point mensuel sur les pages clés est plus adapté.
PageSpeed Insights ou Lighthouse, que choisir ?
Les deux sont utiles mais ne répondent pas à la même question. PageSpeed Insights affiche les données terrain sur 28 jours, donc ce que Google utilise pour vous classer. Lighthouse en local (DevTools) affiche des données laboratoire, utiles pour diagnostiquer une cause précise ou valider une correction juste après déploiement. Pour un audit complet, commencez par PageSpeed Insights, approfondissez avec Lighthouse.
Les Core Web Vitals sont-ils un facteur de classement majeur ?
Non, mais ils font partie des signaux "page experience" officiels de Google. À contenu et autorité équivalents, un site avec de bons Core Web Vitals est favorisé. Ce n'est pas le levier numéro un, mais c'est un avantage compétitif mesurable, particulièrement visible dans les niches serrées où quelques positions se jouent à la seconde de chargement près.
Combien de temps avant de voir l'impact d'une optimisation ?
Compter environ 28 jours pour que les données CrUX intègrent vos nouvelles performances. Avant cela, PageSpeed Insights continue d'afficher un mélange d'ancien et de nouveau, pondéré sur la fenêtre glissante. En laboratoire (Lighthouse), l'impact est visible immédiatement après déploiement, ce qui est utile pour valider qu'une correction n'a rien cassé mais ne reflète pas encore votre score SEO effectif.
Faut-il un développeur pour ce type d'audit ?
Pour la phase de diagnostic, non : PageSpeed Insights et Search Console sont accessibles à tout webmaster attentif. Pour la phase de correction, cela dépend des chantiers. Ajouter width et height sur les images ou activer font-display: swap se fait sans développeur sur la plupart des CMS. En revanche, inliner le CSS critique, découper les tâches JavaScript longues ou refondre un système de rendu côté serveur demande une vraie compétence technique. L'audit, lui, reste accessible.
