Core Web Vitals : ce que Google mesure vraiment (et ce que ça change pour vous)
Votre site charge en 2 secondes. PageSpeed Insights vous donne 88. De loin, ça paraît rassurant. En réalité, ce n'est qu'une partie de l'histoire. Google ne mesure pas seulement une vitesse brute. Il regarde aussi ce que les utilisateurs vivent vraiment : la stabilité visuelle, la réactivité, et le moment où le contenu principal devient enfin visible.
D'où vient ce changement ?
Pendant longtemps, Google mesurait la réactivité avec FID – First Input Delay. Un premier clic rapide, c'était suffisant. Mais FID avait un défaut grave : un site pouvait avoir un premier clic rapide, puis geler pendant 2 secondes au scroll suivant. FID ne captait rien de ce problème.
En mars 2024, Google a remplacé FID par INP. Au lieu de mesurer seulement le délai du premier clic, INP observe la réactivité tout au long de la visite. C'est une métrique plus représentative de l'expérience réelle.
Un point que beaucoup de gens confondent : Google n'utilise pas les données Lighthouse ou PageSpeed Insights pour le classement. Ce sont des données de laboratoire – utiles pour diagnostiquer, mais pas ce que Google regarde pour décider de votre position.
Pour le ranking, Google s'appuie sur le Chrome User Experience Report (CrUX) – des mesures collectées auprès de vrais utilisateurs Chrome sur 28 jours. Google évalue chaque métrique au 75e percentile : votre score doit être « bon » pour au moins 75 visiteurs sur 100. Ce n'est pas une moyenne, c'est un seuil qui protège vos utilisateurs les plus lents. Un bon score de test ne garantit pas que vos vrais visiteurs aient une bonne expérience.
L'écart entre lab data et données de terrain peut être énorme. J'ai vu des sites afficher 95 sur PageSpeed alors que la moitié des utilisateurs réels dépassaient le seuil LCP. La raison était beaucoup moins mystérieuse qu'on pourrait le croire : le vrai trafic passait encore en partie par de la 3G mobile. PageSpeed, lui, simulait du 4G.
Les trois Core Web Vitals expliqués
Largest Contentful Paint (LCP) – Objectif : ≤ 2,5 secondes
LCP mesure quand le contenu principal devient visible. Pas quand la page est complètement chargée – juste quand l'utilisateur voit quelque chose d'utile. Sur une page avec une image héros en haut, LCP chronomètre le moment où cette image s'affiche.
Pour une PME : pensez au temps qu'il faut avant de voir le logo et le titre de votre page d'accueil. Sur mobile, si c'est plus de 2,5 secondes, Google considère que c'est lent.
Les causes fréquentes d'un mauvais LCP : une image non optimisée (une photo de 4 Mo en JPEG fait des dégâts), des polices web qui bloquent le rendu, un temps de réponse serveur trop long, ou des ressources CSS/JS qui bloquent le rendu initial. Chaque cas a sa correction, mais il faut d'abord savoir lire un rapport Lighthouse pour trouver la bonne. Si votre page met trop de temps à montrer l'essentiel, l'utilisateur doute avant même de lire.
Interaction to Next Paint (INP) – Objectif : ≤ 200 millisecondes
INP mesure le délai entre votre action (clic, frappe, tap) et la prochaine mise à jour visuelle. C'est la réactivité de la page – pas juste au premier clic, mais pendant toute la session. 200 ms, c'est perçu comme instantané. Au-delà de 300 ms, on commence à sentir le délai.
Pour une PME : c'est la différence entre un bouton « Ajouter au panier » qui répond au quart de tour et un bouton qui semble figé pendant une demi-seconde.
Un mauvais INP vient presque toujours du JavaScript : du code lourd qui monopolise le thread principal, des scripts tiers (analytics, chatbots, widgets) qui s'exécutent au mauvais moment, ou des frameworks frontend qui re-rendent trop de composants à la fois. Des trois métriques, c'est souvent la plus coriace à corriger, parce qu'elle demande de comprendre comment le JavaScript interagit avec le navigateur. Et quand l'interface réagit mal, elle donne une impression de lenteur même quand la page est déjà affichée.
Cumulative Layout Shift (CLS) – Objectif : ≤ 0,1
CLS mesure l'instabilité visuelle : combien de fois le contenu se déplace sans action de l'utilisateur ? Vous lisez un article, une publicité charge en haut, tout le texte descend, vous cliquez sur le mauvais lien. C'est un CLS élevé.
Les causes sont souvent simples à identifier : images et vidéos sans dimensions explicites (le navigateur ne sait pas combien d'espace réserver), polices web qui chargent tard et modifient la hauteur du texte, contenu injecté dynamiquement (publicités, bannières cookies). C'est en général la métrique la plus facile à corriger. Attention quand même aux iframes et aux scripts tiers, qui peuvent le faire remonter sans que vous ne le voyiez. Si la page bouge sans prévenir, la confiance baisse immédiatement.
L'impact réel : classement et conversions
Oui, les Core Web Vitals peuvent influencer votre visibilité Google. Ce n'est pas le facteur principal – la pertinence du contenu reste décisive – mais c'est un signal utile, surtout entre deux pages de qualité comparable.
Ce qui est vraiment intéressant, c'est l'impact mesurable sur vos visiteurs. Vodafone a mené un test A/B rigoureux : en améliorant leur LCP de 31 %, ils ont constaté une hausse de 8 % des ventes. Pas un changement de design, pas un nouveau produit – juste un affichage plus rapide du contenu principal.
L'étude « Milliseconds Make Millions » commandée par Google à Deloitte va dans le même sens. En analysant 30 millions de sessions sur 37 sites, les chercheurs ont montré qu'une amélioration de 0,1 seconde du temps de chargement augmentait les taux de conversion de 8 à 10 % selon le secteur. Les millisecondes comptent.
Donc oui, optimisez pour Google. Mais surtout, faites-le pour les gens qui visitent votre site.
Mesurer en continu, pas juste une fois
Un audit Lighthouse ponctuel, c'est un point de départ — pas une stratégie. La performance fluctue selon les appareils, les connexions, le contenu de la page et même l'heure de la journée.
Le bon réflexe : commencez par la section « Signaux Web essentiels » de Google Search Console. Elle affiche l'état de vos pages sur la base des données CrUX — des vrais utilisateurs Chrome, pas une simulation. Vous voyez quelles URL sont en vert, en orange ou en rouge, avec le détail par métrique. Consultez-le au moins une fois par mois. Ensuite, utilisez PageSpeed Insights sur les pages en rouge pour identifier les causes techniques. Corrigez, déployez, et vérifiez dans Search Console 28 jours plus tard — c'est le cycle de collecte CrUX. C'est un processus itératif, pas un one-shot.
Si votre site a peu de trafic, vous n'aurez pas toujours assez de données de terrain dans CrUX. Dans ce cas, les données de laboratoire restent utiles, mais elles doivent être interprétées avec prudence.
Hébergement suisse et temps de réponse serveur
Le TTFB (Time to First Byte) – le temps que met le serveur à commencer à répondre – est le premier maillon de la chaîne LCP. Vous pouvez optimiser vos images et votre JavaScript autant que vous voulez : si votre serveur met 2 secondes à répondre, vous partez avec un handicap.
Pour un site destiné surtout à un public suisse, un hébergement situé en Suisse peut réduire la latence et améliorer le temps de réponse serveur. Cet effet ne suffit pas à lui seul, mais il aide, surtout sur le LCP. Des acteurs comme Infomaniak, basé à Genève, ou Hostpoint, à Rapperswil, ont aussi l'avantage d'un hébergement local cohérent avec des exigences de souveraineté ou de conformité.
Ce qu'il ne faut pas faire
Ne mesurez pas seulement avec Lighthouse. Les données de laboratoire sont précieuses pour identifier les problèmes, mais ce n'est pas ce que Google utilise pour le classement. Regardez vos données de terrain dans Search Console – c'est la réalité de vos visiteurs.
Ne confondez pas « score élevé sur PageSpeed » avec « site bien optimisé ». Un site peut afficher 95/100 en labo et toujours échouer aux Core Web Vitals en situation réelle, parce que votre trafic réel inclut des appareils et des connexions que la simulation ne reproduit pas.
Et ne visez pas la perfection. Google veut du « Good » – le vert. Pas du 100/100. Atteindre le seuil vert sur les trois métriques au p75 de vos visiteurs réels, c'est déjà un excellent résultat.
Conclusion
Les Core Web Vitals ne sont pas glamour. Il n'y a rien de très neuf là-dedans. C'est surtout de l'ingénierie web bien faite : optimiser les images, maîtriser le JavaScript, configurer le cache, choisir un bon hébergement.
Mais ça marche. Les sites qui passent au vert sur ces trois métriques offrent en général une meilleure expérience, et cela peut soutenir à la fois leur visibilité et leurs conversions. Les données de Vodafone et de Deloitte le confirment : même des améliorations modestes – quelques dixièmes de seconde – ont un impact mesurable sur votre chiffre d'affaires.
Si vous voulez savoir où en est votre site, commencez par Google Search Console, section « Signaux Web essentiels ». Et si vous voyez du rouge, parlons-en. C'est souvent plus simple à corriger qu'on ne le pense.