Comment utiliser PageSpeed Insights pour accélérer vos pages ?

PageSpeed Insights analyse la performance d'une page web sur mobile et sur ordinateur, puis indique ce qui freine son affichage ou sa réactivité. Un client me demandait récemment pourquoi son score restait bloqué à 62 alors que son site semblait rapide sur son téléphone. La réponse se trouvait quelques lignes plus bas dans le rapport : ses visiteurs réels subissaient un affichage tardif de l'image principale.

La note sur 100 attire immédiatement le regard. Elle ne suffit pourtant pas à juger une page. Pour exploiter correctement PageSpeed Insights, il faut distinguer les données collectées auprès de vrais visiteurs, les mesures produites par Lighthouse dans un environnement simulé et les recommandations techniques. Ce sont ces trois niveaux qui transforment un chiffre isolé en plan de travail.

Qu'est-ce que PageSpeed Insights ?

PageSpeed Insights est un outil gratuit de Google qui mesure l'expérience offerte par une page sur mobile et sur ordinateur. Il rassemble, lorsqu'elles sont disponibles, des données réelles issues du rapport d'expérience utilisateur Chrome et un audit de laboratoire réalisé avec Lighthouse. Il signale ensuite les causes possibles des lenteurs observées.

L'outil travaille sur une URL précise. Il ne réalise donc pas un audit exhaustif du domaine. Une page d'accueil légère peut obtenir une bonne note tandis qu'une fiche produit, chargée d'images, de variantes et de scripts tiers, reste lente. Pour obtenir une vision utile du site, il faut tester plusieurs modèles de pages.

Quelles informations l'outil affiche-t-il ?

Le rapport débute généralement par l'évaluation des Core Web Vitals. Cette première partie s'appuie sur l'expérience de véritables utilisateurs Chrome lorsqu'un volume de données suffisant existe. Elle indique si la page, ou parfois son origine, satisfait les critères définis par Google.

Plus bas, le rapport Lighthouse présente une note de performance comprise entre 0 et 100. Cette note vient d'un chargement simulé dans des conditions définies par l'outil. Elle s'accompagne de métriques détaillées, puis d'audits qui aident à retrouver les ressources ou les traitements responsables du résultat.

PageSpeed Insights classe enfin ses observations dans plusieurs rubriques. Selon la version de Lighthouse employée, leur intitulé et leur organisation peuvent évoluer. On y retrouve notamment les éléments susceptibles d'améliorer la performance, les diagnostics techniques et les audits déjà réussis.

Que ne mesure pas PageSpeed Insights ?

PSI n'est ni un outil de supervision permanente ni un test de charge. Il ne montre pas comment un serveur réagit face à plusieurs milliers de connexions simultanées. Il ne remplace pas non plus un suivi interne des temps de réponse, des erreurs ou de la disponibilité.

L'outil ne connaît pas davantage les contraintes commerciales de la page. Il peut signaler qu'un script tiers consomme beaucoup de ressources sans savoir que ce script gère le paiement, la mesure d'audience ou le recueil du consentement. Une recommandation technique doit donc être confrontée au rôle réel de la ressource avant toute suppression.

• PSI analyse une URL, pas l'ensemble du parcours utilisateur.
• Le test de laboratoire reproduit un environnement défini, pas tous les appareils de vos visiteurs.
• Les économies annoncées sont des estimations, pas une promesse de gain identique en production.
• L'outil identifie des pistes, mais n'applique aucune correction.

Quelle différence entre PSI, Lighthouse, CrUX et Search Console ?

PageSpeed Insights sert d'interface de synthèse. Lighthouse est le moteur d'audit qui produit les données de laboratoire et la note de performance. Vous pouvez aussi lancer Lighthouse depuis Chrome DevTools pour examiner une version locale ou une page qui n'est pas encore accessible au public.

Le Chrome UX Report, souvent abrégé CrUX, rassemble des données d'utilisation réelles et anonymisées provenant d'utilisateurs Chrome éligibles. PSI exploite ces données sur une période glissante de 28 jours. C'est cette source qui renseigne sur l'expérience réellement vécue, sous réserve qu'un volume suffisant soit disponible.

