« Votre site n’est pas assez rapide, il faut passer au vert sur PageSpeed. » C’est un argument que beaucoup d’entreprises entendent, souvent accompagné d’un devis d’optimisation.
Les Core Web Vitals sont une bonne chose : ils ont donné un vocabulaire commun pour parler de performance web. Mais ils sont aussi devenus un argument commercial, avec son lot de raccourcis, dont le plus tenace : « il faut être à 100 sur PageSpeed ».
Voici ce que ces indicateurs mesurent réellement, ce qu’ils changent pour un site vitrine, et où l’effort d’optimisation cesse d’être rentable.
Les trois indicateurs, en français
LCP : le temps d’affichage du contenu principal
Le Largest Contentful Paint mesure le temps au bout duquel le plus gros élément visible de la page est affiché : en général l’image ou le titre principal de votre bandeau.
Concrètement, c’est la réponse à « au bout de combien de temps le visiteur voit quelque chose d’utile ? ». L’objectif est de rester sous 2,5 secondes.
C’est l’indicateur le plus important des trois, et généralement le plus facile à améliorer.
INP : la réactivité aux clics
L’Interaction to Next Paint mesure le délai entre l’action du visiteur (un clic, une ouverture de menu) et le moment où la page réagit visuellement.
C’est ce qui donne l’impression d’un site « qui rame » : on clique sur le menu burger, et il s’ouvre un quart de seconde plus tard. L’objectif est de rester sous 200 millisecondes.
Sur un site vitrine classique, cet indicateur pose rarement problème. Il se dégrade surtout quand la page charge beaucoup de JavaScript, souvent des extensions, des sliders et des scripts de suivi.
CLS : la stabilité visuelle
Le Cumulative Layout Shift mesure les décalages de contenu pendant le chargement : le texte que vous commencez à lire et qui saute parce qu’une image ou une bannière vient de s’insérer au-dessus.
C’est l’indicateur le plus irritant pour le visiteur, et paradoxalement le moins coûteux à corriger. L’objectif est de rester sous 0,1. La cause est presque toujours la même : des images sans dimensions déclarées, ou des éléments injectés après le chargement.
Ce que Google en fait réellement
C’est ici que les raccourcis commencent.
Les Core Web Vitals sont bien un critère de classement. Mais un critère parmi beaucoup d’autres, et loin d’être le plus déterminant. La pertinence du contenu, l’intention de recherche et l’autorité du site pèsent nettement plus lourd.
En pratique, la performance agit surtout comme un critère de départage. À contenu équivalent, le site plus rapide est avantagé. Elle ne compense pas un contenu faible : un site parfaitement optimisé sur un sujet mal traité ne remontera pas.
Deux précisions qui changent la lecture des rapports :
Ce qui compte, ce sont les données réelles, pas le score du test. Google s’appuie sur les mesures collectées auprès des vrais visiteurs (les données CrUX, sur les 28 derniers jours), pas sur le score que PageSpeed Insights calcule en simulation. Un site peut afficher 85 en test tout en étant classé « bon » sur les données réelles, et l’inverse arrive aussi.
L’évaluation se fait au 75e centile. Autrement dit, il faut que 75 % des visites soient bonnes pour que la page passe. C’est une précision qui a des conséquences concrètes : un site qui vous paraît rapide depuis votre bureau peut échouer parce qu’un quart de vos visiteurs, sur mobile ou sur une connexion moyenne, vit une expérience très différente de la vôtre.
Le seuil est un passage, pas un gradient. Une page est évaluée « bonne », « à améliorer » ou « médiocre ». Passer de médiocre à bon compte. Gagner 4 points une fois qu’on est déjà dans le vert n’apporte rien.
Où sont les vrais gains
Sur les sites vitrines que je reprends, les causes de lenteur sont presque toujours les mêmes, et rarement exotiques. Je les donne dans l’ordre où je les traite, parce que cet ordre compte : optimiser une image sur un serveur lent, c’est peindre une façade qui prend l’eau.
Les images non optimisées. C’est le premier poste, de loin. Une photo de 4 Mo affichée dans un bloc de 600 pixels de large, servie en JPEG plutôt qu’en WebP, sans chargement différé pour ce qui est hors écran. Corriger ça règle souvent le LCP à lui seul.
Les extensions accumulées. Sur WordPress, chaque extension ajoute potentiellement son CSS et son JavaScript sur toutes les pages, y compris celles qui n’en ont pas l’usage. Un formulaire de contact qui charge sa librairie sur la page d’accueil, un slider actif sur tout le site alors qu’il ne sert qu’en page d’accueil.
Les scripts tiers. Outils de suivi, widgets de réseaux sociaux, chat en ligne, bandeau de consentement. Chacun paraît anodin ; l’accumulation ne l’est pas. Ce sont les principaux responsables d’un mauvais INP.
Les polices web. Plusieurs familles chargées avec toutes leurs variantes, souvent depuis un domaine externe, alors que deux graisses suffisent.
Ces quatre points couvrent la grande majorité des situations, et aucun ne relève de l’optimisation avancée. Mais ils partagent tous une dépendance : le serveur qui les sert.
Le socle qu’on oublie : l’hébergement
C’est la couche la moins visible, et celle qui plafonne toutes les autres.
Avant même que le navigateur puisse afficher quoi que ce soit, il envoie une requête et attend la réponse du serveur. Ce délai porte un nom, le TTFB (Time To First Byte), et il s’ajoute à tout le reste. Un serveur qui répond en 800 millisecondes vous a déjà mangé un tiers de votre budget LCP avant que la moindre image ne commence à se charger.
Autrement dit : vous pouvez convertir toutes vos images en WebP et supprimer la moitié de vos extensions, si le serveur est lent, vous ne passerez pas sous les 2,5 secondes. C’est un plafond, pas un facteur parmi d’autres.
Ce qui rend un hébergement lent
- Un mutualisé surchargé. Vos ressources sont partagées avec d’autres sites sur la même machine. Un voisin qui consomme, et votre temps de réponse s’en ressent, sans que vous puissiez rien y faire.
- Une version de PHP ancienne. L’écart de performance entre PHP 7.4 et une version récente est considérable sur WordPress. C’est souvent le gain le plus rapide à obtenir.
- Pas de cache serveur. Sans OPcache côté PHP, ni cache de pages, chaque visite refait tout le travail de génération.
- Une base de données non entretenue. Tables qui gonflent, requêtes lentes, révisions d’articles jamais purgées.
- La distance géographique. Un serveur situé loin de vos visiteurs ajoute de la latence réseau incompressible. Pour une clientèle française, un hébergement en France a du sens.
Comment savoir si c’est votre problème
Regardez le TTFB dans PageSpeed Insights, ou plus simplement l’onglet Réseau de votre navigateur : la première ligne de la requête principale.
Le repère : sous 200 ms, c’est bon. Au-delà de 600 ms, le serveur est votre facteur limitant, et c’est là qu’il faut agir avant de toucher aux images.
Un test complémentaire, très parlant : chargez une page quasi vide de votre site, une mention légale par exemple. Si elle est lente aussi, le problème n’est ni vos images ni vos extensions. Il est en dessous.
Ce que ça implique
Sur ce point, changer d’hébergement donne souvent plus de résultat que des semaines d’optimisation front. C’est aussi le levier le moins souvent proposé, parce qu’il ne se facture pas en heures d’optimisation.
Je détaille les critères de choix dans mon article sur le mutualisé, VPS ou serveur dédié, et le choix de l’hébergeur lui-même dans celui sur OVHcloud, Infomaniak ou o2switch. À noter qu’un serveur bien dimensionné mais mal entretenu se dégrade dans le temps, ce que j’aborde côté infogérance serveur.
Où l’effort cesse d’être rentable
C’est la partie dont on parle moins, parce qu’elle ne se vend pas.
Une fois les gros postes traités, chaque point supplémentaire coûte de plus en plus cher. Passer de 45 à 85, c’est de l’hygiène technique. Passer de 90 à 98, c’est du travail d’orfèvre : découpage fin du CSS, préchargement sélectif, réécriture de composants, avec un risque réel de fragiliser le site pour un bénéfice que ni le visiteur ni Google ne percevront.
Trois situations où l’optimisation n’est pas la bonne dépense :
- Le site est déjà dans le vert. Le budget est mieux placé sur le contenu ou l’acquisition.
- Le problème n’est pas la vitesse. Un site rapide qui ne convertit pas a un problème de proposition, de clarté ou de parcours, pas de millisecondes.
- Le site est structurellement à bout. Empiler des optimisations sur un thème lourd bourré d’extensions, c’est traiter le symptôme. À ce stade, la question devient celle d’une refonte ou d’une mise à jour.
Le vrai argument, qui n’est pas le SEO
On vend la performance avec le référencement. C’est l’angle le plus visible, et le moins convaincant.
L’argument solide est ailleurs : la performance est une question d’expérience et de contexte réel d’usage. Vos visiteurs ne sont pas tous sur une fibre avec un ordinateur récent. Une partie significative arrive sur mobile, parfois sur une connexion 4G ou 5G irrégulière, parfois sur un téléphone de quatre ans.
Sur un site vitrine, une page qui met cinq secondes à s’afficher perd des gens avant même d’avoir dit ce qu’elle proposait. Ce n’est pas une pénalité de Google : ce sont des visiteurs qui repartent.
C’est aussi pour ça que le test compte moins que la réalité. Un score de laboratoire mesure une page dans des conditions choisies. Ce qui vous intéresse, c’est ce que vivent vos visiteurs, et c’est exactement ce que mesurent les données réelles.
Comment savoir où vous en êtes
Trois vérifications suffisent pour se faire une idée honnête, sans outil payant.
- PageSpeed Insights sur vos trois pages principales (accueil, page de service, contact). Regardez la section des données réelles en haut si elle est disponible, avant le score de laboratoire.
- La Search Console, rubrique Signaux web essentiels, qui montre l’évolution sur l’ensemble du site et identifie les groupes de pages en difficulté.
- Votre propre téléphone, en données mobiles (pas en Wi-Fi), sur le site. C’est le test le plus parlant, et le seul qui reflète ce que vit un visiteur.
Si les trois convergent, vous avez votre réponse sans avoir besoin d’un audit.
En résumé
Les Core Web Vitals sont un outil utile, à condition de les lire pour ce qu’ils sont : une mesure de l’expérience réelle, pas un score à maximiser.
Ce qu’il faut retenir :
- Le vert compte, le 100 non. Franchir le seuil a de la valeur ; les points au-delà n’en ont plus.
- Les gros gains sont simples. Images, extensions, scripts tiers, polices, hébergement, dans cet ordre.
- La performance ne sauve pas un contenu faible, et ne compense pas un site mal conçu.
- Le meilleur argument n’est pas Google, c’est le visiteur qui reste au lieu de repartir.
Si votre site est lent et que vous ne savez pas par où commencer, le point de départ est un diagnostic honnête : identifier les deux ou trois causes réelles plutôt que de tout optimiser. Je peux m’en charger dans le cadre de mes prestations ponctuelles, ou en suivi continu avec le monitoring des performances inclus en infogérance Astro.