PageSpeed Insights : comment lire le rapport — données des utilisateurs, score Lighthouse et réglages du test

PageSpeed Insights affiche deux mesures différentes sur un même écran, et la plupart des malentendus sur le score viennent de ce qu’on lit une moitié du rapport comme si c’était l’autre. La moitié supérieure, ce sont les données réelles des utilisateurs de Chrome sur les 28 derniers jours : pour la page exacte que vous avez saisie, pour toute l’origine, ou rien du tout. La moitié inférieure, c’est un unique chargement simulé de la page par Lighthouse, sur un téléphone de milieu de gamme émulé, avec une connexion bridée et un processeur ralenti.

Google décrit lui-même cette séparation : « Les données de laboratoire sont utiles pour déboguer les problèmes, car elles sont collectées dans un environnement contrôlé. Cependant, cet outil peut ne pas refléter les goulots d’étranglement réels. Les données sur le terrain sont utiles pour capturer l’expérience utilisateur réelle, mais elles comportent un ensemble de métriques plus limité » (À propos de PageSpeed Insights, version française mise à jour le 25 juillet 2025, consultée le 5 octobre 2026). Le laboratoire sert à trouver les causes ; le terrain montre comment la page se comporte pour de vraies personnes.

Confondre les deux produit trois questions récurrentes : pourquoi le score saute alors que rien n’a changé ; pourquoi un 90 vert ne signifie pas que la page réussit l’évaluation Core Web Vitals ; et pourquoi un message d’absence de données s’affiche à la place des données des utilisateurs. Une seule règle répond aux trois : le score de 0 à 100 sert au diagnostic, et ce sont les données de terrain qui décident si une page réussit.

Ce que montre PageSpeed Insights : deux mesures sur un même écran

La moitié supérieure du rapport vient du Chrome User Experience Report (CrUX), la moitié inférieure de Lighthouse — deux sources qui mesurent des choses différentes à des moments différents. Selon la même page de Google, PSI indique les données d’expérience réelle des utilisateurs pour le First Contentful Paint (FCP), l’Interaction to Next Paint (INP), le Largest Contentful Paint (LCP) et le Cumulative Layout Shift (CLS) « sur la période de collecte des 28 derniers jours », ainsi qu’une métrique expérimentale, le Time to First Byte (TTFB).

La fenêtre de 28 jours est glissante. Les données de terrain de PSI sont mises à jour chaque jour, tandis que l’ensemble de données CrUX dans BigQuery est mis à jour tous les mois et ne contient que des données au niveau de l’origine ; les deux couvrent les 28 jours précédents (À propos de PageSpeed Insights, consulté le 5 octobre 2026). Les chiffres du haut du rapport décrivent donc ce que les utilisateurs ont vécu au cours des quatre dernières semaines, pas la version de la page d’aujourd’hui.

La moitié inférieure, c’est Lighthouse : « PSI utilise Lighthouse pour analyser l’URL donnée dans un environnement simulé pour les catégories Performances, Accessibilité, Bonnes pratiques et SEO ». Le test tourne sur les serveurs de Google, et le rapport précise la région d’exécution : « dans l’une des régions suivantes : Amérique du Nord, Europe ou Asie » (même source).

Les deux moitiés peuvent se contredire, et ce n’est pas un bug. La FAQ de Google l’explique : les données de terrain sont un rapport historique sur les performances d’une URL donnée, tandis que les données de laboratoire reposent sur un chargement simulé, sur un seul appareil et dans des conditions réseau fixes ; les valeurs peuvent donc différer (même source). Notre article sur les Core Web Vitals explique plus en détail pourquoi laboratoire et terrain divergent sur telle ou telle métrique.

La moitié supérieure du rapport : les données réelles des utilisateurs

La moitié supérieure de l’écran répond à une seule question : comment la page s’est comportée pour de vraies personnes au cours des 28 derniers jours. Pour la lire correctement, il faut savoir de qui viennent ces données, pourquoi il peut ne pas y en avoir, et ce que signifie le chiffre au-dessus des barres.

