Webperf 2025 : pourquoi le score Lighthouse ne suffit plus

Entre Lighthouse, PageSpeed Insights et les Core Web Vitals, il y a souvent un sacré flou côté clients – et même côté pros parfois. On mélange tout, alors que chacun a son rôle précis dans l’écosystème de la performance web. Lighthouse, c’est l’outil d’audit open source développé par Google, qui va scanner une page web et générer un rapport local en conditions simulées. PageSpeed Insights, lui, est l’interface web de Google qui utilise Lighthouse pour fournir un score, mais qui y ajoute en plus des données de terrain, issues des vrais utilisateurs via le Chrome User Experience Report (CrUX). Et les Core Web Vitals ? Ce sont des indicateurs spécifiques (LCP, CLS, INP) intégrés dans la Search Console et d’autres outils Google, utilisés dans l’algorithme SEO.

Le problème, c’est qu’on utilise souvent ces outils sans vraiment comprendre ce qu’ils mesurent ni comment. Résultat : un client voit un score rouge sur PageSpeed et panique, sans savoir que c’est peut-être juste une font qui bloque le rendu sur mobile en Edge. Ou au contraire, il est tout sourire parce qu’il a du vert partout, alors qu’en réalité son site rame sur un Android de base. Et derrière, c’est la conversion qui trinque. Comprendre qui mesure quoi, et dans quel contexte, c’est déjà commencer à faire les bons choix techniques.

Le score de performance Lighthouse est une moyenne pondérée de plusieurs métriques (First Contentful Paint, Largest Contentful Paint, Speed Index, Total Blocking Time, Time to Interactive, Cumulative Layout Shift). Chaque indicateur a un poids différent dans le calcul, et Google ajuste ces pondérations régulièrement selon ses priorités du moment. Mais en 2025, la composante qui prend de plus en plus de place, c’est l’Interactivity. Avec l’arrivée d’INP comme remplaçant de FID, Google montre qu’il ne s’intéresse plus seulement au temps de chargement initial, mais surtout à la fluidité de l’interaction.

Et pourtant, dans Lighthouse, toutes ces métriques sont calculées dans un environnement simulé, sans l’ombre d’un utilisateur réel. Le site est chargé depuis une machine virtuelle, avec une version propre de Chrome, sans extensions, sans historique, sans scripts parasites. Bref, tout est idéal, contrôlé, irréaliste. Résultat : le score est souvent bien plus élevé que la performance vécue par les visiteurs. Il suffit d’un preload mal configuré ou d’un JS inutile qui se déclenche trop tôt pour que tout s’effondre sur mobile, même si Lighthouse ne bronche pas.

C’est LE point clé que trop peu d’entreprises réalisent : Lighthouse, c’est un test de labo. Pas une analyse terrain. Pas un reflet fidèle de ce que vit votre audience. Imaginez un médecin qui vous fait passer un test cardio en vous regardant sur une vidéo d’il y a six mois. C’est à peu près aussi fiable. Aucun cache navigateur. Aucun scroll. Aucune interaction réelle. Aucune latence liée à l’API distante que vous utilisez en production. Aucune personnalisation dynamique. Rien.

Et surtout, c’est un test fait une seule fois. À un instant T. Dans un état “vierge”. Le souci, c’est que vos visiteurs, eux, reviennent. Naviguent. Cumulent des cookies. Ont des connexions réseau changeantes. Utilisent des extensions Chrome ou des bloqueurs de pub. Et ce sont ces conditions d’usage qu’il faut prendre en compte. Parce qu’un site peut être rapide au premier chargement mais s’effondrer ensuite dès que l’utilisateur clique ou scrolle. Lighthouse ne vous dira jamais ça.

S’en remettre uniquement au score Lighthouse pour piloter la stratégie technique d’un site, c’est comme choisir une voiture juste en regardant sa fiche de consommation officielle. En théorie, c’est propre, carré. En pratique, ça ne vous dit rien sur la fiabilité, la tenue de route, ni le ressenti à la conduite. Et c’est exactement ce qu’on constate avec certains projets : le focus est mis sur l’outil, pas sur l’expérience. On passe des jours à grapiller des points sur Lighthouse en désactivant des fonctionnalités utiles, en compressant des images jusqu’à les rendre floues, ou en chargeant des scripts importants trop tard juste pour éviter une alerte. Tout ça pour afficher un 90+ qui, au fond, n’a aucun impact réel.

