Qu'est-ce que PageSpeed Insights (PSI) ?

Qu'est-ce que PageSpeed Insights (PSI) ?

PageSpeed Insights (PSI) est l'outil gratuit d'analyse de performance web de Google. Entrez n'importe quelle URL sur pagespeed.web.dev et PSI renvoie une carte de score de performance combinant deux sources de données distinctes : données de laboratoire (un audit synthétique frais de Lighthouse exécuté depuis un data center Google) et données de terrain (métriques d'utilisateurs réels du Chrome User Experience Report couvrant les 28 derniers jours). L'outil fait ensuite remonter des recommandations spécifiques et priorisées pour améliorer la vitesse de la page.

PSI est l'outil de performance le plus cité dans les discussions SEO pour une raison : c'est le visage public du programme Core Web Vitals de Google. Les scores que vous voyez dans PSI correspondent directement aux signaux que Google utilise pour le ranking. "PSI s'est-il amélioré ?" est la question qui termine la plupart des débats de performance.

Les deux moitiés de PSI : données de laboratoire vs. données de terrain

Comprendre PSI nécessite de comprendre les deux types de données complètement différents qu'il montre. Ils répondent à des questions différentes.

Données de terrain (CrUX) — "comment les utilisateurs réels expérimentent-ils cette page ?"

Le Chrome User Experience Report (CrUX) est un dataset public de métriques de performance anonymisées collectées d'utilisateurs réels Chrome (ceux qui ont opté pour la synchronisation de l'historique du navigateur). PSI affiche les valeurs du 75e percentile sur les 28 derniers jours pour cette URL ou origine.

Les quatre métriques CrUX dans PSI :

• LCP (Largest Contentful Paint) — quand le plus grand élément above-fold se rend. Bon : ≤2,5s.
• INP (Interaction to Next Paint) — réactivité à l'input utilisateur. A remplacé FID en mars 2024. Bon : ≤200ms.
• CLS (Cumulative Layout Shift) — stabilité visuelle. Bon : ≤0,1.
• FCP (First Contentful Paint) et TTFB (Time to First Byte) — diagnostique, pas pass/fail.

Les données de terrain sont ce que Google utilise pour le signal de ranking Core Web Vitals. Si les données de terrain manquent (page à faible trafic), Google se replie sur les données au niveau origine, puis aucun signal du tout.

Données de laboratoire (Lighthouse) — "à quelle vitesse cette page peut-elle se charger dans des conditions idéales ?"