Cette page ou toute l’origine

PSI cherche d’abord des données sur la page exacte. S’il n’y en a pas assez, il remonte d’un niveau. Selon Google : « Une page peut ne pas disposer de suffisamment de données si elle a été publiée récemment ou si elle comporte trop peu d’échantillons provenant d’utilisateurs réels. Dans ce cas, PSI revient à la granularité au niveau de l’origine, qui englobe toutes les expériences utilisateur sur toutes les pages du site Web. Il est possible que l’origine ne dispose pas de données suffisantes, auquel cas PSI ne pourra pas afficher de données sur l’expérience utilisateur réelle » (À propos de PageSpeed Insights, consulté le 5 octobre 2026). Dans la réponse de l’API, ce sont deux objets distincts : loadingExperience pour la page et originLoadingExperience pour l’origine (documentation de runPagespeed, consultée le 5 octobre 2026).

Cela explique une chose qui ressemble souvent à un bug : les chiffres d’une page peuvent changer alors que rien n’a bougé sur cette page. Les données d’origine couvrent toutes les pages vues de toutes les pages du site ; une modification d’une autre page, ou un déplacement du trafic entre les pages, fait donc bouger aussi les chiffres de « votre » page. De plus, la fenêtre de 28 jours avance chaque jour et les pages vues les plus anciennes en sortent. Avant de comparer deux relevés, vérifiez qu’ils portent sur le même périmètre.

Pourquoi il peut n’y avoir aucune donnée

Seules les pages publiques et indexables entrent dans CrUX. Selon la méthodologie de CrUX, une page est considérée comme publiquement accessible « si elle répond aux mêmes critères d’indexabilité que les moteurs de recherche » : elle est exclue si, après les redirections, elle répond avec un code d’état autre que 200, si elle porte un en-tête X-Robots-Tag: noindex ou une balise <meta name="robots" content="noindex"> (méthodologie CrUX, page du 20 juin 2024, consultée le 5 octobre 2026).

La seconde condition est la popularité, et Google ne publie pas le seuil : « Nous ne divulguons pas le nombre exact […] Le nombre minimal est le même pour les pages et les origines. » Les pages en dessous ne figurent pas dans l’ensemble de données, et on ne peut pas demander leur ajout : « Pour le moment, vous ne pouvez pas envoyer manuellement des pages ni des origines pour qu’elles soient incluses » (même source). Ne sont comptés que les utilisateurs de Chrome sur ordinateur et Android qui ont activé l’envoi des statistiques d’utilisation et la synchronisation de l’historique, sans phrase secrète de synchronisation ; Chrome sur iOS ne transmet rien à CrUX. Notre article sur les Core Web Vitals détaille ce que l’absence de données de terrain signifie pour le site d’une petite entreprise.

Les barres, et le chiffre au-dessus

Chaque métrique a une barre en trois couleurs : bon, à améliorer et médiocre. L’exemple de Google : « 11 % dans la barre orange du LCP indique que 11 % de toutes les valeurs de LCP observées se situent entre 2 500 ms et 4 000 ms ». Le chiffre au-dessus de la barre n’est pas une moyenne : « Au-dessus des barres de distribution, PSI indique le 75e percentile pour toutes les métriques » (À propos de PageSpeed Insights, consulté le 5 octobre 2026). La valeur au-dessus de la barre du LCP signifie donc que trois quarts des pages vues ont eu un LCP au moins aussi bon, et un quart un LCP moins bon.

Quand une page réussit l’évaluation Core Web Vitals