Le risque, c’est de sacrifier l’UX sur l’autel d’un score. De faire des compromis absurdes. De négliger des problèmes de fond (structure du DOM, scripts bloquants, CSS mal géré, composants redondants) au profit de petites optimisations cosmétiques. Et surtout, c’est de croire que l’objectif est atteint. Qu’un bon score = un bon site. Alors que le ressenti utilisateur, lui, n’a pas changé d’un iota.

Lighthouse ne mesure pas la frustration. Il ne capte pas l’agacement d’un clic qui ne répond pas tout de suite. Il ne voit pas un bouton qui bouge au moment du tap. Il ne sent pas le micro-lag quand une animation JS passe mal sur un appareil moyen de gamme. Tous ces petits irritants, ces grains de sable dans l’expérience, ne remontent jamais dans un audit lab. Et pourtant, ce sont eux qui font toute la différence entre un site agréable… et un site qu’on quitte.

Et ce n’est pas qu’un problème UX. C’est un problème de SEO, de business, de réputation. Google intègre ces signaux de performance perçue dans son classement. Les utilisateurs, eux, ne donnent pas de seconde chance à un site lent ou instable. Et les indicateurs d’engagement (temps passé, scroll, conversion) s’effondrent en silence. Autrement dit : ce que Lighthouse ne dit pas peut vous coûter très cher.

Depuis leur lancement, les Core Web Vitals ont connu plusieurs ajustements. Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour que le contenu principal s’affiche : c’est ce qui donne la sensation que le site « répond » visuellement. Le CLS (Cumulative Layout Shift) suit les décalages visuels intempestifs : un bouton qui saute pendant qu’on clique, une image qui pousse le texte vers le bas. Des détails en apparence, mais qui pourrissent l’expérience. Le dernier arrivé, c’est INP (Interaction to Next Paint), qui a officiellement remplacé FID en mars 2024. Il mesure la latence entre une interaction utilisateur et sa réponse visible à l’écran. INP n’est pas un indicateur secondaire : c’est maintenant un critère de classement SEO.

Autrement dit, Google ne regarde plus seulement si votre site se charge vite, mais s’il réagit vite. C’est un tournant majeur. Parce qu’un site peut afficher du contenu en 2 secondes, et pourtant prendre 4 ou 5 secondes à répondre à un clic. Et c’est précisément ce que détecte INP. Si vous n’y faites pas attention, vous pouvez avoir un bon score Lighthouse mais une note catastrophique en Web Vitals, et donc des performances SEO et UX pénalisées.

Jusqu’à récemment, le FID (First Input Delay) était l’indicateur utilisé pour mesurer la réactivité. Mais FID n’était déclenché que sur la toute première interaction (souvent un clic ou une touche), et ne reflétait donc qu’un instant très court. Google l’a donc remplacé par INP, bien plus exigeant, qui prend en compte toutes les interactions sur une page, pendant toute la durée de la session. Résultat : un site qui commence bien mais devient lourd à l’usage est désormais pénalisé.

C’est un vrai message de la part de Google : ce qui compte, ce n’est pas juste l’apparence de la performance. C’est la stabilité de l’expérience. Le confort, la réactivité, la continuité. En clair, vous n’avez plus le droit de faire un site qui « tient deux secondes » et s’écroule ensuite. INP vient bousculer les mauvaises habitudes : surcharge de JS, effets inutiles, animations non optimisées… tout ce qui bloque ou ralentit les interactions est désormais dans le viseur. Et il est temps que les équipes techniques en prennent pleinement conscience.

L’un des grands aveuglements de la performance web, c’est de tester ses sites sur MacBook Pro en fibre optique, avec zéro cache, zéro interaction, et un réseau stable. Mais vos utilisateurs ? Ils sont en déplacement, dans un bus, en partage de connexion. Ils sont sur des Android d’entrée de gamme, parfois avec des apps ou des VPN actifs. Ils utilisent un navigateur pas forcément à jour, ou des interfaces intégrées à des outils métiers. Bref : ils ne naviguent pas dans les conditions idéales que reproduit Lighthouse.

