Tu as un Lighthouse vert. Tu respires. Et deux jours plus tard, Google Search Console (GSC) t’affiche des Core Web Vitals « à améliorer » ou « médiocres ». Le réflexe classique, c’est de conclure que « GSC bug » ou que « Google est incohérent ».
La réalité est plus simple, et un peu plus frustrante : tu compares deux mondes différents. Lighthouse te donne une photo en labo. GSC te remonte la perf vécue par des utilisateurs réels, via le Chrome UX Report (CrUX). Et entre les deux, il y a ta prod, ton trafic mobile, tes scripts tiers, tes sessions longues, tes cookies banners, tes pages pas chaudes dans le cache… bref, la vraie vie.
Core Web Vitals dans GSC : ce n’est pas Lighthouse, c’est CrUX (field data)
Le rapport Core Web Vitals de Search Console est basé sur des données terrain (field data) issues de CrUX. Concrètement, ça vient de vrais utilisateurs de Chrome qui ont accepté la collecte, sur de vrais devices, avec de vrais réseaux, et des comportements parfois pénibles pour la perf (scroll, clics, navigation, retour arrière, onglets qui restent ouverts, etc.).
Et surtout, GSC ne te parle pas de « score » Lighthouse. GSC te parle de distribution : un site passe ou ne passe pas selon des percentiles (en pratique, le 75e percentile), sur une fenêtre glissante d’environ 28 jours. Ça veut dire un truc très concret : tu peux avoir une majorité d’utilisateurs contents, mais un quart qui galère, et ça suffit à être « rouge ».
Autre détail qui piège beaucoup de monde : dans GSC, les URLs sont souvent regroupées par « type de page » (templates) quand Google détecte des patterns similaires. Tu crois regarder « une page », tu regardes parfois une famille entière. Et si une seule variante est toxique (un paramètre, un module, un AB test), tu peux te faire embarquer.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Pourquoi Lighthouse peut être vert pendant que GSC est rouge (les divergences qui reviennent tout le temps)
Lighthouse est précieux, mais il est structurellement optimiste par rapport au terrain, même quand tu le lances sérieusement. Il mesure dans un environnement synthétique, avec un scénario court, souvent centré sur le chargement initial. GSC/CrUX, lui, absorbe tout ce que tu ne contrôles pas.
La divergence la plus fréquente, c’est le mix device/réseau. Tu testes Lighthouse depuis un laptop correct, ou un mobile récent, sur une connexion stable. Tes utilisateurs, eux, viennent sur des Android fatigués, avec des radios capricieuses, parfois en mode économie d’énergie. Sur le papier, c’est « le même site ». En pratique, le CPU time explose, les Long Tasks s’accumulent, et l’INP part en vrille.
Deuxième classique : les scripts tiers. Lighthouse peut les voir, mais il ne reproduit pas toujours le pire des scénarios : tags qui se chargent plus tard, consentement qui retarde ou duplique des appels, A/B tests qui bougent le DOM après rendu, widgets qui s’initialisent au scroll. Sur CrUX, ces variations finissent dans la stat, parce qu’elles arrivent réellement chez des gens.
Troisième cas qui surprend : l’interaction utilisateur. Lighthouse te donne une idée, mais l’INP (Interaction to Next Paint) est une métrique de terrain par nature. Si ton site devient « lourd » après quelques interactions (SPA qui accumule des listeners, store qui grossit, composants qui re-render à chaque scroll), Lighthouse peut rester propre sur un run court… et CrUX te sanctionne sur des sessions plus longues.
Quatrième piège : cache et navigation. Lighthouse est souvent lancé sur une page « froide », dans une session artificielle. Tes utilisateurs, eux, naviguent depuis des pages déjà ouvertes, reviennent en arrière (bfcache), arrivent via une page intermédiaire, ou prennent des routes où ton JS est déjà en mémoire. Ça peut améliorer certaines métriques… ou empirer CLS/INP selon comment ton app est codée. Le terrain n’est pas une simple « première visite ».
Et puis il y a le banal, le très banal : tu testes la mauvaise URL (homepage propre) alors que le problème est sur un template d’article blindé de embeds, ou sur une page catégorie qui fait des requêtes infinies, ou sur une page produit avec 14 trackers. Lighthouse n’est pas « faux », tu regardes juste le mauvais endroit.
Ce que mesurent vraiment LCP, CLS et INP (et pourquoi tu peux « optimiser » dans le vide)
Sur le terrain, les Core Web Vitals sont impitoyables parce qu’ils correspondent à des sensations très concrètes.
LCP (Largest Contentful Paint), c’est le moment où l’élément principal devient visible. Dans la vraie vie, le LCP se fait exploser par une image hero mal servie, un TTFB qui grimpe aux heures de pointe, du CSS critique qui arrive trop tard, ou une police qui bloque le rendu. Et même si ton Lighthouse « simule » un réseau, il ne vit pas tes saturations serveur, tes variations CDN, tes cookies, tes headers de cache, tes redirections géoloc…
CLS (Cumulative Layout Shift), c’est le saut de layout. Sur un run Lighthouse, tu peux passer à côté d’un shift déclenché après consentement, après chargement d’un widget, après injection d’un encart pub, ou après un lazyload qui réserve mal l’espace. Sur CrUX, ces shifts arrivent chez des gens, et ça s’imprime dans la stat.
INP (qui a remplacé FID), c’est la réactivité réelle. Et c’est là que le « mismatch » est le plus violent : un site peut être rapide à charger mais pénible à utiliser (main thread saturé, handlers trop lourds, rendu qui bloque après un clic). Si tu optimises uniquement le chargement initial, tu peux te raconter une belle histoire et laisser le vrai irritant intact.
Mon protocole terrain : arrêter le one-shot Lighthouse, et recoller au réel
La règle que je me répète : Lab pour diagnostiquer, Field pour décider. Lighthouse sert à trouver des causes, pas à « valider » une expérience utilisateur globale.
Côté lab, je ne crois pas au run unique. Je fais plusieurs passes, j’observe la médiane, et je force des conditions proches du trafic réel (mobile, throttling cohérent, extensions coupées, cache maîtrisé). Et je garde en tête un truc : ce que je veux, c’est un signal stable, pas un score qui flatte.
# Exemple simple : répéter Lighthouse et regarder la médiane, pas le meilleur run
npx lighthouse https://example.com \
--preset=desktop \
--throttling-method=simulate \
--runs=7 \
--output=html \
--output-path=./lh-report.htmlEnsuite, je recolle à la réalité côté field. Le minimum syndical, c’est de regarder PageSpeed Insights, parce qu’il affiche à la fois les données terrain CrUX (si dispo) et les données lab Lighthouse. Tu as un pont direct entre les deux mondes, ce qui évite déjà 80% des débats stériles.
Et si le site compte un minimum (trafic, enjeu business), je mets en place du RUM (Real User Monitoring). Pas forcément une usine à gaz. Juste de quoi segmenter par device, par route, par pays, par login/non-login, et comprendre qui souffre réellement.
// RUM minimaliste avec la lib web-vitals : tu envoies les métriques vers ton endpoint
import {onLCP, onCLS, onINP} from 'web-vitals';
function sendToAnalytics(metric) {
navigator.sendBeacon('/analytics/web-vitals', JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
url: location.href,
ua: navigator.userAgent
}));
}
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
Le but n’est pas de « remplacer » CrUX. Le but, c’est d’avoir ton propre microscope pour expliquer un rouge GSC sans faire de magie. Parce que GSC te dit « c’est mauvais », mais ne te dit pas « chez qui, quand, et à cause de quoi ».
Segmentation : la différence entre “mon site est lent” et “ce template mobile tue l’INP”
Quand GSC est rouge, la tentation c’est de se jeter sur la homepage ou sur « la page qui fait le plus de trafic ». Ça marche parfois. Souvent, c’est une perte de temps.
Ce qui marche vraiment, c’est de raisonner en templates et en segments. Un site n’a pas « une perf ». Il a des profils. Les pages article n’ont pas le même poids que les pages produit. Les pages avec embeds n’ont pas la même stabilité que celles sans. Et la perf sur iPhone récent n’a rien à voir avec la perf sur Android entrée de gamme.
En pratique, je cherche d’abord à répondre à trois questions très terre-à-terre. Est-ce que le rouge est concentré sur mobile ? Est-ce que ça touche un groupe d’URLs qui sent le template (GSC regroupe souvent bien) ? Est-ce que le problème est plutôt LCP, CLS ou INP ? Rien que ça te dicte une stratégie différente.
Un exemple vécu : Lighthouse vert sur un template article parce que la page « nue » est clean. Mais en prod, 30% des articles ont un embed Instagram, un player, et une bannière consentement qui déclenche un relayout. Résultat : CLS en field dégueulasse, et impossible à voir sur le run que tu fais « sur un article au hasard ».
Les mauvais arbitrages que je vois tout le temps (et qui ne réparent pas GSC)
Le premier mauvais arbitrage, c’est d’optimiser « pour le score ». Tu vois un audit Lighthouse qui te dit de réduire le JS, tu fais sauter des trucs au hasard, tu gagnes 5 points, et tu penses avoir réglé l’histoire. Sauf que ton INP terrain était cassé par une seule interaction qui bloque 400 ms sur un handler, et tu n’as touché à rien d’utile.
Le deuxième, c’est de traiter la perf comme un chantier isolé du produit. Typiquement, tu améliores LCP en rendant le hero plus léger, mais le marketing colle une vidéo auto-play la semaine suivante. Ou tu stabilises CLS en réservant de l’espace, et un A/B test change la hauteur des cards. Sans garde-fous, tu vas jouer au chat et à la souris avec GSC, et comme CrUX est en fenêtre 28 jours, tu auras toujours l’impression d’être « en retard ».
Le troisième, c’est de promettre un délai absurde. Non, tu ne « repasses pas au vert demain ». Même si tu corriges tout aujourd’hui, GSC reflète une période glissante. Ce que tu peux promettre en revanche, c’est une trajectoire : des métriques RUM qui s’améliorent immédiatement, puis CrUX qui suit, puis GSC qui se met à jour.
Quoi dire à un client ou à un PM : arrêter de vendre du vert, vendre du mesurable
Si tu dois expliquer le mismatch à quelqu’un qui n’a pas envie de rentrer dans les percentiles, je trouve qu’une phrase suffit : Lighthouse mesure un test contrôlé, GSC mesure ce que vivent vraiment les gens. Les deux sont utiles, mais on ne prend pas des décisions produit sur un test contrôlé uniquement.
Ensuite, je cadre les attentes. Quand on parle Core Web Vitals, on parle de probabilité et de population. Le job, ce n’est pas d’avoir un run « parfait ». Le job, c’est de réduire la proportion d’utilisateurs qui ont une mauvaise expérience, sur les pages qui comptent, sur les devices qui pèsent dans le business.
Et je mets un contrat clair : on suit un dashboard RUM (ou au minimum PSI/CrUX) par template, on fixe une cible (ex : INP sous 200 ms au p75 sur mobile), et on s’engage sur des changements concrets (scripts tiers, rendu, cache, taille des payloads). Le « score Lighthouse » reste un outil de diagnostic interne. Pas un KPI final.
Le point qui fâche : parfois tu ne peux pas “corriger” CrUX rapidement (et c’est normal)
Il y a des cas où tu fais tout bien et CrUX reste mauvais un moment. Soit parce que ton trafic est faible et les données mettent du temps à se stabiliser. Soit parce que la distribution a une longue traîne (un segment d’utilisateurs très lent). Soit parce que tu as un template très hétérogène (certains contenus lourds, d’autres non).
Dans ces cas-là, le bon move n’est pas de paniquer et d’empiler les micro-optimisations. Le bon move, c’est de comprendre qui souffre. Si 10% de ton trafic vient d’un pays avec réseau compliqué, tu peux décider de servir une version plus light, ou de changer la stratégie d’images. Si ce sont des pages spécifiques qui concentrent le problème, tu les traites comme une dette de contenu, pas comme une dette de build.
Mon avis : Lighthouse n’est pas le problème, c’est l’usage qu’on en fait
Lighthouse est un excellent outil quand tu le utilises pour ce qu’il est : un laboratoire, répétable, actionnable, parfait pour attraper des régressions et guider des optimisations. Le problème, c’est la croyance magique qu’un « vert » est une validation universelle.
Si tu veux arrêter de te battre contre GSC, garde cette discipline : tu debug en lab, tu valides en field, tu segmentes, et tu ne promets pas un vert « immédiat ». Tu promets une amélioration mesurée sur des utilisateurs réels. C’est moins sexy qu’un screenshot Lighthouse. C’est aussi beaucoup plus sérieux.
Sources
- Discussion Reddit : confusion GSC Core Web Vitals vs Lighthouse
- Google Search Central : Page Experience / signaux et métriques
- Chrome UX Report (CrUX) : documentation
- web.dev : Core Web Vitals (principes et interprétation)
- Lib web-vitals : mesurer LCP/CLS/INP en RUM
- Chrome Developers : Lighthouse (lab data)