La Google Search Console adopte une vue plus large. Son rapport Core Web Vitals regroupe des URL qui présentent des comportements proches. Il aide à repérer un problème touchant tout un modèle de page, tandis que PSI sert à examiner une URL et à rechercher les causes techniques possibles.

Comment utiliser PageSpeed Insights ?

Pour utiliser PageSpeed Insights, ouvrez pagespeed.web.dev, saisissez l'adresse complète de la page puis lancez l'analyse. Consultez séparément les résultats mobiles et ceux des ordinateurs. Commencez par les données réelles, lorsqu'elles existent, avant d'utiliser le rapport Lighthouse pour diagnostiquer les causes et préparer les corrections.

1. Choisissez une URL représentative, par exemple une fiche produit ou un article qui reçoit du trafic.
2. Saisissez son adresse complète avec le protocole HTTPS dans PageSpeed Insights.
3. Lancez l'analyse et attendez l'affichage du rapport.
4. Examinez l'onglet mobile, puis l'onglet ordinateur.
5. Vérifiez d'abord l'évaluation des Core Web Vitals et la provenance des données affichées.
6. Descendez jusqu'au rapport Lighthouse pour repérer la métrique la plus dégradée.
7. Ouvrez les audits associés afin d'identifier les images, scripts, feuilles de style ou traitements concernés.

Le test ne doit pas se limiter à la page d'accueil. Sur un site vitrine, je retiens généralement l'accueil, une page de service, un article et la page de contact. Sur une boutique, j'ajoute une catégorie, une fiche produit et les principales étapes du parcours d'achat accessibles sans transmettre de données personnelles.

Cette sélection révèle les problèmes liés aux modèles. Si toutes les fiches produits utilisent la même galerie d'images et le même script de variantes, corriger leur modèle aura plus d'effet que retoucher une URL isolée.

Pourquoi faut-il commencer par le résultat mobile ?

Le résultat mobile met souvent en évidence des contraintes moins visibles sur un ordinateur récent : processeur plus lent, écran différent et réseau moins stable. Il ne faut pas en déduire que tous les visiteurs rencontrent exactement ces conditions. Le test sert à rendre les ralentissements reproductibles et plus faciles à diagnostiquer.

Un écart entre mobile et ordinateur n'a rien d'exceptionnel. Une grande image, un menu chargé en JavaScript ou un outil de suivi peut peser bien plus lourd sur le test mobile. L'objectif consiste à comprendre cet écart, pas à obtenir deux notes identiques.

Faut-il lancer plusieurs tests ?

Oui. Une mesure de laboratoire peut varier en fonction de la réponse du serveur, des scripts tiers, du cache et des conditions d'exécution de Lighthouse. Trois tests successifs donnent un repère plus solide qu'une capture isolée. Pour comparer un avant et un après, utilisez la médiane des résultats plutôt que le meilleur score obtenu.

Testez dans des conditions comparables. Conservez la même URL, le même mode mobile ou ordinateur et un intervalle raisonnable entre les mesures. Notez également les modifications réalisées. Sans ce journal, il devient difficile de savoir si le gain vient de la compression des images, du cache ou d'une variation normale du test.

Comment lire les résultats de PageSpeed Insights ?

La lecture commence par une question simple : le rapport affiche-t-il des données réelles pour cette URL, pour l'ensemble de l'origine ou aucune donnée de terrain ? Cette indication change la portée du résultat. Elle évite surtout de comparer une expérience observée sur 28 jours avec un test Lighthouse exécuté à l'instant où vous consultez la page.

Données de terrain et données de laboratoire

Les données de terrain décrivent l'expérience de visiteurs réels. Elles agrègent différents appareils, réseaux, lieux et comportements. Leur période glissante de 28 jours explique qu'une correction mise en ligne ce matin ne fasse pas immédiatement basculer l'évaluation dans le vert.

Les données de laboratoire viennent d'une exécution simulée de Lighthouse. Elles répondent à un autre besoin : reproduire une situation, isoler un problème et comparer deux versions. Elles réagissent immédiatement à une modification, mais ne décrivent pas à elles seules l'ensemble de votre audience.

