Faut-il arrêter de surveiller le score Lighthouse global pour se concentrer sur les métriques Core Web Vitals pertinentes à son site ?

Pourquoi Google remet-il en cause l'importance du score Lighthouse global ?

Le score Lighthouse global agrège plusieurs métriques (FID, LCP, CLS, mais aussi Time to Interactive, Speed Index) en un seul chiffre. Cette simplification pose problème : elle donne le même poids à toutes les métriques, quel que soit le contexte d'usage du site.

Martin Splitt précise que ce score fonctionne surtout comme un « smoke test » : un indicateur grossier qui détecte les cas extrêmes. Un score de 5 signale un site techniquement cassé nécessitant une intervention urgente. Un score de 95 indique qu'il ne reste que des optimisations marginales à réaliser.

Entre ces deux extrêmes, le score global perd de sa pertinence. Un site à 60 peut être parfaitement optimisé pour son usage réel si les bonnes métriques sont au vert.

Quelles métriques prioriser selon le type de site ?

Google donne deux exemples clairs pour illustrer la contextualisation des métriques. Pour une application de chat (Slack, Discord, etc.), le First Input Delay (FID) devient critique : l'utilisateur veut interagir immédiatement, et tout délai de réactivité nuit à l'expérience.

À l'inverse, sur un site de contenu pur comme Wikipedia, le Largest Contentful Paint (LCP) prime : l'utilisateur veut accéder au texte principal le plus vite possible. Le FID a moins d'importance puisque l'interaction n'est pas le cœur de l'usage.

Le Cumulative Layout Shift (CLS), quant à lui, reste universellement important mais avec des seuils de tolérance variables. Un site e-commerce avec des formulaires de paiement doit viser un CLS proche de zéro pour éviter les clics accidentels.

Cette approche change-t-elle la stratégie d'optimisation des Core Web Vitals ?

Absolument. Au lieu de chercher à équilibrer artificiellement toutes les métriques pour gonfler le score Lighthouse, il faut d'abord identifier le parcours utilisateur dominant. Ensuite, prioriser la métrique qui impacte directement ce parcours.

Cette déclaration valide une approche que certains SEO techniques pratiquent déjà : l'audit différencié par template. Une page d'accueil, une fiche produit, un article de blog n'ont pas les mêmes enjeux de performance ni les mêmes métriques critiques.

Concrètement, cela signifie qu'un site peut avoir des pages avec des scores Lighthouse de 75 mais des performances réelles excellentes sur les métriques qui comptent pour leur usage spécifique.

• Le score Lighthouse global est un indicateur de santé générale, pas un objectif en soi
• Chaque type de page doit être optimisé pour sa métrique dominante (LCP pour contenu, FID pour interactif, CLS pour transactionnel)
• Un score de 5 = urgence technique, un score de 95 = peaufinage, entre les deux = analyse contextuelle nécessaire
• Les tests Lighthouse doivent être segmentés par template pour identifier les priorités réelles
• Ne jamais sacrifier l'expérience utilisateur réelle pour améliorer un score agrégé artificiel

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, mais elle arrive tardivement. Les SEO techniques ont constaté depuis 2021 que des sites avec des scores Lighthouse moyens (65-80) pouvaient surperformer des sites à 95+ dans les SERP, à condition que leurs métriques critiques soient excellentes.

Le problème, c'est que Google a longtemps communiqué de manière ambiguë sur ce sujet. Les outils officiels (PageSpeed Insights, Search Console) mettent en avant le score global, ce qui a poussé beaucoup de référenceurs à l'optimiser aveuglément. Cette clarification de Splitt remet les curseurs au bon endroit.

Reste une zone grise : comment Google mesure-t-il réellement ces métriques pour le classement ? Les données CrUX (Chrome User Experience Report) agrègent tous les utilisateurs réels. Si votre site a 80% de visiteurs mobiles sur 3G qui dégradent le LCP, mais que votre audience cible utilise majoritairement du desktop fiber, êtes-vous pénalisé injustement ? [A vérifier]

Quelles nuances faut-il apporter à cette affirmation ?

Premier point : Splitt ne dit pas que les métriques ignorées peuvent être catastrophiques. Un site de contenu ne peut pas se permettre un FID de 800ms sous prétexte que le LCP est bon. Il y a une notion de seuil minimal acceptable sur toutes les métriques.

Deuxième nuance : l'exemple du chat vs Wikipedia est caricatural. La plupart des sites sont hybrides : un site e-commerce a du contenu (fiches produit), de l'interaction (filtres, comparateurs) et du transactionnel (checkout). Comment prioriser ? La réponse nécessite une analyse des pages stratégiques et de leurs objectifs business.

