La question m’arrive presque toujours dans les mêmes termes : « mon score PageSpeed est à 45 sur 100, est-ce que Google me pénalise ? ». Derrière, il y a souvent un prestataire qui a envoyé une capture d’écran rouge et un devis de refonte.
Je vais te donner la version que peu de gens te diront, parce qu’elle vend moins bien : ce score sur 100 n’est pas ce que Google utilise pour te classer, les Core Web Vitals pèsent beaucoup moins lourd qu’on ne te le raconte, et il y a de bonnes chances que Google n’ait même pas assez de données pour évaluer ton site. Ce qui ne veut pas dire qu’il faut ignorer la vitesse : le vrai gain est ailleurs, et il est bien réel.
Trois métriques, et rien d’autre
Les Core Web Vitals (« signaux web essentiels » en français) sont exactement trois mesures, chacune répondant à une question simple du point de vue du visiteur.
| Métrique | Ce qu’elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Quand le contenu principal s’affiche | ≤ 2,5 s | 2,5 s à 4 s | > 4 s |
| INP | La réactivité aux clics et aux taps | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS | La stabilité visuelle (le contenu qui saute) | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
Deux précisions qui changent la lecture du rapport. D’abord, la mesure se fait au 75e percentile de tes chargements de page sur 28 jours glissants : autrement dit, il faut que trois visiteurs sur quatre soient dans le vert, pas la moyenne. Ensuite, il faut que les trois métriques soient bonnes simultanément. Une seule en orange fait échouer l’ensemble.
Si tu as retenu « FID » d’un audit passé, c’est daté : cette métrique a été remplacée par l’INP le 12 mars 2024, puis retirée de Chrome en septembre 2024. J’en croise encore dans des rapports vendus en 2026.
Non, Google n’a pas durci les seuils
Un bruit circule depuis quelques mois : Google aurait abaissé le seuil du LCP de 2,5 à 2 secondes. J’ai vérifié à la source avant d’écrire cet article : c’est faux. La documentation officielle du LCP, mise à jour pour la dernière fois en septembre 2025, indique toujours 2,5 secondes. L’aide de la Search Console aussi. Et le journal des mises à jour de la documentation Google Search ne contient aucune modification 2026 liée aux signaux web essentiels.
Même chose pour la fameuse métrique de « fluidité des animations » qu’on annonce comme imminente : la page de travail des équipes Chrome sur le sujet n’a pas bougé depuis novembre 2021.
Je le signale parce que c’est un excellent test pour juger ton prestataire. Quelqu’un qui te vend une urgence sur la base d’un seuil qui n’existe pas ne vérifie pas ses sources, ou compte sur le fait que tu ne les vérifieras pas.
Ce que ça pèse vraiment dans le classement
Voilà le passage qui fâche. Google est plus explicite qu’on ne le croit sur le sujet, et sa documentation dit deux choses très claires : « il n’y a pas de signal unique », et surtout « Google Search cherche toujours à montrer le contenu le plus pertinent, même si l’expérience de page est médiocre ». Martin Splitt, chez Google, a formulé la même idée plus directement : les Core Web Vitals ne sont pas aussi importants que certains le pensent, sans être pour autant sans effet.
Traduction opérationnelle : c’est un signal de départage. Quand deux pages se valent en pertinence, la plus rapide peut passer devant. Une page rapide au contenu faible ne dépassera jamais une page lente qui répond mieux à la question posée.
Il y a un second point, encore plus concret pour une TPE des Pyrénées-Orientales. Ces mesures viennent de vrais visiteurs sous Chrome, collectées dans une base publique appelée CrUX. Pour qu’un site y figure, il lui faut un minimum de trafic. En dessous, la Search Console affiche « pas assez de données ». Si c’est ton cas, ce signal ne joue quasiment pas pour toi, et investir trois mille euros dans l’optimisation de ton INP en espérant remonter dans Google est un mauvais calcul. Mieux vaut commencer par un audit SEO technique qui te dira où sont réellement tes blocages.
Alors pourquoi s’en occuper ?
Parce que le gain n’est pas dans le classement, il est dans la conversion. Un visiteur qui attend trois secondes sur mobile pendant que ta page se construit, ou qui clique sur un bouton qui se déplace au dernier moment, ne se plaint pas : il repart.
Je dois être honnête sur les chiffres. Les études les plus citées sur le lien vitesse et conversion (une amélioration de 0,1 seconde qui fait gagner 8 % de conversions dans le retail) viennent d’un travail Deloitte commandé par Google, mesuré fin 2019, sur des métriques qui ne sont même plus celles d’aujourd’hui. Les études de cas de Google sur le sujet datent de 2020 et 2021. Quant aux chiffres qui tournent en boucle sur les blogs français (« 1 seconde de plus, 7 % de conversions en moins »), ils remontent à 2017 et je n’ai jamais réussi à remonter à l’étude d’origine.
Autrement dit : la direction est solide et documentée, les pourcentages précis qu’on te cite comme frais ne le sont pas. Si tu veux savoir ce que la vitesse te coûte sur ton site, la seule méthode honnête est de mesurer tes propres conversions, ce qui suppose un tracking des conversions correctement posé.
WordPress : dernier du classement, et c’est réparable
Aujourd’hui, environ 56 % des sites mesurés dans CrUX passent les trois seuils. Les plateformes ne sont pas à égalité : d’après le rapport technologique de HTTP Archive (relevé d’avril 2026), Duda tourne autour de 85 %, Wix 80 %, Shopify 79 %, et WordPress ferme la marche autour de 49 %.
Le point de blocage est identifié : c’est le LCP. Chez WordPress, une page mobile pèse 2,9 Mo en médiane, dont 1,6 Mo rien qu’en images, le pire score des CMS mesurés. Ce n’est pas WordPress le problème, c’est ce qu’on met dedans : un thème multi-usage qui charge douze polices, un slider en page d’accueil, et des photos uploadées telles quelles depuis un smartphone.
Maintenant le détail contre-intuitif, celui que je vois le plus souvent mal traité. Sur les sites au LCP dégradé, moins de 10 % du temps est passé à télécharger l’image. Le problème n’est presque jamais le poids du fichier : c’est tout le temps perdu avant de commencer à le télécharger. Sur les pages mobiles, 73 % ont une image comme élément principal, et dans plus d’un tiers des cas cette image n’est pas visible dans le code HTML initial, parce qu’elle est chargée par un script ou posée en fond CSS. Le navigateur ne peut pas la demander tant qu’il n’a pas exécuté le reste.
Conséquence pratique : compresser tes images ne réglera pas grand-chose si ton visuel principal est planqué dans un carrousel JavaScript. C’est typiquement ce que je regarde en premier sur un site WordPress.
Le seul tableau de bord qui compte
Il faut distinguer deux familles d’outils, et c’est là que se joue le malentendu du score à 45.
Les données de laboratoire (Lighthouse, la partie basse de PageSpeed Insights) simulent un chargement, sur un appareil théorique, avec un cache vide. C’est un outil de diagnostic, très utile pour comprendre d’où vient un problème. Ce n’est pas une note d’examen. Détail révélateur : Lighthouse ne mesure même pas l’INP, puisqu’il faudrait de vraies interactions humaines. Il affiche une métrique de substitution à la place.
Les données de terrain (le rapport « Signaux web essentiels » de la Search Console, la partie haute de PageSpeed Insights) viennent de tes visiteurs réels. C’est cela, et uniquement cela, que Google utilise.
Un site à 100/100 sur PageSpeed avec un rapport Search Console au rouge reste un site lent pour tes clients. Ouvre la Search Console, pas l’outil qui donne la note la plus flatteuse.
Par quoi commencer, concrètement
Trois corrections couvrent la majorité des situations que je rencontre, et aucune ne demande de refonte.
- Déclare les dimensions de tes images. Deux tiers des pages ont au moins une image sans largeur ni hauteur dans le code. C’est la première cause de contenu qui saute, et la correction prend trente secondes par image.
- Retire le chargement différé sur l’image principale. Beaucoup de thèmes et de plugins posent un
loading="lazy"sur tout, y compris la grande image en haut de la page d’accueil. Résultat : on retarde volontairement l’élément qui définit ton LCP. - Mets en place un cache de page et un CDN. Seul un tiers des pages sont servies par un CDN. Sur un mutualisé mal configuré, le serveur met déjà une seconde à répondre avant même que la page commence à s’afficher.
Au delà, on entre dans le travail de fond : alléger le thème, discipliner les scripts tiers (bandeau cookies, chat, widgets d’avis, pixels publicitaires empilés dans Tag Manager), et traiter la performance comme une composante de l’optimisation technique on-site. Et quand la dette est trop lourde, quand le thème lui-même est le problème, il faut savoir le dire : c’est le moment d’envisager une refonte du site plutôt que d’empiler des plugins d’optimisation sur des fondations fatiguées.
Ce que je te conseille
Regarde ta Search Console. Si elle affiche « pas assez de données », arrête de t’inquiéter des Core Web Vitals et occupe toi de ton contenu et de ta visibilité locale : c’est là qu’est ton retour sur investissement. Si elle affiche des URLs en rouge, commence par les trois corrections ci-dessus avant d’écouter qui que ce soit te parler de refonte.
Et méfie toi des urgences fabriquées. En 25 ans de métier à Perpignan, j’ai vu beaucoup de devis justifiés par un score rouge sur un outil que Google n’utilise pas pour classer.
Si tu veux savoir où en est vraiment ton site, et ce qui mérite ou non d’être corrigé, pose moi ta question : je te réponds franchement, même quand la réponse est qu’il n’y a rien à faire.