Les deux sources peuvent donc se contredire sans que le rapport soit défaillant. Une page peut obtenir un bon résultat de laboratoire tout en conservant des données réelles médiocres, notamment après une amélioration récente. L'inverse arrive lorsqu'un test ponctuel rencontre un serveur momentanément lent alors que l'expérience habituelle reste bonne.

Comment interpréter les Core Web Vitals ?

Les Core Web Vitals actifs sont le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift. Pour réussir l'évaluation, les trois métriques doivent se trouver dans la catégorie « bonne » au 75e percentile. Autrement dit, il ne suffit pas que l'expérience moyenne soit satisfaisante.

Le tableau montre que chaque métrique appelle un diagnostic différent. Compresser une image peut améliorer le LCP, mais ne résoudra pas nécessairement un mauvais INP provoqué par un long traitement JavaScript.

Depuis mars 2024, l'INP a remplacé le First Input Delay, ou FID. L'INP examine la réactivité pendant la visite avec une approche plus large que le seul délai précédant la première interaction. Si un guide présente encore le FID parmi les trois métriques actives, son explication doit être actualisée.

À quoi servent le FCP, le TTFB et le TBT ?

PageSpeed Insights affiche d'autres indicateurs utiles au diagnostic. Le First Contentful Paint, ou FCP, mesure le moment où le navigateur affiche le premier contenu. Le Time to First Byte, ou TTFB, renseigne sur le délai avant la réception du premier octet. Un TTFB élevé peut orienter le diagnostic vers le serveur, le cache ou la génération de la page.

Le Total Blocking Time, ou TBT, additionne les périodes durant lesquelles le thread principal reste bloqué assez longtemps pour gêner la réactivité. Il est utilisé en laboratoire, où une véritable mesure de l'INP n'est pas toujours possible faute d'interactions humaines représentatives. Un mauvais TBT conduit souvent à examiner le JavaScript.

Ces mesures ne sont pas des Core Web Vitals supplémentaires. Elles servent à expliquer pourquoi une métrique principale se dégrade. Cette distinction évite de traiter cinq ou six indicateurs comme s'ils avaient tous la même portée.

Quel est un bon score PageSpeed Insights ?

La note Lighthouse utilise trois plages de lecture. Un résultat de 90 à 100 est classé bon, un résultat de 50 à 89 doit être amélioré et une note de 0 à 49 est jugée faible. Cette échelle facilite le repérage, mais elle ne transforme pas le score en mesure directe de l'expérience réelle.

La couleur résume un résultat de laboratoire. Elle ne dit pas quelle ressource doit être corrigée et ne prouve pas que tous les visiteurs vivent la même expérience. Une note de 92 avec des données réelles dégradées mérite davantage d'attention qu'une note de 82 accompagnée de trois Core Web Vitals au vert.

Pourquoi le score change-t-il entre deux tests ?

Le score peut évoluer sans modification du code. La charge du serveur, la réponse d'un service externe, la mise en cache ou l'exécution d'un script tiers introduisent des variations. Lighthouse lui-même évolue : ses métriques, ses audits et leurs pondérations peuvent changer d'une version à l'autre.

Comparer deux tests suppose donc de conserver le détail des métriques. Une différence de trois points n'a souvent aucun intérêt pratique. Une hausse répétée du LCP de 2,2 à 3,4 secondes, en revanche, mérite une investigation même si la note globale reste dans la même couleur.

Faut-il viser 100 sur 100 ?

Non. Obtenir 100 peut être satisfaisant sur une page sobre, mais ce chiffre ne doit pas devenir l'objectif du projet. Certaines fonctions utiles ont un coût : recherche interne, personnalisation, paiement, mesure du consentement ou assistance en ligne. Le travail consiste à réduire ce coût sans dégrader le service rendu.

J'ai vu des équipes consacrer plusieurs journées à gagner les derniers points d'une page déjà fluide alors que des fiches produits importantes restaient dans le rouge. Le budget aurait été mieux employé sur le modèle qui recevait le trafic et générait les ventes.