L’évaluation porte sur trois métriques : INP, LCP et CLS. La règle de PSI comporte deux cas limites : « l’agrégation réussit l’évaluation des métriques Core Web Vitals si les 75e centiles des trois métriques sont bonnes. Sinon, l’agrégation ne passe pas l’évaluation. Si l’agrégation ne dispose pas de suffisamment de données pour l’INP, elle sera approuvée si les 75e centiles du LCP et du CLS sont "Bons". Si les données du LCP ou du CLS sont insuffisantes, l’agrégation au niveau de la page ou de l’origine ne peut pas être évaluée » (même source). L’absence de données INP n’empêche donc pas de réussir, alors que l’absence de données LCP ou CLS rend toute évaluation impossible.

Les seuils des trois métriques (LCP 2,5 s, INP 200 ms, CLS 0,1 au 75e centile) et ce qui les fait échouer sont traités dans notre article sur les Core Web Vitals. Le rapport affiche deux autres métriques qui ne comptent pas pour l’évaluation, mais qui ont leurs propres seuils dans le tableau de PSI (même source) :

• FCP : bon jusqu’à 1 800 ms, à améliorer au-delà de 1 800 ms et jusqu’à 3 000 ms, médiocre au-delà de 3 000 ms ;
• TTFB (expérimental) : bon jusqu’à 800 ms, à améliorer au-delà de 800 ms et jusqu’à 1 800 ms, médiocre au-delà de 1 800 ms.

Deux relevés, 5 octobre 2026

Nous avons vérifié ce que l’API PageSpeed Insights renvoie pour notre propre domaine et pour un site à fort trafic. Pour www.digitalvantage.ch, la réponse ne contenait aucune donnée de terrain, ni pour la page ni pour l’origine : notre site n’a pas assez de mesures dans CrUX. Moins d’une minute plus tard, l’API renvoyait des données de terrain complètes au niveau de la page pour la page d’accueil de web.dev, un site de Google : catégorie globale SLOW, LCP 3 139 ms, INP 218 ms et CLS 0,01 au 75e centile. Même un site consacré à la performance web dépassait donc les seuils du LCP et de l’INP. Il s’agit d’un seul relevé par l’API, pas par l’interface, et il couvre la fenêtre de 28 jours précédant cette date.

La moitié inférieure : d’où vient le score de 0 à 100

Le score de performance est une moyenne pondérée de cinq métriques de laboratoire tirées d’un seul chargement simulé — pas une évaluation de l’expérience des utilisateurs réels. Google donne les plages : un score de 90 ou plus est considéré comme bon, de 50 à 89, il nécessite une amélioration, et en dessous de 50, il est médiocre. Et il ajoute aussitôt une réserve : de bonnes données de laboratoire ne signifient pas nécessairement que l’expérience des utilisateurs réels sera bonne elle aussi (À propos de PageSpeed Insights, consulté le 5 octobre 2026).

Seules les métriques comptent pour le score : « Le score lié aux performances est une moyenne pondérée des scores des métriques » et « seules les métriques contribuent à votre score de performance Lighthouse, et non les résultats des sections "Opportunités" ou "Diagnostic" » (Calcul du score de performance Lighthouse, page du 19 septembre 2019, consultée le 5 octobre 2026 ; pondérations confirmées dans la configuration de Lighthouse, consultée le 3 octobre 2026). Les recommandations sous le score aident à trouver les causes, mais elles n’ajoutent ni ne retirent le moindre point.

Les métriques n’ont pas toutes le même poids. Selon la documentation de Lighthouse, le LCP pèse 25 % et le Total Blocking Time 30 % : ces deux-là font donc 55 % du score ; FCP, Speed Index et CLS se partagent les 45 % restants. Le tableau complet des pondérations, et la raison pour laquelle la métrique la plus lourde n’est pas un Core Web Vital, se trouvent dans notre article sur les Core Web Vitals.

Pourquoi le passage de 90 à 100 est le plus cher

