Vous avez collé l’adresse de votre site dans PageSpeed Insights et obtenu un score de 38 dans un cercle rouge, sur l’onglet « Mobile ». Sur l’onglet « Bureau », 85. Sous le cercle, une longue liste de conseils dans un jargon incompréhensible. Première pensée : le site est mauvais et Google le sanctionne pour ça.
En bref : le score PageSpeed Insights affiché dans le cercle n’est pas un verdict. C’est le résultat d’un seul test simulé, et il change d’une analyse à l’autre. On regarde d’abord le bloc du haut, celui des données de vrais visiteurs, puis deux ou trois indicateurs, et seulement ensuite la liste de conseils, où un débutant peut se contenter des 3 à 5 premiers points.
Voyons comment lire le rapport dans l’ordre et ce que vous pouvez laisser de côté. Si vous cherchez plutôt pourquoi un site rame en général, c’est l’objet de l’article Pourquoi un site devient lent et que vérifier en premier. Ici, on parle uniquement du rapport PageSpeed.
Pas le temps de vous en occuper ?
J’accélère votre site avec des mesures avant et après, et je vérifie que les formulaires et les demandes fonctionnent toujours. À partir de 200 € HT. Si vous préférez le faire vous-même, tout est expliqué étape par étape ci-dessous.
Le rapport compte deux blocs, et celui du haut pèse le plus
PageSpeed Insights (l’outil gratuit de Google, sur pagespeed.web.dev) affiche sur une même page deux choses très différentes.
Bloc du haut : les vrais visiteurs
Le premier bloc sous l’adresse, intitulé « Découvrez l’expérience de vos utilisateurs ». Ce sont les données des navigateurs Chrome de vos vrais visiteurs sur les 28 derniers jours. La ligne principale : « Évaluation Core Web Vitals », réussie ou en échec.
Bloc du bas : le test en laboratoire
Le second bloc, « Analysez les problèmes de performances ». C’est un seul chargement de la page, simulé par Google avec l’outil Lighthouse. C’est de là que viennent le cercle avec le score et la liste de conseils. Sous le cercle, c’est écrit noir sur blanc : « Les valeurs sont estimées et peuvent varier ».
Le bloc du haut répond à la question « comment le site se comporte chez les gens », celui du bas à « où chercher les causes ». Google prévient lui-même qu’un bon score en laboratoire ne garantit pas que les vrais visiteurs soient bien servis (documentation PageSpeed Insights). L’inverse arrive aussi : 55 dans le cercle, et l’évaluation des vrais visiteurs réussie.
Si le bloc du haut affiche « Aucune donnée » au lieu de chiffres, c’est normal pour un petit site. Google ne remplit ce bloc que s’il y a assez de visiteurs sous Chrome pour faire des statistiques. En haut du bloc, deux boutons « Cette URL » et « Origine » permettent de passer de la page au site entier : essayez « Origine ». S’il n’y a pas de données non plus, il vous reste le bloc du bas et le rapport Core Web Vitals de la Search Console (l’espace gratuit de Google pour le propriétaire du site).
Ce rapport repose lui aussi sur les données de vrais visiteurs, mais il est parfois vide pour les sites à faible trafic.
Pourquoi le score est plus bas sur mobile
L’onglet « Mobile » ne teste pas le site sur votre iPhone en Wi-Fi à la maison. Lighthouse simule un téléphone milieu de gamme sur un réseau mobile lent : en bas du rapport, c’est indiqué en toutes lettres, « Émulation du Moto G Power » et « Connexion 4G lente ». L’onglet « Bureau » simule un ordinateur avec une connexion filaire. Le score mobile est donc presque toujours plus bas, et le comparer au score ordinateur n’a pas de sens.
C’est pourtant l’onglet « Mobile » qu’il faut regarder : les clients d’une petite entreprise cherchent souvent l’adresse, le menu ou le numéro de téléphone depuis un smartphone, et pas toujours avec un bon réseau.
Core Web Vitals : les trois indicateurs en clair
Dans le bloc du haut, les trois lignes principales s’appellent les Core Web Vitals, ou Signaux Web essentiels. Voici ce qu’elles mesurent :
LCP : quand l’essentiel apparaît
Au bout de combien de secondes le plus grand élément du premier écran s’affiche : grande photo, bannière ou titre. Pour le visiteur, c’est le moment où « la page s’est ouverte ».
INP : la vitesse de réaction
Le temps entre un appui sur un bouton ou un menu et la réaction de la page. Un mauvais INP se ressent comme « j’ai appuyé et rien ne se passe ».
CLS : quand la page bouge toute seule
Les blocs bougent-ils pendant le chargement ? Situation connue : vous visez un bouton, une image finit de se charger au-dessus, et vous appuyez à côté. C’est un nombre sans unité.
Les seuils de Google (web.dev) :
| Indicateur | Bon | Mauvais |
|---|---|---|
| LCP | jusqu’à 2,5 s | plus de 4 s |
| INP | jusqu’à 200 ms | plus de 500 ms |
| CLS | jusqu’à 0,1 | plus de 0,25 |
Entre les deux, la zone orange « à améliorer » : LCP de 2,5 à 4 s, INP de 200 à 500 ms, CLS de 0,1 à 0,25.
L’évaluation est réussie si les trois indicateurs sont bons pour au moins trois visites sur quatre (Google regarde le 75e centile sur les 28 derniers jours, séparément pour les téléphones et les ordinateurs). Si les données INP sont insuffisantes, un bon LCP et un bon CLS suffisent (documentation PageSpeed Insights).
Le bloc du bas n’a pas d’INP : le test ne clique sur rien. À la place, il y a le Total Blocking Time (TBT), le temps pendant lequel la page est occupée par ses scripts et ne peut pas répondre. Le score du cercle combine cinq indicateurs de laboratoire : ceux qui pèsent le plus sont le TBT (30 %), le LCP et le CLS (25 % chacun), le reste revient au FCP et au Speed Index (Lighthouse). C’est pourquoi les scripts lourds et les photos en haut de page font le plus baisser le chiffre.
Pourquoi le score varie et pourquoi 100 n’est pas l’objectif
Lancez le test trois fois de suite, et vous obtiendrez presque à coup sûr trois scores différents. Google l’explique par la charge du réseau et des serveurs qui exécutent le test, et la documentation de Lighthouse ajoute les publicités et les tests A/B qui changent d’un chargement à l’autre, les extensions du navigateur et l’antivirus (Lighthouse). Un écart de 5 à 10 points sans modification du site ne veut généralement rien dire. Comparez la même page dans le même onglet et prenez la moyenne de trois analyses.
Quant au 100, Google est clair : un score parfait de 100 est très difficile à obtenir et n’est pas attendu, la cible est 90 et plus. Dans sa documentation Search, Google indique que les signaux web essentiels sont pris en compte dans le classement, mais que de bonnes valeurs ne garantissent pas de bonnes positions, et que viser un résultat parfait uniquement pour le SEO n’est peut-être pas le meilleur usage de votre temps (Google Search Central).
Courir après le score peut même nuire. Par exemple, différer le chargement de tous les scripts fait monter le chiffre, mais peut casser le formulaire de contact ou sa protection anti-spam. Un site à 70 avec un formulaire qui fonctionne est plus utile qu’un site à 98 qui ne reçoit plus de demandes.
Améliorer son score PageSpeed Insights : ce qui rapporte le plus
La liste de conseils du bloc du bas est longue, mais la plupart des points indiquent des « Économies estimées », en secondes ou en kilo-octets. À côté de la mention « Afficher les audits pertinents pour », vous pouvez choisir LCP, TBT ou CLS : il ne reste alors que les conseils qui agissent sur cet indicateur. Sur le site d’une petite entreprise, les gros points cachent généralement l’une de ces six causes.
Images trop lourdes
Le point « Améliorer l’affichage des images ». Une photo prise au téléphone, de 3 à 5 Mo, en haut de page est presque toujours l’élément LCP. La réduire et la convertir en WebP, vous pouvez le faire vous-même : comment réduire ses photos. Les images sans width ni height explicites apparaissent dans le point « Causes des décalages de mise en page » et agissent sur le CLS.
Pas de cache
Le point « Utiliser des durées de mise en cache efficaces » vise à éviter que le navigateur retélécharge les mêmes fichiers à chaque visite. Par ailleurs, un WordPress sans cache de pages reconstruit chaque page à chaque visite. Les deux se règlent avec une seule extension de cache ou chez l’hébergeur. Installez une seule extension, pas deux.
Scripts en trop
Le point « Tiers » (le code fourni par des services extérieurs) montre ce que pèsent le chat, les pixels publicitaires, la carte intégrée, le widget de réseau social. Ajoutez-y les extensions qu’on n’utilise plus depuis longtemps. Chacun est utile seul, ensemble ils pénalisent le LCP comme l’INP.
Polices
Trois ou quatre familles de polices en cinq graisses, chargées depuis un serveur externe. Deux familles et trois graisses suffisent en général. Le point « Affichage de la police » signale que le texte attend le chargement de la police.
Slider (carrousel) en haut de page
Cinq grandes photos, une animation et une bibliothèque de scripts dédiée sur le premier écran. Le slider est souvent à la fois l’élément LCP et la cause des décalages. Une seule bonne photo à la place du slider rapporte généralement plus qu’une dizaine de petites retouches.
Serveur lent
La ligne Time to First Byte (TTFB) du bloc du haut : le temps de réflexion du serveur avant d’envoyer la page. Au-delà de 0,8 seconde, les images n’y sont pour rien : c’est l’hébergement ou le site lui-même qui répond lentement.
Ce que vous pouvez laisser de côté
- Toute la section « Diagnostic », si vous n’êtes pas développeur. Google précise lui-même, juste en dessous, que ces chiffres n’ont pas d’incidence directe sur le score lié aux performances.
- « Réduisez les ressources CSS inutilisées » et « Réduisez les ressources JavaScript inutilisées » sur un site créé avec un constructeur de pages. Ce code vient presque toujours du thème ou du constructeur de pages. Impossible de le retirer à la main sans casser la mise en page. Si ce point fait apparaître les adresses du chat ou des widgets, reportez-vous à la carte « Scripts en trop » plus haut : ce qui aide, c’est de renoncer au superflu, pas de nettoyer le code à la main.
- Les points qui font gagner quelques kilo-octets ou quelques dizaines de millisecondes. Par exemple « Réduisez la taille des ressources CSS ». Vous ne verrez pas la différence.
- Les autres cercles : « Accessibilité », « Bonnes pratiques », « SEO ». Ce sont des sujets à part, ils n’influencent pas le score de performances.
Comment vérifier votre site, étape par étape
- Ouvrez pagespeed.web.dev, collez l’adresse de la page d’accueil et cliquez sur « Analyser ». Faites ensuite de même pour votre page de service la plus importante.
- Choisissez l’onglet « Mobile » et commencez par le bloc du haut. Si l’évaluation Core Web Vitals est réussie, le score du bas est secondaire : ne cherchez que les problèmes flagrants.
- Si le bloc du haut n’a pas de données, cliquez sur « Origine » pour voir le site entier, et si le site est relié à la Search Console, consultez-y le rapport Core Web Vitals.
- Lancez le test trois fois et notez le score, le LCP et le CLS. Travaillez sur la moyenne.
- Choisissez LCP, TBT ou CLS à côté de « Afficher les audits pertinents pour » et prenez un ou deux points avec les plus grosses « Économies estimées ».
- Avant toute modification, faites une sauvegarde (dans le panneau de l’hébergeur ou avec une extension de sauvegarde). Changez une chose à la fois et relancez le test après chaque changement.
- Après chaque modification, vérifiez sur téléphone le menu, le formulaire de contact et le bouton d’appel. Comment faire sans outils : vérifier son site sur téléphone.
Quand on ne s’en sort plus seul
Si après les images et le cache le LCP dépasse encore 4 secondes, la cause est généralement plus profonde : réponse lente du serveur (regardez le TTFB), thème lourd ou constructeur de pages.
Un mauvais INP chez les vrais visiteurs ne se corrige pas non plus avec une extension : c’est un travail sur les scripts. Même chose s’il s’agit d’une boutique avec des commandes en cours, ou si une « extension d’accélération » a déjà cassé le formulaire une fois. Dans ces cas, une soirée de réglages ajoute plus souvent des problèmes que des points.
Si votre temps vaut plus cher
Tout ce qui précède, vous pouvez le faire vous-même : lire le bloc du haut, réduire les photos, installer une extension de cache et retirer les widgets inutiles. Pour un petit site, c’est souvent suffisant pour sortir de la zone rouge.
Si vous ne voulez pas vous plonger dans les rapports, Zen Webmaster prend en charge la partie technique : optimisation de la vitesse du site, avec mesures avant et après et vérification que les formulaires et les demandes fonctionnent. À partir de 200 € HT, tous les prix sur la page tarifs.
Vous préférez ne pas vous en occuper ?
Décrivez votre besoin en quelques mots. Je vous réponds sous un jour ouvré : ce qu'il faut faire, le prix et le délai.
Derniers articles