Astuce de Chloé. Pour votre prochain audit, choisissez cinq URL représentatives et notez trois valeurs pour chacune : LCP, INP ou TBT selon les données disponibles, et CLS. Cette petite grille montre immédiatement si le problème touche une seule page ou tout un modèle.

Comment améliorer le score PageSpeed Insights ?

Commencez par la métrique la plus dégradée et recherchez les ressources que PSI lui associe. Traitez d'abord les images principales, la réponse serveur, le JavaScript bloquant et les décalages de mise en page. Appliquez une famille de corrections à la fois, puis relancez plusieurs tests et contrôlez le fonctionnement de la page.

Réduire le LCP

Un mauvais LCP vient souvent de l'élément principal visible au chargement. Sur une page éditoriale, il s'agit fréquemment de l'image de couverture. Sur une fiche produit, ce peut être la photographie principale, le titre ou un bloc rendu tardivement par JavaScript.

• Redimensionnez l'image aux dimensions réellement nécessaires.
• Compressez le fichier et utilisez un format moderne adapté, comme WebP ou AVIF.
• Évitez le chargement différé de l'image située immédiatement dans la zone visible.
• Donnez la priorité à la ressource LCP lorsqu'elle est identifiée avec certitude.
• Réduisez le temps de réponse du serveur grâce au cache et à une génération de page plus rapide.
• Limitez les feuilles de style et scripts qui retardent le premier affichage.

Le chargement différé est utile pour les images situées plus bas dans la page. L'appliquer sans distinction à l'image principale peut produire l'effet inverse et retarder le LCP. C'est l'une des corrections automatiques que je vérifie systématiquement après l'installation d'une extension de performance.

Améliorer l'INP et réduire le TBT

Un INP élevé signale une page qui réagit tardivement aux clics, aux pressions tactiles ou aux saisies. Le JavaScript constitue souvent la première piste. Un fichier volumineux n'est toutefois pas nécessairement le seul responsable : plusieurs petites tâches exécutées au mauvais moment peuvent également encombrer le thread principal.

• Supprimez le JavaScript réellement inutilisé après vérification fonctionnelle.
• Fractionnez les tâches longues afin de rendre la main au navigateur.
• Différez les scripts qui ne sont pas nécessaires au premier affichage.
• Réduisez le travail déclenché par chaque interaction.
• Contrôlez les gestionnaires d'événements et les rendus répétés.
• Mesurez séparément le coût des outils publicitaires, analytiques et conversationnels.

Chrome DevTools aide à retrouver les tâches longues dans l'enregistrement des performances. Cette analyse demande plus de temps qu'une lecture du score PSI, mais elle évite de supprimer plusieurs extensions au hasard.

Corriger le CLS

Le CLS augmente lorsqu'un élément visible change de position sans que l'utilisateur s'y attende. Le cas classique reste l'image dont la largeur et la hauteur ne sont pas réservées. Le navigateur affiche d'abord le texte, puis le décale lorsqu'il reçoit les dimensions de l'image.

Renseignez les dimensions des images et vidéos, réservez une zone stable aux publicités et évitez d'insérer une bannière au-dessus d'un contenu déjà affiché. Les polices web peuvent aussi provoquer un déplacement du texte. Leur préchargement, leur chargement raisonné et le choix d'une police de remplacement aux proportions proches réduisent ce mouvement.

Agir sur le serveur et le cache

Lorsque le TTFB est élevé, alléger une image ne traite pas la première cause. Examinez le cache de page, les requêtes vers la base de données, les appels à des services distants et les ressources disponibles sur l'hébergement. Sur un CMS, une extension lente ou une page générée sans cache peut retarder tout ce qui suit.

Un réseau de diffusion de contenu peut rapprocher les fichiers statiques des visiteurs. Son intérêt dépend toutefois de la localisation de l'audience, du poids des ressources et de l'architecture du site. Ajouter un CDN à une page ralentie par une requête de base de données ne corrigera pas cette requête.

Compresser et alléger les ressources

La compression Brotli ou Gzip réduit le volume transféré pour le HTML, le CSS, le JavaScript et d'autres fichiers textuels. La minification retire les caractères inutiles au fonctionnement du code. Ces actions sont courantes, mais leur effet dépend du poids initial des ressources.