Chaque métrique gagne ses points sur une courbe fondée sur les données de HTTP Archive : « Le 25e centile des données d’archive HTTP devient un score de 50 […] et le 8e centile devient un score de 90 ». La courbe s’aplatit en haut : « pour passer d’un score de 99 à 100, vous devez améliorer la métrique d’environ la même quantité que pour passer de 90 à 94 » (Calcul du score de performance Lighthouse, consulté le 5 octobre 2026). Si quelqu’un vous propose de « monter à 100 », vous payez le tronçon le plus cher de l’échelle.

Pourquoi il n’y a pas d’INP dans la moitié inférieure

Le test de laboratoire de PSI se contente de charger la page. Personne ne clique, il n’y a donc aucune interaction à mesurer. Google l’explique : certains outils de laboratoire ne rapportent pas l’INP d’une page, car ils n’observent que son chargement, sans aucune interaction ; dans ce cas, le Total Blocking Time (TBT) peut être une métrique de substitution raisonnable pour l’INP, mais il ne remplace pas l’INP en tant que tel (web.dev, Interaction to Next Paint, mise à jour le 2 septembre 2025, consultée le 5 octobre 2026). Le TBT mesure le blocage du fil principal pendant le chargement, pas la réaction de la page à un clic précis.

Cela ne veut pas dire que Lighthouse ne peut jamais mesurer l’INP. En mode Période (Timespan), disponible notamment dans le panneau Lighthouse des outils de développement Chrome, Lighthouse enregistre un intervalle pendant lequel vous interagissez vous-même avec la page, et c’est seulement dans ce mode que son audit INP s’exécute (code source de l’audit INP de Lighthouse, consulté le 3 octobre 2026). Mais une telle mesure dépend de ce que vous faites : « la valeur INP obtenue pour une page lors des tests en laboratoire dépendra des interactions effectuées pendant la période de mesure » (web.dev), et un rapport en mode Période ne produit pas de score de performance global (Lighthouse, user flows, consulté le 3 octobre 2026). Notre article sur les Core Web Vitals explique en quoi l’INP diffère du TBT, et ce qui le dégrade.

Mobile et ordinateur : quels réglages utilise PageSpeed Insights

Le rapport a deux onglets, Mobile et Bureau, et chacun mesure avec des hypothèses différentes sur l’appareil, la connexion et le processeur. Les réglages mobiles modélisent une connexion mobile faible. La documentation de Lighthouse indique que la limitation du réseau vise à émuler la vitesse de connexion mobile du 85e centile environ ; un profil avec 150 ms de latence et 1,6 Mbit/s en réception / 750 kbit/s en envoi représente « à peu près les 25 % de connexions 4G les plus lentes et les 25 % de connexions 3G les plus rapides » (traduction libre), et ce profil s’appelle « Slow 4G » — il portait autrefois le nom « Fast 3G » (Lighthouse, Network Throttling, consulté le 3 octobre 2026). Dans l’interface française de PSI, il apparaît comme « Connexion 4G lente ». Ce n’est pas de la 4G au sens courant, mais une connexion mobile faible.

Le processeur est ralenti d’un facteur quatre : par défaut, Lighthouse applique un multiplicateur constant de 4x, qui, selon la même documentation, fait passer un test typique de la catégorie des ordinateurs haut de gamme « quelque part dans la catégorie des mobiles de milieu de gamme » (même source, traduction libre). L’appareil émulé est un moto g power (2022) : la configuration de Lighthouse le nomme, et le même modèle figurait dans l’en-tête user-agent de la réponse de l’API PSI que nous avons reçue le 3 octobre 2026 (Chrome 153). L’ordinateur est mesuré avec 40 ms de latence, 10 Mbit/s de débit et sans ralentissement du processeur. La page « À propos de PageSpeed Insights » cite encore un téléphone plus ancien ; sur ce point, c’est le code de Lighthouse qui fait foi.

Une réserve sur ce tableau. PSI ne publie pas ces valeurs, et son API ne les renvoie pas. Elles viennent du code de Lighthouse, et l’affirmation selon laquelle PSI les utilise repose sur une phrase de la documentation de Lighthouse : la limitation simulée « reste le réglage par défaut. Cela correspond à la configuration de PageSpeed Insights et au réglage par défaut de Lighthouse CLI » (Lighthouse, Network Throttling, traduction libre).

