Pourquoi un bon score PageSpeed ne prouve pas que votre site est rapide

« Le premier principe, c'est de ne pas se tromper soi-même, et c'est vous la personne la plus facile à tromper. »
— Richard Feynman, 1974

La capture d'écran arrive souvent en fin de projet : un grand cercle vert, 98 sur 100, envoyé comme preuve que le site est rapide. Tout le monde est content, le prestataire le premier, et la question de la performance est rangée parmi les sujets réglés. J'avoue, moi aussi j'ai déjà fait la capture d'écran du cercle vert.

Pendant ce temps, un client potentiel ouvre votre page depuis son téléphone, dans un train entre Sion et Brig. Il voit un écran blanc, puis un bandeau qui se décale au moment précis où il allait toucher un bouton. S'il est arrivé par une annonce Google, vous avez payé ce clic, qu'il reste ou non.

Le score de laboratoire n'est pas un mensonge, mais il ne mesure pas ce que Google retient pour évaluer votre site. Google regarde la vitesse vécue par vos vrais visiteurs, et c'est elle qu'il faut soigner, même quand le cercle est déjà vert.

Pourquoi un score de laboratoire ne dit rien de vos vrais visiteurs

PageSpeed Insights affiche deux choses différentes, et on n'en regarde souvent qu'une. En haut, quand elles existent, les données de terrain : ce que des utilisateurs réels de Chrome ont vécu sur votre page au cours des 28 derniers jours. En dessous, le score Lighthouse : une simulation sur un appareil et une connexion fictifs.

Le laboratoire simule un seul visiteur

Le test de laboratoire charge votre page une fois, dans des conditions fixes, sans bandeau de cookies accepté, sans extension, sans historique. C'est très utile pour déboguer, parce que le résultat est reproductible d'un essai à l'autre. Mais il ne sait rien de vos visiteurs réels, de leurs téléphones ni de leur réseau.

Les Core Web Vitals se mesurent sur le terrain

Les Core Web Vitals sont trois mesures de l'expérience vécue, et chacune répond à une question simple : ça s'affiche, ça répond, ça reste en place ? Pour être jugée bonne, une page doit tenir les trois seuils sur au moins 75 % des visites réelles :

• LCP : le temps d'affichage du plus grand élément visible, 2,5 secondes au plus ;
• INP : la réactivité aux interactions, 200 millisecondes au plus ;
• CLS : la stabilité de la mise en page pendant le chargement, 0,1 au plus.

Un 98 de laboratoire avec des données de terrain dans le rouge reste un site lent pour ceux qui comptent.

1. Lisez vos données de terrain avant de toucher au code

Commencez par le rapport Core Web Vitals de la Search Console. Il regroupe vos pages par problème, sépare mobile et ordinateur, et vous dit laquelle des trois mesures pose problème. C'est la seule base sérieuse pour décider où investir, parce qu'elle reflète ce que Google voit réellement.

Quand votre site n'a pas assez de visites

Une limite honnête s'impose ici : un site à faible trafic n'a souvent pas assez de visites Chrome pour que Google publie des données de terrain. Le rapport reste vide, et c'est normal. Dans ce cas, le laboratoire redevient votre meilleur indicateur, à condition de le lire comme une estimation et de tester sur un vrai téléphone.

C'est aussi pour ça que la performance fait partie d'une stratégie SEO et non d'une case à cocher en fin de projet : elle se suit dans le temps, page par page, comme vos positions, et elle se dégrade discrètement à chaque ajout si personne ne la surveille.

2. Allégez l'image principale, celle qui s'affiche en premier

Sur la plupart des sites vitrines, l'élément qui détermine le LCP est une image : la photo d'en-tête, le visuel d'accueil, parfois une vidéo en arrière-plan. C'est elle qu'il faut traiter en premier, parce qu'elle concentre souvent l'essentiel du poids que le visiteur attend de voir.

Allégez, dimensionnez et priorisez l'image

Trois gestes règlent la majorité des cas :

• servir l'image dans un format moderne comme AVIF ou WebP, à la taille réellement affichée ;
• la charger en priorité plutôt que de la laisser attendre son tour derrière le reste ;
• déclarer sa largeur et sa hauteur dans le code, pour que le navigateur lui réserve sa place avant même qu'elle arrive.

Ce dernier point règle aussi le CLS, ces décalages qui font toucher le mauvais bouton. Sur mon propre site, les 739 images déclarent leurs dimensions, et aucune ne provoque de décalage de mise en page. Ce n'est pas un exploit, c'est une règle appliquée dès la construction plutôt que corrigée après coup.

Méfiez-vous aussi des carrousels en tête de page et des vidéos d'arrière-plan lancées automatiquement. Ils deviennent souvent l'élément LCP sans que personne l'ait décidé, et obligent le téléphone à télécharger plusieurs visuels avant d'afficher le premier. Une seule image forte, bien servie, fait presque toujours mieux, en impact comme en vitesse.

3. Retirez les scripts que personne n'a vraiment choisis

Le deuxième poids d'un site est invisible : ce sont les scripts. Un widget de chat, trois outils de suivi, un bandeau de cookies, un carrousel, une extension installée pour un besoin ponctuel et jamais retirée. Chacun semblait léger, et ensemble ils occupent le téléphone de votre visiteur au moment où il essaie d'interagir.

Faites l'inventaire avant d'optimiser

Listez chaque script chargé par votre site et demandez-vous qui l'a ajouté, pourquoi et s'il sert encore. Beaucoup arrivent avec un thème acheté pour gagner du temps , et cet inventaire suffit souvent à gagner davantage que n'importe quelle optimisation fine : le code le plus rapide reste celui qu'on ne charge pas.

Pour les scripts qui restent, la question devient celle du moment. Un widget de chat ou une carte interactive n'ont aucune raison de se charger avant votre titre : reportez-les après l'affichage principal, ou au premier geste du visiteur. Le contenu arrive d'abord, les outils ensuite, et le téléphone répond quand on le touche.

Et aucun site n'est parfait. Le dernier audit du mien relevait encore des données structurées qui pèsent environ 16 % du HTML, et une connexion anticipée manquante vers l'outil de statistiques. Ce sont des kilos en trop, modestes mais réels, et je les traite comme n'importe quel autre chantier.

La vitesse se décide dans l'architecture, pas après la mise en ligne

Optimiser la vitesse après coup, c'est chercher des grammes sur une structure conçue sans balance. On compresse une image, on retarde un script, on gagne quelques points, et le prochain ajout efface le gain. Les sites durablement rapides le sont parce que chaque choix a été pesé au moment de la construction.

Fixez un budget de performance dès la maquette

Je travaille avec cette contrainte dès le départ : quelles images, dans quel format, quels scripts et pour quel usage, quelle police et combien de variantes. Ces décisions appartiennent au développement web , pas à une phase d'optimisation qu'on espère avoir le temps de faire à la fin.

Reste une vérité à garder en tête : la vitesse départage, elle ne remplace pas. Une page rapide qui ne répond pas à la question du visiteur ne montera pas, et une page lente mais incontournable gardera sa place un moment. La performance est une condition d'entrée, pas une stratégie à elle seule.

Prêt à mesurer la vitesse que vivent vraiment vos visiteurs ?

Un cercle vert fait plaisir, mais ce sont vos visiteurs qui décident si votre site est rapide. Regardez ce qu'ils vivent, traitez l'image principale, faites le tri dans les scripts, et le score suivra de lui-même. L'inverse, lui, n'a jamais rendu un site plus rapide pour personne.

👉 Vous voulez savoir ce que vos visiteurs vivent vraiment en ouvrant votre site ? Contactez-moi