Depuis le 27 octobre 2026, PageSpeed Insights utilise Lighthouse 13.6.0, dont la simulation Lantern a été retravaillée pour estimer le FCP et le LCP. Les scores de laboratoire en ressortent le plus souvent plus élevés, surtout sur les sites riches en JavaScript. Un score qui grimpe cette semaine ne prouve rien sur le site : il faut vérifier que les deux rapports comparés citent la même version de Lighthouse et regarder les données de terrain CrUX, pas seulement le score de laboratoire.
Sommaire
PageSpeed Insights utilise désormais Lighthouse 13.6.0, une version publiée le 27 octobre 2026 avec une refonte de Lantern, la simulation qui estime le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP).12 Barry Pollard, du pôle performance web de Chrome, a indiqué sur Bluesky que ces mesures simulées deviennent plus justes et donnent en général des scores plus élevés, surtout sur les sites très chargés en JavaScript.1 Cet article revient sur ce que la mise à jour change dans la simulation et sur la façon de lire un rapport de vitesse sans confondre une amélioration du site avec un effet du changement d'outil.
01Pourquoi un score peut grimper sans rien changer au site
Le score de performance affiché par PageSpeed Insights vient d'une simulation Lighthouse, pas d'une mesure sur l'appareil réel d'un visiteur.3 Changer cette simulation peut donc faire bouger le score d'une page qui n'a reçu aucune modification.1
Lighthouse 13.6.0, publié le 27 octobre
Les notes de version du dépôt GoogleChrome/lighthouse datent la sortie de 13.6.0 au 27 octobre 2026 et annoncent que l'équipe attend un déploiement dans les DevTools de Chrome 159, puis dans PageSpeed Insights sous une semaine.2 Search Engine Journal rapporte que PageSpeed Insights a bien basculé sur cette version.1
Les sites riches en JavaScript, les plus concernés
Pollard a commenté le cas d'un développeur qui avait constaté une nette amélioration des résultats d'applications à page unique depuis la mise à jour, en citant react.dev comme exemple.1 Il a précisé que l'effet ne se limite pas aux applications à page unique mais touche plus largement les sites fortement dépendants de JavaScript.1
02Ce que Lantern simule différemment depuis la 13.6
Les notes de version listent plusieurs changements dans Lantern, la simulation qui estime la vitesse de chargement sans la mesurer réellement.2 Deux d'entre eux touchent directement au calcul du FCP et du LCP, un troisième concerne un audit distinct, tourné vers les robots IA.
Le réseau et les connexions
Lantern traite désormais les connexions HTTP/3 comme multiplexées, crédite les octets de dépassement H2 consommés entre les étapes de la simulation, exclut les requêtes sans connexion du calcul des connexions actives et améliore l'estimation du temps d'aller-retour et du débit par origine.2
Le LCP textuel calculé depuis les mêmes requêtes que le FCP
Quand l'élément du LCP est un texte qui apparaît dans la même frame que le premier contenu de la page, Lantern estime maintenant ce LCP à partir des mêmes requêtes et tâches que celles utilisées pour le FCP, plutôt qu'à partir d'un ensemble pouvant inclure toute requête faite avant le LCP.2 Ivan Akulov a montré, dans un ticket GitHub, comment l'ancienne simulation traitait une page de test créée avec Framer dont le seul contenu au-dessus de la ligne de flottaison était un texte : ce même élément comptait pour le FCP et pour le LCP, mais Lighthouse donnait un LCP simulé bien plus tardif que le FCP.1 Précharger les modules JavaScript de la page améliorait le temps d'interactivité réel de cette page, mais aggravait ce LCP simulé.1 Pollard a remercié Akulov d'avoir contribué à ces améliorations, et l'équipe Lighthouse a fermé le ticket comme résolu par la mise à niveau de Lantern listée dans les notes de la 13.6.1
Un changement côté GEO : l'audit ARD cherche désormais ard.json
Lighthouse 13.6 met aussi à jour l'audit de découverte des ressources agentiques (ARD) à la version 0.91 de la spécification : il cherche une ligne Agentmap dans le robots.txt, une balise ou un en-tête Link rel="ard", et le fichier /.well-known/ard.json, avant de se replier sur l'ancien nom ai-catalog.json.2 La version 13.5 ne cherchait encore que cet ancien nom, alors que la spécification avait déjà changé pour ard.json : un site qui n'utilisait que le nouveau nom sans ligne Agentmap dans son robots.txt ressortait donc comme non applicable.1 Vérifier quelles règles du robots.txt s'appliquent aux robots IA permet de voir si une ligne Agentmap ou une règle équivalente est déjà en place avant de s'inquiéter d'un audit ARD négatif.
03Comment lire un rapport de vitesse sans se tromper
La mise à jour ne change rien pour l'internaute qui charge réellement la page. Elle change seulement la simulation de laboratoire, ce qui impose deux réflexes avant de commenter un score.
Données de laboratoire contre données de terrain
Selon la documentation de PageSpeed Insights, les données de laboratoire viennent d'un chargement simulé sur un seul appareil et un ensemble fixe de conditions réseau, et Google précise que de bonnes données de laboratoire ne garantissent pas que l'expérience des vrais utilisateurs sera, elle aussi, bonne.3 Les données de terrain, affichées dans le même rapport, représentent les visites réelles des 28 derniers jours, telles que les rapporte le Chrome User Experience Report (CrUX).1 Le détail des deux blocs d'un rapport PageSpeed Insights explique comment les lire côte à côte sans les additionner.
Vérifier la version de Lighthouse avant de comparer deux rapports
Chaque rapport PageSpeed Insights indique la version de Lighthouse utilisée, à côté de l'appareil simulé.1 Deux rapports pris avant et après le 27 octobre n'ont pas été mesurés avec la même simulation : une partie d'un score de laboratoire plus élevé sur une page qu'on vient d'optimiser peut venir de la nouvelle version, et un graphique qui suit le score dans le temps peut afficher un saut au moment du basculement vers la 13.6.1 Avant de signaler une amélioration, il faut vérifier que les deux rapports comparés citent la même version de Lighthouse, et regarder aussi les données de terrain.1
Pour voir l'effet sur un site réel, j'ai lancé Lighthouse 13.5.0 puis 13.6.0 en ligne de commande sur react.dev, l'exemple cité plus haut, depuis le même poste, trois mesures par version. En mobile, le score de performance médian passe de 65 à 94 : le LCP simulé tombe de 7,3 s à 1,3 s et le TBT de 270 ms à 140 ms. En bureau, le score passe de 99 à 100. Sur nemociment.fr, un site statique avec peu de JavaScript, le sens est inverse : le score mobile médian passe de 79 à 72 et le bureau reste à 96. L'effet dépend donc de la page, et un score peut aussi baisser sans que le site ait bougé.
Le piège classique du reporting client
Pour un prestataire qui suit la vitesse d'un site client, un score qui grimpe la semaine du 27 octobre sans action technique de son côté est le piège classique : rien, dans le seul chiffre affiché, ne distingue l'effet du changement de simulation d'une vraie amélioration.1 L'audit technique qui suit aussi les Core Web Vitals s'appuie sur les données de terrain d'un site, qui ne bougent pas avec une mise à jour de Lighthouse.