Une limitation simulée, pas physique

« Simulée » est à prendre au pied de la lettre. PSI ne bride pas physiquement la connexion ni le processeur pendant le test. Lighthouse charge la page sans restriction, puis calcule comment ce chargement se serait déroulé sur un réseau lent et un processeur plus faible : la limitation simulée « utilise une simulation du chargement de la page, fondée sur les données observées lors du chargement initial non bridé » (même source, traduction libre). C’est pourquoi la documentation prévient que si vous ouvrez ensuite la trace d’origine, ses valeurs ne correspondront pas aux résultats de Lighthouse, puisque cette trace précède la simulation. La même documentation reconnaît ouvertement que la simulation a ses cas limites et que d’autres méthodes conviennent mieux à une investigation approfondie.

Cela explique pourquoi un score PSI diffère d’un score Lighthouse obtenu en local sur une machine rapide. En local, la simulation part d’un chargement mesuré sur votre matériel et votre connexion, et le ralentissement de 4x du processeur s’applique à votre machine, pas au serveur de Google ; la documentation de Lighthouse précise d’ailleurs que sur une machine plus faible, on peut réduire ce multiplicateur (même source). On peut aussi choisir une autre méthode, la limitation DevTools, qui ralentit les requêtes elles-mêmes.

Pourquoi le mobile obtient un moins bon score, et ce que cela implique pour l’API

Le score mobile est généralement plus bas pour une raison simple : le profil suppose un réseau plus lent et un processeur quatre fois plus lent, si bien que chaque kilo-octet et chaque milliseconde d’exécution de script coûtent plus cher. De plus, depuis Lighthouse 6, l’ordinateur a ses propres courbes de notation, plus strictes (Calcul du score de performance Lighthouse) ; les scores des deux onglets ne se comparent donc pas point par point. Notre article sur le responsive design aborde comment concevoir un site en pensant d’abord aux téléphones.

Un piège de la mesure automatisée : le paramètre strategy de l’API est décrit comme « La stratégie d’analyse (ordinateur ou mobile) à utiliser (l’ordinateur est la stratégie par défaut) » (documentation de runPagespeed, version française mise à jour le 25 juillet 2025, consultée le 5 octobre 2026). Un script qui appelle l’API sans strategy=mobile mesure l’ordinateur, le profil le plus clément.

Pourquoi le score PageSpeed change alors que vous n’avez rien modifié

Le score de laboratoire est conçu pour varier d’un passage à l’autre ; un test isolé ne prouve donc jamais qu’une chose s’est améliorée ou dégradée. La documentation de Lighthouse le dit sans détour : les scores de performance Lighthouse changent en raison de la variabilité inhérente aux technologies du web et des réseaux, même sans aucune modification du code ; il faut exécuter Lighthouse plusieurs fois et tenir compte de cette variabilité avant de tirer des conclusions (Lighthouse, Score Variability, consulté le 3 octobre 2026).

Le même document évalue la probabilité de chaque source de variabilité dans PageSpeed Insights :

• certaine : le non-déterminisme du navigateur ;
• probable : le non-déterminisme de la page elle-même, et du serveur qui l’héberge ;
• possible : le réseau de transit et le partage de ressources sur la machine de test ;
• peu probable : le réseau local et le matériel du client.

Le dernier point compte en pratique : dans PSI, votre Wi-Fi et votre ordinateur portable ont peu de chances d’expliquer les écarts, puisque le test tourne sur les serveurs de Google. Dans les outils de développement Chrome, où le test tourne sur votre propre ordinateur, le matériel et sa charge comptent bel et bien (nous y revenons plus bas). La page de Google sur le calcul du score cite aussi des causes côté site : tests A/B, modifications des annonces diffusées, routage du trafic (Calcul du score de performance Lighthouse). Si une page charge un jeu d’annonces différent à chaque fois, chaque test mesure une page légèrement différente.