Les données de laboratoire viennent d'un audit Lighthouse frais sur un appareil mobile ou desktop simulé avec un réseau bridé. C'est reproductible (mêmes conditions à chaque exécution) et diagnostique (Lighthouse génère une liste d'opportunités).

Les métriques de laboratoire dans PSI :

• FCP, LCP, CLS — mêmes métriques, mais mesurées en conditions de laboratoire.
• TBT (Total Blocking Time) — proxy pour INP. Temps pendant lequel le main thread était bloqué durant le chargement de la page.
• Speed Index — à quelle vitesse le contenu visible se peint pendant le chargement.
• Score de Performance (0-100) — moyenne pondérée des métriques de laboratoire.

Le score PSI : comment il est calculé

Le score de Performance est une combinaison pondérée de métriques de laboratoire avec ces poids (à partir de Lighthouse 10) :

• LCP : 25%
• TBT : 30%
• CLS : 25%
• FCP : 10%
• Speed Index : 10%

Chaque métrique est mappée à un score 0-100 utilisant une courbe log-normale calibrée contre les top 1000 sites. Un 100 signifie "dans le palier supérieur des pages rapides". Un 50 signifie médian.

Google appelle 90+ "bon", 50-89 "a besoin d'amélioration" et en dessous de 50 "pauvre". La plupart des sites de production en 2026 scorent 50-80 mobile et 80-95 desktop. Atteindre 90+ sur mobile est vraiment difficile et nécessite une optimisation délibérée.

Score mobile vs. desktop

PSI lance deux audits : un avec un Slow 4G simulé + bridage d'appareil mobile mid-tier, et un avec une vitesse desktop câble simulée. Le score mobile est presque toujours plus bas parce que l'appareil simulé est plus lent.

Le signal de ranking de Google utilise les données de terrain mobile. Les scores desktop sont utiles pour le diagnostic mais n'affectent pas directement le SEO. Optimisez d'abord pour l'expérience mobile.

Le moteur de recommandations : opportunités et diagnostics

Sous les scores, PSI fait remonter une liste priorisée de problèmes. Deux types :

• Opportunités — économies quantifiées, par ex., "Dimensionner correctement les images : économies estimées 1,2s." Ce sont des choses concrètes à corriger qui devraient améliorer votre score.
• Diagnostics — résultats qualitatifs, par ex., "Éviter une taille DOM excessive." Contexte utile mais aucune estimation directe d'économies.

Les opportunités les plus courantes (selon notre expérience d'audit de milliers de sites) :

1. Dimensionner correctement les images (images servies plus grandes qu'affichées)
2. Différer les images hors écran (images below-fold chargées avec empressement)
3. Éliminer les ressources bloquantes au rendu (CSS/JS dans head)
4. Réduire le JavaScript inutilisé (bloat de bundle)
5. Servir les images en formats next-gen (pas de WebP/AVIF)
6. Réduire le CSS inutilisé (feuilles de style sur-expédiées)
7. Minifier CSS/JavaScript (assets non compressés)
8. Activer la compression de texte (pas de gzip/brotli)
9. Preconnect aux origines requises (domaines tiers critiques)
10. Éviter d'enchaîner les requêtes critiques (profondeur de cascade)

Erreurs courantes d'interprétation du score PSI

• Chasser un score de 100. Les rendements décroissants frappent fort au-dessus de 90. Optimiser 95→100 prend souvent plus de temps de dev que 70→90 et apporte moins de bénéfice dans le monde réel.
• Traiter chaque exécution PSI comme faisant autorité. Les scores de laboratoire PSI ont une variance de ±5 points d'une exécution à l'autre à cause du bruit de simulation réseau. Ne réagissez pas à un seul changement de score ; regardez les tendances à travers plusieurs exécutions.
• Ignorer les données de terrain. Les données de laboratoire vous disent ce qui est possible ; les données de terrain vous disent ce que les utilisateurs expérimentent vraiment. Si votre LCP de terrain est mauvais mais que le LCP de laboratoire est bon, votre problème est la distribution géographique, la variance d'appareils réels ou les scripts tiers qui ne chargent pas dans les conditions de laboratoire.
• Optimiser pour le score au lieu de l'expérience. Certaines optimisations améliorent le score sans aider les utilisateurs (par ex., code splitting agressif qui rend les interactions plus lentes). Validez toujours avec de vrais utilisateurs (données RUM) après des changements PSI.
• Oublier le décalage du signal de ranking. Les données CrUX sont une fenêtre glissante de 28 jours. Si vous expédiez une optimisation aujourd'hui, il faudra 4 semaines avant que les données de terrain ne la reflètent pleinement.
• Comparer PSI à d'autres outils sans normaliser. WebPageTest, GTmetrix et PSI utilisent différents profils de bridage. La même page peut scorer 65 sur PSI mobile et 85 sur GTmetrix. Les chiffres ne sont pas comparables entre outils — choisissez-en un et tenez-vous y.

PSI vs. Lighthouse vs. Chrome DevTools Performance

Trois outils liés, différents cas d'usage :

• PSI — orienté public, inclut des données de terrain, facile à partager. Mieux pour les audiences produit/exec et les vérifications rapides.
• Lighthouse (DevTools ou CLI) — fonctionne sur votre machine locale, pas de données de terrain, itération plus rapide. Mieux pour le travail d'optimisation active.
• Onglet Performance de Chrome DevTools — graphiques en flammes, profilage JavaScript, pas de scoring. Mieux pour l'analyse profonde de cause racine.

Automatiser les vérifications PSI en CI

Ne vous fiez pas aux exécutions manuelles de PSI. Meilleure pratique : automatisez les audits Lighthouse dans votre pipeline CI (en utilisant lighthouse-ci) et faites échouer le build si la performance régresse en dessous d'un seuil. Cela attrape les régressions avant qu'elles ne touchent la production. La plupart des équipes web matures ont des gates Lighthouse-CI pour les pages principales.

FAQ : PageSpeed Insights

Pourquoi mon score PSI est-il si bas ?

Coupables les plus probables : JavaScript bloquant au rendu dans le head, images non optimisées, layout shifts dus à du contenu chargé tardivement et scripts tiers (analytics, pubs, widgets de chat). Les diagnostics de PSI les classeront pour vous. Commencez par le haut.

Le score PSI affecte-t-il le ranking SEO ?

Indirectement. Le signal de ranking est les Core Web Vitals, qui utilisent les données de terrain (CrUX) — pas le score de laboratoire PSI. Un score de laboratoire élevé avec de mauvaises données de terrain n'aidera pas le SEO. Un taux parfait de réussite de données de terrain avec un score de laboratoire médiocre c'est bien.

Pourquoi mes scores PSI fluctuent-ils ?

Les scores de laboratoire fluctuent parce que Lighthouse utilise un bridage réseau simulé qui ajoute du hasard. Lancez 3-5 audits et utilisez la médiane. Les données de terrain fluctuent en raison des changements dans le mix d'appareils utilisateurs, la distribution géographique et les patterns de trafic.

Pourquoi le score desktop est-il à 90+ mais mobile dans les 50 ?

Les appareils mobiles sont considérablement plus lents que les desktops, surtout sur du matériel mid-tier simulé avec bridage Slow 4G. L'exécution JavaScript est 4-6x plus lente sur mobile, le réseau est bridé et les goulots d'étranglement du main thread ont plus d'impact. L'optimisation mobile-d'abord est plus difficile.

Comment améliorer les scores PSI ?

Top trois actions pour la plupart des sites : (1) optimiser les images — dimensionnement correct, format WebP/AVIF, lazy loading below-fold ; (2) réduire le JavaScript — code split, différer les scripts non critiques, éliminer les bibliothèques inutilisées ; (3) éliminer le blocage au rendu — inline le CSS critique, defer/async JS, preload les polices. Le test de vitesse LoadFocus montre les mêmes diagnostics avec une couverture multi-localisations.

À quelle fréquence devrais-je vérifier PSI ?

Pour le travail d'optimisation active, quotidien. Pour le monitoring, mensuel ça va — configurez Lighthouse-CI automatisé dans votre pipeline de build pour ne pas avoir à vous souvenir.

Comment LoadFocus complète PSI

PSI teste une URL depuis un data center Google. Les tests de vitesse de site web LoadFocus lancent le même audit Lighthouse depuis 30+ localisations dans le monde, faisant remonter des différences géographiques de performance que PSI ne peut pas voir. Le monitoring continu trace les Core Web Vitals dans le temps pour que vous attrapiez les régressions le jour où elles surviennent, pas 4 semaines plus tard quand le signal de données de terrain arrive.