Un site lent perd des visiteurs : sur mobile, personne n'attend. En plus, Google utilise les Core Web Vitals parmi ses signaux d'expérience de page. Le moyen le plus simple de mesurer tout ça est gratuit : PageSpeed Insights, l'outil de Google. Voici comment l'utiliser et, surtout, comment lire le rapport sans s'y perdre, avec l'exemple réel de mon propre site.
Pas à pas
- Ouvrez pagespeed.web.dev.
- Collez l'adresse complète de la page (par exemple votre accueil ou une fiche produit) et cliquez sur Analyser.
- Patientez une trentaine de secondes. Le rapport a deux onglets : Mobile et Bureau. Regardez d'abord le mobile : c'est le test le plus exigeant, et celui de la majorité de vos visiteurs.
- Le bouton Copier le lien garde le rapport pour le partager ou le comparer plus tard.
Deux parties qui ne mesurent pas la même chose
- « Découvrez l'expérience de vos utilisateurs » : les données de terrain, mesurées dans le navigateur Chrome de vos visiteurs (le rapport CrUX). D'après Google, c'est le 75e centile des 28 derniers jours. Si votre page n'a pas assez de trafic, PageSpeed prend les données de tout le site, et si ça ne suffit pas non plus, il affiche « Aucune donnée » : c'est le cas de mon site et de la plupart des PME. Ce n'est pas une erreur.
- « Analysez les problèmes de performances » : les données de laboratoire. Lighthouse charge la page une fois sur un téléphone simulé (dans mon rapport, un Moto G Power en 4G lente). C'est de là que vient la note de 0 à 100.
Les métriques et leurs seuils
Voici les seuils officiels de Google pour les données de terrain (documentation de PageSpeed Insights) :
| Métrique | Ce qu'elle mesure | Bon | Mauvais |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Quand l'élément principal (photo, titre) s'affiche | jusqu'à 2,5 s | plus de 4 s |
| INP (Interaction to Next Paint) | La rapidité de réaction à un toucher ou un clic | jusqu'à 200 ms | plus de 500 ms |
| CLS (Cumulative Layout Shift) | À quel point le contenu bouge pendant le chargement | jusqu'à 0,1 | plus de 0,25 |
| FCP (First Contentful Paint) | Quand le premier contenu s'affiche | jusqu'à 1,8 s | plus de 3 s |
| TTFB (Time to First Byte) | Le temps de réponse du serveur | jusqu'à 0,8 s | plus de 1,8 s |
Les trois premières sont les Core Web Vitals : une page réussit l'évaluation seulement si les trois sont au vert.
Comment la note est calculée
La note de laboratoire est une moyenne pondérée de cinq métriques (documentation de Lighthouse) : Total Blocking Time 30 %, LCP 25 %, CLS 25 %, FCP 10 % et Speed Index 10 %. De 90 à 100 c'est vert, de 50 à 89 orange, sous 50 rouge. Le Total Blocking Time mesure combien de temps le JavaScript bloque la page : voilà pourquoi les scripts tiers (chat, publicité, statistiques) font autant baisser la note sur mobile.
Mon propre site en exemple
Le 2 novembre 2026, ma page d'accueil a obtenu 100 sur mobile : un LCP de 1,1 s, un Total Blocking Time de 30 ms et un CLS de 0,005. Et pourtant, le rapport propose des améliorations : environ 53 Kio à gagner sur les images, 74 Kio de JavaScript inutilisé et 2 Kio de CSS. Et l'accessibilité reste à 95 à cause d'un problème de contraste de couleurs.
Une leçon que j'ai apprise : en octobre, en mesurant avec Lighthouse sur mon propre ordinateur, la même page d'accueil obtenait entre 60 et 72. La note varie selon la machine, le réseau et ce qui tourne à côté. Il faut donc toujours comparer avec le même outil, et refaire le test deux ou trois fois avant de conclure.
Ce qui fait le plus souvent baisser la note
- Des images trop lourdes : des photos de plusieurs mégas, ni en WebP ni redimensionnées pour le mobile. C'est la cause numéro un que je vois chez les PME.
- Des vidéos en page d'accueil : une vidéo de fond peut peser plus lourd que tout le reste du site.
- Trop de scripts tiers : chat, pixels publicitaires, plusieurs outils de statistiques.
- Des polices bloquantes : des typographies chargées avant le texte ; il faut les charger sans bloquer.
- Du contenu qui saute : des images sans largeur ni hauteur déclarées, des bandeaux qui s'insèrent en haut (mauvais CLS).
- Un serveur lent : un hébergement bas de gamme et surchargé se voit dans le TTFB, avant même que quoi que ce soit ne s'affiche.
Mes conseils
- Testez aussi les pages qui comptent le plus : un produit, une page de réservation, le formulaire de contact, pas seulement l'accueil.
- Ne visez pas 100 à tout prix : passer de 85 à 100 change peu de chose ; passer de 30 à 80 change beaucoup.
- Si votre site a du trafic, regardez le rapport Core Web Vitals de la Search Console : il regroupe toutes vos pages avec des données réelles. Je l'explique dans Google Search Console pas à pas.
- La vitesse ne sert à rien si Google ne voit pas vos pages : vérifiez aussi pourquoi Google n'indexe pas un site.
Mes sites sont faits sur mesure en ASP.NET Core, justement pour qu'ils chargent vite (je compare avec WordPress dans cet article). Si vous voulez que je regarde le vôtre, voir mes sites web ou écrivez-moi.
Votre site est lent ?
Je vous dis ce qui le freine et combien coûte la correction, avec une proposition claire.
Demander mon devis gratuitÉcrivez-moi sur WhatsApp