Nous l’avons vérifié le 3 octobre 2026 sur developer.chrome.com, un site de Google. Trois passages PSI sur l’onglet mobile en cinq minutes ont donné 55, 62 et 72, alors que la moitié supérieure affichait chaque fois les mêmes données des utilisateurs : LCP 3,1 s, INP 297 ms, CLS 0,02. L’écart de 17 points est la variabilité propre au test, et rien d’autre.

La réponse, c’est l’agrégation. Le document de Lighthouse l’affirme : le score Lighthouse médian de 5 passages est deux fois plus stable qu’un passage unique, et il recommande d’agréger les valeurs — médiane, 90e centile, voire minimum et maximum — plutôt que de se fier à des résultats de tests isolés (même source). Nous exécutons le test cinq fois et retenons la médiane ; la procédure complète figure dans notre article Tester un site web.

Quelle adresse saisir dans PageSpeed Insights

Testez l’adresse finale, celle à laquelle la page s’ouvre réellement, et non une variante qui redirige. Lorsque nous avons passé https://digitalvantage.ch/ (sans « www ») dans l’API PSI le 5 octobre 2026, le résultat est arrivé avec un avertissement selon lequel l’URL testée « was redirected to https://www.digitalvantage.ch/. Try testing the second URL directly. » (l’API renvoie ce message en anglais). Depuis 2022, « PSI tentera de suivre les redirections 3XX avant de transmettre cette URL à Lighthouse » (notes de version de PSI, entrée du 10 mai 2022, consultée le 5 octobre 2026), mais l’avertissement indique clairement quelle adresse il vaut la peine de mesurer.

Pour les données de terrain, c’est l’adresse sous la forme que connaît CrUX qui compte. La méthodologie de CrUX pose trois règles (méthodologie CrUX, consultée le 5 octobre 2026) :

• les paramètres de requête et les fragments sont supprimés : pour CrUX, une adresse avec ?utm_medium=email ou #main est la même que sans ;
• dans les applications monopages (SPA), les transitions entre vues sont attribuées à la première page vue ;
• une page en noindex, ou qui répond avec un code d’état autre que 200, n’a aucune donnée de terrain.

Encore un point : ne testez pas seulement la page d’accueil. Dans le Web Almanac 2025, les pages d’accueil réussissaient les Core Web Vitals moins souvent que les autres pages (détails plus bas). Mesurez les pages sur lesquelles les gens arrivent réellement depuis la recherche et la publicité.

Lighthouse dans les outils de développement Chrome ou PageSpeed Insights

Lighthouse est le moteur de PSI, mais lancé dans votre propre navigateur, il mesure aussi votre ordinateur. Google le décrit comme « un outil automatisé Open Source » que l’on peut exécuter « dans les outils de développement Chrome, à partir de la ligne de commande ou en tant que module Node » (présentation de Lighthouse, page du 2 juin 2025, consultée le 5 octobre 2026). Dans Chrome, c’est un panneau à part des outils de développement (DevTools).

La documentation du panneau décrit les différences (Lighthouse dans les outils de développement Chrome, mise à jour le 15 octobre 2025, consultée le 5 octobre 2026) :

• le score dépend de votre propre configuration : « Lighthouse est influencé par votre configuration, y compris par les autres chargements en cours sur votre appareil, les extensions Chrome et tous les paramètres de l’appareil que vous avez stockés dans des cookies, le stockage local ou des éléments similaires » ;
• la navigation privée aide, mais pas entièrement : « même dans ce cas, il peut toujours être soumis à ces influences » ;
• c’est pourquoi « vous ne pouvez pas comparer directement deux audits Lighthouse effectués sur des machines différentes » ;
• PSI et les outils d’intégration continue tournent sur des serveurs distincts et « peuvent générer des audits Lighthouse plus "propres" et plus cohérents ».

