PageSpeed Insights suffit-il vraiment pour optimiser vos Core Web Vitals ?

Quelle est la différence entre PSI et les données de terrain ?

PageSpeed Insights combine deux types de mesures : les données de laboratoire (Lighthouse) et les données de terrain (CrUX). Lighthouse lance votre page dans un environnement simulé ultra-contrôlé : connexion 4G bridée, CPU throttlé, navigateur Chrome sans extensions. C'est reproductible, mais totalement déconnecté de la réalité.

Le Chrome User Experience Report, lui, remonte les performances réelles vécues par vos visiteurs Chrome au cours des 28 derniers jours. C'est cette donnée-là que Google utilise pour classer vos pages selon les Core Web Vitals. Lighthouse diagnostique, CrUX juge.

Pourquoi Google pousse-t-il autant Lighthouse ?

Parce que c'est un outil pédagogique gratuit qui évangélise les bonnes pratiques web. Google a besoin que les webmasters comprennent les notions de rendu critique, de JS bloquant, de cache navigateur. Lighthouse liste 70+ vérifications et donne un score sur 100 qui flatte l'ego des décideurs.

Mais attention : un score Lighthouse de 95 ne garantit aucunement que vos Core Web Vitals CrUX seront au vert. J'ai vu des sites scorer 88 sur mobile avec un LCP réel à 4,2 secondes en conditions réelles. L'inverse existe aussi : des sites à 62 en lab qui passent les seuils CrUX parce que leur audience a du bon débit.

Qu'est-ce que « optimiser en conséquence » signifie concrètement ?

Mueller reste volontairement vague. « Optimiser en conséquence » pourrait signifier corriger les alertes Lighthouse, ou bien adapter votre stratégie selon l'appareil dominant dans vos segments CrUX. Si 80 % de votre trafic vient de mobiles 3G en Inde, vous ne prioriserez pas les mêmes optimisations qu'un site desktop BtoB européen.

Le piège classique : traiter Lighthouse comme une checklist à 100 %. Certains audits (notamment ceux sur l'accessibilité ou les PWA) n'ont aucun impact SEO direct. D'autres (images non optimisées, JS tiers) sont critiques. Hiérarchisez selon l'impact métier, pas selon le poids des points Lighthouse.

• PSI = outil de diagnostic combinant Lighthouse (lab) et CrUX (terrain)
• Lighthouse simule des conditions contrôlées, pas votre trafic réel
• CrUX contient les données que Google utilise pour le classement Core Web Vitals
• Un bon score Lighthouse ne garantit pas un bon classement, et inversement
• Utilisez PSI pour identifier les leviers, validez l'impact avec CrUX et la Search Console

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui et non. Google a raison de promouvoir PSI comme point d'entrée : c'est accessible, documenté, et ça sensibilise aux enjeux de performance. Mais dans la pratique, trop de consultants juniors prennent le score Lighthouse pour argent comptant et optimisent dans le vide.

J'ai audité des centaines de sites où les équipes techniques avaient passé des semaines à gratter 10 points Lighthouse sur des critères cosmétiques (contrast ratios, meta viewport) pendant que le LCP réel stagnait à 3,8 secondes parce qu'un CDN mal configuré servait des images WebP non compressées. Le score lab était monté à 92. Le trafic organique continuait de baisser.

Quelles nuances faut-il apporter ?

Mueller ne précise pas que Lighthouse v10 a changé la pondération des métriques et que certains sites ont vu leur score chuter de 15 points du jour au lendemain sans aucune régression réelle. Les seuils TBT (Total Blocking Time) sont devenus plus sévères, alors que Google ne l'utilise même pas comme signal de ranking — c'est le FID ou l'INP qui comptent.

Autre point : PSI mobile teste sur un Moto G4 émulé avec un CPU 4x throttlé. Si votre audience utilise des iPhone 13, cette simulation sous-estime largement vos performances réelles. Inversement, si vous visez des marchés émergents, le Moto G4 est encore trop optimiste. [A vérifier] : Google n'a jamais publié la distribution réelle des devices dans le panel CrUX.

Dans quels cas cet outil devient-il trompeur ?

Lighthouse échoue lamentablement sur les sites hautement interactifs (SPA React/Vue lourdes) où le rendu initial est rapide mais l'interactivité réelle arrive 8 secondes plus tard. Le score FCP sera excellent, le LCP correct, mais l'INP catastrophique. PSI ne teste qu'un chargement à froid, jamais les navigations internes.

Autre cas : les sites avec contenu personnalisé ou geo-ciblé. Lighthouse charge votre page depuis des serveurs Google US. Si vous servez du contenu différent selon la géolocalisation ou si votre CDN a des edge servers mal répartis, les mesures lab seront totalement biaisées. Toujours croiser avec les données CrUX segmentées par pays.

Comment utiliser PSI sans se tromper de priorités ?

D'abord, lancez PSI sur vos 10 URLs les plus stratégiques (homepage, catégories top, fiches produit bestsellers). Ne vous arrêtez pas au score global : descendez dans les audits détaillés et filtrez par impact. Cherchez les opportunities qui affichent un gain temps estimé supérieur à 1 seconde.

Ensuite, comparez systématiquement avec l'onglet CrUX en haut de PSI. Si Lighthouse vous donne 78 mais que CrUX indique « Good » sur LCP/FID/CLS, félicitations : vos vrais users sont contents, inutile de sur-optimiser. Si c'est l'inverse (bon score lab, CrUX orange/rouge), creusez les données Search Console pour identifier les segments problématiques (device, pays, type de connexion).

Quelles erreurs éviter absolument ?

Ne jamais optimiser pour le score au détriment de l'UX. J'ai vu des sites retirer des polices custom, désactiver des animations CSS utiles, ou lazy-loader le hero banner pour monter à 95. Résultat : l'expérience devient fade, le taux de rebond explose, et Google finit par déclasser la page malgré les bons Core Web Vitals parce que les signaux comportementaux sont catastrophiques.

Deuxième erreur classique : ignorer les scripts tiers. Google Tag Manager, Hotjar, Intercom, pixels Facebook… Ces outils plombent le TBT et le LCP mais les marketeurs refusent de les toucher. Si vous ne pouvez pas les retirer, chargez-les en différé ou via un worker. Lighthouse vous montre exactement quels scripts bloquent le main thread et combien de millisecondes ils coûtent.

Quelle stratégie d'optimisation adopter sur la durée ?

Mettez en place un monitoring continu avec PageSpeed Insights API ou un outil comme Lighthouse CI intégré à votre pipeline CI/CD. Lancez un audit automatique à chaque déploiement et bloquez la mise en prod si le score descend sous un seuil critique (par exemple 70 mobile). Ça évite les régressions silencieuses.

Parallèlement, suivez vos Core Web Vitals CrUX dans la Search Console chaque semaine. Si vous détectez une dégradation sur un segment (par exemple LCP mobile qui passe de « Good » à « Needs Improvement »), remontez dans PSI pour diagnostiquer. L'outil vous dira si c'est un problème de serveur (TTFB élevé), de ressources bloquantes, ou de layout shift.

• Auditez d'abord les pages à fort trafic et à fort CA, pas l'ensemble du site
• Comparez toujours score Lighthouse (lab) et données CrUX (terrain)
• Priorisez les optimisations selon l'impact temps estimé, pas le nombre de points gagnés
• Automatisez les audits dans votre CI/CD pour détecter les régressions avant la prod
• Segmentez les données CrUX par device et géo pour cibler les vrais problèmes
• Ne sacrifiez jamais l'UX réelle pour un score cosmétique