Et c’est précisément pour ça que les métriques terrain sont vitales. Parce qu’elles reflètent les vraies performances ressenties par vos visiteurs. Le LCP met 3,7 secondes à se charger sur un Redmi ? Le CLS explose sur Safari iOS ? L’INP dépasse 400ms sur Firefox ? Tout ça, ce sont des problèmes concrets, vécus, mesurables et actionnables. Tant qu’on ne les intègre pas dans les process de conception et de développement, on passe à côté du vrai sujet.

On peut avoir un Time to Interactive excellent et un Speed Index parfait, mais si l’utilisateur a l’impression que ça rame, alors ça rame. Point. La performance web, ce n’est pas une suite de chiffres : c’est une sensation, une fluidité, une absence de friction. C’est le sentiment que tout se déroule naturellement, sans effort, sans blocage. Un site peut avoir des scores techniques honorables et pourtant générer de la frustration simplement parce qu’il met du temps à réagir, ou parce qu’il est visuellement instable, ou parce que le contenu arrive trop tard.

La performance perçue, c’est ce que vivent les utilisateurs. Et ce que Google cherche de plus en plus à mesurer, justement pour l’intégrer dans son algorithme. En 2025, ignorer cette dimension, c’est passer à côté de l’enjeu principal. Parce que ce n’est pas Lighthouse qui décide si un site est bon ou non : c’est l’utilisateur.

La première étape d’un travail sérieux sur la performance, c’est de regarder les deux faces de la pièce. On commence évidemment par un audit technique en labo, avec Lighthouse, Chrome DevTools, WebPageTest. Ces outils nous donnent une première photographie, une cartographie des points d’attention. Mais on ne s’arrête jamais là. On croise ensuite avec des données de terrain, issues de la Search Console, du CrUX, ou des outils d’analyse RUM (Real User Monitoring).

Cette double lecture est indispensable. Elle permet de détecter des écarts, de hiérarchiser les urgences, de comprendre ce qui est ressenti dans la vraie vie. Un site peut être correct en labo et désastreux en production. Inversement, certains problèmes visibles dans Lighthouse ne sont pas critiques dans le contexte réel. Il faut donc savoir où placer les efforts. Ce travail d’interprétation, on le fait systématiquement chez LATELIER. C’est ce qui permet de prendre les bonnes décisions, sans tomber dans l’optimisation inutile ou dans l’aveuglement.

Pour aller plus loin, on s’appuie sur des outils spécialisés. WebPageTest nous permet de simuler des conditions de navigation bien plus proches de la réalité qu’un simple test Lighthouse. On peut choisir un mobile, une localisation géographique, une vitesse de réseau précise, et observer chaque étape du chargement avec une granularité extrême. C’est une mine d’or pour comprendre où se situe le vrai goulot d’étranglement.

SpeedCurve, lui, permet de suivre l’évolution de la performance dans le temps. C’est essentiel pour les sites vivants, qui changent régulièrement. On peut repérer les régressions, les pics de lenteur, les zones à risque. Sur certains projets, on intègre aussi du monitoring custom via Datadog, Sentry ou même du RUM sur mesure, développé directement dans le front. Ce niveau d’analyse permet de prendre des décisions avec des données fiables, pas juste des impressions.

On ne travaille pas la performance dans un coin. On l’intègre aux outils que le client utilise déjà. Les données issues de la Search Console sont croisées avec les analytics, les taux de clic, les comportements de navigation. GA4 nous permet d’observer des détails très fins sur les sessions, les pages lentes, les parcours bloquants.

Et sur certains projets, on va jusqu’à intégrer un tableau de bord personnalisé, avec des indicateurs métiers corrélés à la performance. On peut par exemple visualiser l’impact d’une lenteur sur une page produit spécifique, ou détecter une baisse de conversion liée à un bug sur mobile. C’est cette approche globale, connectée à la réalité business, qui fait toute la différence. La performance n’est plus un sujet purement technique. C’est un outil de pilotage concret.

Un site qui fonctionne bien le jour de la mise en ligne, c’est bien. Mais un site qui reste rapide, fluide et stable dans la durée, c’est beaucoup mieux. C’est pourquoi on met en place un système de suivi continu de la performance sur les projets critiques. Chaque mois, ou à chaque déploiement, on vérifie que les indicateurs sont stables. Si un script est ajouté, si une mise à jour a des effets secondaires, si un changement dans l’hébergement provoque des lenteurs, on est alertés.