En contrepartie, les DevTools savent faire ce que PSI ne fait pas. Ils peuvent auditer une page derrière une connexion : Google cite parmi les usages de Lighthouse le fait d’auditer « les pages qui nécessitent une authentification » (présentation de Lighthouse). Ils permettent de choisir l’appareil et les catégories d’audit : « De nombreux outils Lighthouse (par exemple, PageSpeed Insights) ne permettent pas de choisir le type d’appareil ni les catégories d’audit ». Outre le mode Navigation par défaut, ils proposent les modes Période et Instantané, ainsi que la limitation DevTools à côté de la limitation simulée.

La répartition pratique : PSI pour des mesures comparables de pages publiques, les DevTools pour les pages derrière une connexion et pour le travail sur une interaction précise. Pour remonter à la cause d’un problème, Google renvoie ailleurs : « Lorsque vous utilisez les outils de développement pour déboguer des problèmes de performances, nous vous recommandons d’utiliser le panneau Performances plutôt que Lighthouse » (même source).

Lighthouse 13 : les audits deviennent des « insights »

Si vous comparez un rapport avec un guide d’il y a un an, la liste des recommandations sous le score peut sembler complètement différente ; la notation, elle, n’a pas changé. Lighthouse 13.0 (article du blog Chrome du 10 octobre 2025) a remplacé les anciens audits de performance par des « insights », partagés avec le panneau Performances des DevTools. Google est explicite : « Cette version de Lighthouse n’apporte aucune modification au score de performances, qui est basé sur les métriques plutôt que sur les audits. Seuls les audits sans score sont concernés » (Lighthouse 13.0, consulté le 5 octobre 2026).

Pour qui lit un rapport, cela signifie deux choses. Les captures d’écran et les listes d’« opportunités » des anciens guides peuvent ne pas correspondre à ce que vous voyez. Et le score de 0 à 100 se calcule comme avant, à partir des mêmes cinq métriques avec les mêmes pondérations.

La dernière version est Lighthouse 13.5.0, publiée le 18 septembre 2026 (versions de Lighthouse sur GitHub, consulté le 3 octobre 2026). Dans nos appels à l’API PSI du 3 octobre 2026, le champ lighthouseVersion indiquait 13.5.0 : PSI tournait donc avec cette version.

L’API PageSpeed Insights : la clé, les limites et un changement annoncé

L’API PageSpeed Insights renvoie les mêmes données que l’interface, mais ses valeurs par défaut diffèrent, et un changement annoncé concerne quiconque construit un suivi automatisé. La clé est facultative : selon la documentation, l’API fonctionne avec ou sans clé API, mais une clé est recommandée pour des requêtes fréquentes et automatisées (PSI API, Get Started, en anglais, page du 28 août 2025, consultée le 3 octobre 2026 ; la version française ne reprend pas cette phrase).

La documentation de PSI ne chiffre pas les limites. Sans clé, on atteint vite une limite ; avec une clé, la limite s’affiche dans la console Google Cloud. Notre propre appel sans clé du 3 octobre 2026 a renvoyé un HTTP 429 indiquant que le quota journalier était dépassé, avec un quota affiché à 0. C’est une observation isolée : nous ne savons pas s’il s’agit d’un réglage fixe ou d’un pool partagé épuisé.

Deux valeurs par défaut piègent les gens dans leur premier script. Sans le paramètre category, l’API n’exécute que la performance : « Si aucune n’est spécifiée, seule la catégorie "Performances" sera utilisée ». Sans strategy, elle mesure l’ordinateur (documentation de runPagespeed). Les données de terrain reviennent sous forme de deux objets : loadingExperience pour la page et originLoadingExperience pour l’origine.