Troisième point : Google ne donne aucun chiffre de pondération. Dire « le LCP compte plus » ne quantifie rien. Est-ce 60/40 ? 80/20 ? Sans données, on reste dans l'interprétation. [A vérifier]

Dans quels cas cette approche peut-elle être contre-productive ?

Si on l'applique de manière trop binaire. Certains SEO pourraient négliger complètement le FID sur un site de contenu et se retrouver avec des boutons de partage, des formulaires de newsletter ou des commentaires inutilisables. L'interactivité secondaire reste de l'interactivité.

Autre risque : justifier la médiocrité. « Notre score Lighthouse est à 40 mais c'est pas grave, on est un site de contenu donc seul le LCP compte. » Non. Un score de 40 indique généralement des problèmes structurels (JavaScript bloquant, CSS non optimisé) qui impactent aussi le LCP.

Que faut-il faire concrètement pour adapter son monitoring des Core Web Vitals ?

Première étape : cartographier les templates stratégiques de votre site. Homepage, catégories, fiches produits, articles de blog, pages de checkout — chaque template a un objectif utilisateur différent. Documentez pour chacun si l'usage principal est lecture, interaction ou transaction.

Deuxième action : configurer des segments dans PageSpeed Insights ou CrUX pour tracker séparément chaque type de page. Ne vous contentez pas du score agrégé du domaine. Un site peut avoir un excellent LCP global mais un FID catastrophique sur les pages de filtres produits — et c'est là que l'abandon se produit.

Troisième point : redéfinir vos KPIs de performance. Si vous êtes un média, votre OKR n'est pas « atteindre 95 sur Lighthouse » mais « LCP < 2s sur 75% des articles et CLS < 0.1 ». Si vous êtes un SaaS, c'est « FID < 100ms sur la page d'app et LCP < 2.5s sur la landing ».

Quelles erreurs éviter dans cette réévaluation des priorités ?

Ne pas tomber dans le cherry-picking : choisir arbitrairement la métrique sur laquelle vous êtes déjà bon et ignorer les autres. L'identification de la métrique prioritaire doit partir de l'analyse comportementale (heatmaps, session recordings, analytics), pas de vos performances actuelles.

Éviter aussi de sur-optimiser une seule métrique au détriment de l'expérience globale. On a vu des sites sacrifier le contenu above-the-fold pour booster le LCP (en affichant juste un titre et une image vide), ce qui dégrade le taux d'engagement réel. Google finit toujours par ajuster ses algos contre ces optimisations artificielles.

Dernière erreur fréquente : négliger la variabilité mobile vs desktop. Un site peut avoir un excellent LCP desktop mais un LCP mobile catastrophique. Si 70% de votre trafic SEO vient du mobile, devinez quelle version Google priorise pour le classement ? La segmentation par device est non négociable.

Comment vérifier que votre site est optimisé selon les bons critères ?

Utilisez la Search Console pour identifier les pages avec le plus d'impressions et de clics. Croisez avec les données CrUX pour voir quelles métriques sont en échec sur ces pages stratégiques. Si vos 10 pages qui génèrent 80% du trafic ont un mauvais FID mais que vous avez passé 3 mois à optimiser le LCP sur des pages zombies, vous avez gaspillé du temps.

Mettez en place un monitoring continu avec des alertes sur les métriques prioritaires par template. Des outils comme SpeedCurve, Calibre ou Treo permettent de tracer l'évolution dans le temps et de corréler avec les fluctuations de trafic organique.

Enfin, testez en conditions réelles. Les tests Lighthouse se font sur un réseau simulé et un device émulé. Utilisez WebPageTest avec des profils de connexion variés (3G, 4G, cable) et des devices réels. Un LCP de 1.8s en Lighthouse peut exploser à 5s sur un vrai Xiaomi Redmi en 3G indien — et c'est ce que vos utilisateurs vivent.

• Cartographier les templates stratégiques et identifier la métrique dominante pour chacun (LCP pour contenu, FID pour interactif, CLS pour transactionnel)
• Configurer des segments de suivi dans CrUX et PageSpeed Insights par type de page, pas seulement au niveau domaine
• Redéfinir les KPIs de performance en fonction de l'usage réel, pas du score Lighthouse global
• Croiser les données Search Console (pages stratégiques) avec les données CrUX (métriques en échec) pour prioriser les chantiers
• Tester en conditions réelles (WebPageTest, vrais devices, vraies connexions) pour valider les optimisations au-delà des simulations Lighthouse
• Mettre en place un monitoring continu avec alertes sur les métriques critiques par template