Évitez aussi de charger une bibliothèque entière pour une fonction mineure. Le rapport de couverture de Chrome peut révéler qu'une grande partie du CSS ou du JavaScript téléchargé n'est pas utilisée sur la page. La suppression doit rester prudente, car une portion de code absente du premier écran peut servir après une interaction.

Comment prioriser les recommandations de PSI ?

La meilleure priorité n'est pas toujours l'économie de temps la plus élevée affichée dans le rapport. Croisez quatre critères : la métrique concernée, le nombre de pages touchées, le trafic de ces pages et le risque fonctionnel de la modification.

1. Identifiez la métrique rouge ou orange qui dégrade l'expérience.
2. Vérifiez si le problème apparaît sur plusieurs pages utilisant le même modèle.
3. Repérez les URL qui reçoivent du trafic ou participent à une conversion.
4. Commencez par une correction réversible et mesurable.
5. Testez l'affichage, les formulaires, le consentement et le paiement après modification.
6. Relancez plusieurs mesures Lighthouse dans les mêmes conditions.
7. Suivez ensuite l'évolution des données réelles, qui ne réagiront pas immédiatement.

Une optimisation réussie ne se juge pas au seul score. Elle doit accélérer la page sans casser une fonction, fausser la mesure d'audience ou déplacer le problème vers une autre métrique. Charger tous les scripts en différé peut améliorer l'affichage initial tout en retardant un bouton dont l'utilisateur a besoin dès son arrivée.

FAQ sur PageSpeed Insights

Pourquoi aucune donnée réelle n'est-elle disponible ?

CrUX n'affiche des données que lorsqu'un volume suffisant d'utilisateurs Chrome éligibles a visité la page ou son origine. Les URL récentes ou peu fréquentées peuvent donc ne présenter aucune donnée de terrain. Utilisez alors Lighthouse pour le diagnostic, puis complétez ce test par des mesures internes ou un suivi réel lorsque cela devient possible.

Faut-il tester une page ou tout le site ?

PageSpeed Insights teste une URL à la fois. Sélectionnez des pages représentatives de chaque modèle : accueil, catégorie, fiche produit, article et page de conversion. Si un défaut se répète sur un modèle, la correction peut améliorer de nombreuses URL. Une page légère choisie au hasard ne décrit pas la performance du site entier.

Un bon score PageSpeed garantit-il un meilleur classement ?

Non. La note Lighthouse affichée par PSI n'est pas utilisée directement comme score de classement. Google recommande une bonne expérience sur la page et tient compte de plusieurs signaux, dont les Core Web Vitals. La pertinence du contenu reste déterminante : une page rapide mais pauvre ne gagne pas automatiquement des positions.

Pourquoi les données de terrain restent-elles rouges après une correction ?

Les données CrUX reposent sur une période glissante de 28 jours. Une amélioration récente se mélange donc temporairement aux visites enregistrées avant sa mise en ligne. Lighthouse peut montrer un gain immédiat, tandis que l'indicateur de terrain évolue progressivement à mesure que les anciennes données sortent de la période observée.

PageSpeed Insights est-il gratuit ?

L'interface web de PageSpeed Insights est accessible gratuitement et sans création de compte. Google propose aussi une API pour automatiser des analyses. Cette API fonctionne avec des quotas et ne remplace pas un système de supervision continue. Pour un grand nombre d'URL, il faut organiser les tests et conserver l'historique des résultats.

PageSpeed Insights suffit-il pour auditer les performances ?

Non. PSI constitue un bon point de départ, puis Chrome DevTools aide à examiner le réseau et l'exécution du code. La Search Console montre les groupes d'URL concernés par des Core Web Vitals dégradés. Un outil de suivi des utilisateurs réels apporte enfin des données plus fines sur les appareils, les pages et les parcours.

Lors du prochain test, laissez la note globale de côté pendant quelques minutes. Relevez d'abord la source des données, la métrique la plus faible et l'élément précis qui la dégrade. C'est généralement là que commence le travail qui accélère réellement une page.