Le plus important est une annonce figurant dans la documentation elle-même : « Nous prévoyons de ne plus inclure les données réelles du rapport d’expérience utilisateur Chrome dans cette API. Nous vous recommandons d’utiliser l’API CRUX (guide) ou l’API CRUX History (guide) à la place » (API PSI, premiers pas). Google n’a donné aucune date, et le 5 octobre 2026, l’API renvoyait encore des données de terrain. Si vous construisez un suivi sur la durée, prenez d’emblée les données de terrain dans l’API CrUX : elle est « proposée sans frais », limitée à « 150 requêtes par minute et par projet Google Cloud », mise à jour chaque jour « vers 4h UTC » sans horaire garanti, et elle a « environ deux jours de retard » sur la date du jour (API CrUX, page du 11 février 2025, consultée le 5 octobre 2026).

Où se situent les autres sites : Web Almanac 2025

À peu près un site sur deux dans le monde a de bons Core Web Vitals, et la comparaison entre les années montre que les deux moitiés d’un rapport PSI évoluent réellement de façon indépendante. Le chapitre 7, « Performance », du Web Almanac 2025 repose sur les mesures de juillet 2025 de HTTP Archive et de CrUX (Web Almanac 2025, Performance, en anglais, publié le 15 janvier 2026, consulté le 3 octobre 2026). Ce sont des chiffres mondiaux, sans ventilation par pays.

Selon le Web Almanac, 48 % des sites avaient de bons Core Web Vitals sur mobile en 2025 et 56 % sur ordinateur, contre 44 % et 55 % un an plus tôt, et 36 % et 48 % en 2023. Les mille sites les plus populaires ne font qu’un peu mieux : 51 % et 59 %. Les pages d’accueil réussissaient moins souvent que les autres pages — 45 % sur mobile et 47 % sur ordinateur, contre 56 % et 61 % (même source).

Par métrique, les parts de bons résultats sur mobile et sur ordinateur étaient : LCP 62 % et 74 %, INP 77 % et 97 %, CLS 81 % et 72 %. La comparaison la plus parlante oppose laboratoire et terrain. Le TBT médian de laboratoire sur mobile est passé de 1 209 ms en 2024 à 1 916 ms en 2025, tandis que la part des pages avec un bon INP de terrain sur mobile progressait sur la même période, de 74 % à 77 % (même source). L’indicateur de laboratoire s’est dégradé pendant que l’indicateur de terrain s’améliorait — c’est précisément pourquoi la moitié inférieure d’un rapport ne doit pas être lue comme une prévision de la moitié supérieure. Les résultats par plateforme e-commerce, tirés du chapitre 13 du même rapport, figurent dans notre article sur les Core Web Vitals pour l’e-commerce.

Que faire du résultat

La suite dépend de la moitié du rapport dont vous disposez. Si la moitié supérieure affiche des données de terrain et que l’évaluation échoue, commencez par la métrique hors de son seuil ; notre article sur les Core Web Vitals explique ce qui la cause, et dans quel ordre corriger. S’il n’y a pas de données de terrain, traitez le score Lighthouse comme un diagnostic et mesurez selon une procédure, pas avec un test isolé : voir notre article Tester un site web. Pour évaluer de nombreuses pages à la fois, utilisez le rapport Core Web Vitals de Google Search Console, qui regroupe les pages similaires ; Google précise que les statistiques PSI d’une page isolée peuvent ne pas correspondre aux résultats du groupe dans ce rapport (aide Search Console, rapport Core Web Vitals, en anglais, consultée le 3 octobre 2026). Comment lire ce rapport et les autres, c’est l’objet de notre article sur Google Search Console.

Vous pouvez voir les deux moitiés du rapport pour votre propre site dans notre test de vitesse de site web. Il affiche les données réelles des utilisateurs de Chrome sur les 28 derniers jours, avec la mention « page » ou « site entier » (ou un message indiquant qu’il n’y en a pas), et les évalue selon les seuils des Core Web Vitals. Il montre séparément un test de laboratoire Lighthouse, dans lequel le TBT tient lieu d’INP.