Ce reporting permet aussi de rassurer les clients. Ils savent qu’on garde un œil sur leur site. Que des actions concrètes sont possibles si la situation se dégrade. Et surtout, ils ne découvrent pas six mois plus tard que leurs utilisateurs fuient à cause d’un souci qu’on aurait pu anticiper. C’est une posture de responsabilité. Et une manière de garantir que le travail fait ne se dégrade pas dans le temps.

Enfin, il y a une chose qu’aucun outil ne remplacera jamais complètement : le test humain. Chez LATELIER, on ne valide pas un site uniquement avec des métriques. On le teste. Sur un téléphone. Sur un ordinateur pas tout neuf. En 4G moyenne. En cliquant, scrollant, naviguant comme le ferait n’importe quel utilisateur. C’est souvent à ce moment-là qu’on détecte les micro-latences, les blocages intermittents, les inconforts subtils.

On n’est pas là pour faire du score. On est là pour créer des expériences qui fonctionnent. Qui tiennent la charge. Qui durent. Tester avec les bons outils, c’est bien. Mais tester avec les bonnes questions en tête, c’est mieux. Et la seule qui vaille, en fin de compte, c’est : est-ce que c’est agréable à utiliser ?

Ce n’est pas une hypothèse, c’est une réalité confirmée par Google : les signaux UX et les Core Web Vitals influencent directement le classement dans les résultats de recherche. Et le phénomène ne fait que s’amplifier. Avec l’arrivée d’INP dans les critères officiels, Google montre clairement qu’il valorise les sites qui offrent une expérience fluide et réactive. Les pages lentes, instables ou bloquantes sont pénalisées, même si leur contenu est de qualité.

Optimiser la webperf, c’est donc aussi optimiser son SEO. C’est une manière directe d’augmenter sa visibilité, sans produire une ligne de contenu supplémentaire. C’est surtout une manière pérenne : à chaque mise à jour de l’algorithme, Google renforce le lien entre performance et pertinence. Miser sur la webperf aujourd’hui, c’est sécuriser sa position demain.

Un site rapide, c’est aussi un site qui consomme moins de bande passante, moins de ressources serveurs, moins d’énergie. Et dans un contexte où l’impact environnemental du numérique devient une préoccupation centrale, la webperf rejoint logiquement les démarches d’écoconception. En réduisant le poids des pages, le nombre de requêtes, la quantité de scripts et de médias chargés, on réduit l’empreinte carbone d’un site.

Ce n’est pas un gadget. C’est une responsabilité. Chez LATELIER, on est de plus en plus sollicités sur cette question. Des entreprises qui veulent rendre leur communication digitale plus responsable. Des DSI qui cherchent à aligner leur infrastructure avec les engagements RSE. Et à chaque fois, la réponse passe par une meilleure performance. C’est gagnant sur tous les plans.

On oublie souvent que la lenteur d’un site peut être une forme d’exclusion. Un utilisateur mal équipé, mal connecté, ou en situation de handicap peut rencontrer des difficultés énormes face à une interface trop lourde, trop animée, trop lente à réagir. En optimisant la performance, on améliore aussi l’accessibilité. On rend les contenus plus rapidement disponibles. On réduit les obstacles techniques. On fluidifie les interactions.

Et ce n’est pas réservé à une minorité. En réalité, tout le monde bénéficie de ces améliorations. Un site accessible, c’est un site plus inclusif, plus agréable à utiliser, et donc plus performant dans tous les sens du terme. La webperf, c’est aussi une question d’équité numérique. Et c’est une dimension que les entreprises commencent enfin à intégrer sérieusement.

Dernier levier, et pas des moindres : la performance web a un impact direct sur le chiffre d’affaires. Chaque seconde de latence en plus, c’est des conversions en moins. Ce n’est pas une théorie, c’est mesuré. Amazon, Booking, Google eux-mêmes ont publié des études montrant qu’une simple seconde de trop peut faire chuter les ventes de manière drastique. Et c’est tout aussi vrai pour les sites institutionnels, les SaaS, les sites e-commerce de taille moyenne.

Quand on améliore la webperf, on améliore l’expérience. Et une meilleure expérience, c’est une meilleure rétention, une meilleure activation, un meilleur taux de clic, une baisse du taux de rebond, une augmentation de la confiance. Chez LATELIER, on le voit sur les projets clients : dès que la performance s’améliore, les métriques business suivent. Ce n’est pas un bonus. C’est un investissement rentable.