Core Web Vitals expliqués : comment la vitesse du site booste le SEO et les ventes
Google mesure désormais l'expérience réelle de vos visiteurs et récompense les pages rapides, stables et réactives. Si vos Core Web Vitals sont mauvais, vous perdez à la fois en classement et en chiffre d'affaires.
Qu'est-ce que le LCP, et quel est un bon score ?
Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour que le plus gros élément visible, généralement l'image principale ou le titre, s'affiche. Le seuil de Google pour une bonne expérience est de 2,5 secondes ou moins, évalué au 75e centile des visites réelles : la plupart de vos visiteurs doivent l'atteindre, pas seulement les chanceux en Wi-Fi rapide. Le LCP est la métrique que les visiteurs ressentent le plus directement : c'est le moment où la page a l'air prête. Il échoue généralement pour trois raisons : une image principale surdimensionnée, une réponse serveur lente, ou du code de thème et des polices qui bloquent le rendu. Les corrections sont tout aussi concrètes : des images au bon format et au bon poids, un hébergement ou un CDN rapide, et moins de ressources bloquantes. Sur un site sur-mesure léger, réussir le LCP est la norme plutôt qu'un chantier, et c'est l'une des principales raisons pour lesquelles nous construisons ainsi.
Qu'est-ce que l'INP, et pourquoi a-t-il remplacé le FID ?
L'Interaction to Next Paint (INP) mesure la rapidité avec laquelle une page réagit visuellement après un toucher, un clic ou une saisie, sur toute la visite plutôt que sur la seule première interaction. Un bon score est de 200 millisecondes ou moins. Il a remplacé le First Input Delay comme Core Web Vital en mars 2024, parce que le FID ne mesurait que le délai avant le traitement de la première interaction, que la plupart des sites réussissaient facilement tout en restant poussifs. L'INP capte la vraie frustration : un bouton d'ajout au panier qui hésite, un menu qui s'ouvre une seconde trop tard, un filtre qui fige la page. La cause habituelle est un excès de JavaScript qui se dispute le fil principal du navigateur : widgets de clavardage, popups, traceurs, apps d'avis et fonctions de thème. La solution est un budget de scripts : moins de scripts tiers, chargés plus tard, et des interactions conçues pour que la page réagisse d'abord et termine son travail ensuite.
Qu'est-ce que le CLS, et qu'est-ce qui fait bouger la mise en page ?
Le Cumulative Layout Shift (CLS) mesure à quel point le contenu visible se déplace de façon inattendue pendant le chargement et l'utilisation. Un bon score est de 0,1 ou moins. Vous en avez déjà subi un mauvais : vous allez toucher un lien, une image ou une bannière se charge au-dessus, le texte saute, et vous touchez la mauvaise chose. Au-delà de l'agacement, ces décalages minent la confiance au pire moment, comme sur une fiche produit ou au paiement. Les causes sont mécaniques et se corrigent : images et vidéos sans dimensions déclarées, polices qui s'affichent à une autre taille, barres de témoins, bannières promo et pubs injectées après le rendu du contenu, et intégrations qui se redimensionnent. Un build propre en évite presque tout en réservant l'espace de chaque élément avant son chargement, pour une mise en page stable dès le premier affichage. C'est la moins coûteuse des trois métriques à réussir quand elle est prévue dès le départ.
Pourquoi les Core Web Vitals rapportent-ils deux fois ?
Parce que la même amélioration aide deux choses à la fois : la façon dont les moteurs classent la page et le nombre de visiteurs qui restent assez longtemps pour acheter. Les Core Web Vitals font partie des signaux d'expérience de page de Google : les réussir élimine un désavantage en recherche. Indépendamment, des pages plus rapides et plus stables retiennent davantage les visiteurs : l'étude « Milliseconds Make Millions » de Deloitte et Google a associé même un gain de 0,1 seconde de vitesse mobile à une meilleure conversion sur les sites de commerce de détail mesurés. Peu d'améliorations touchent à la fois l'acquisition et la conversion ; la plupart des dépenses marketing achètent l'une ou l'autre. C'est aussi pourquoi le travail de vitesse dure plus longtemps que les campagnes : une fois le site rapide, chaque futur visiteur en profite, qu'il vienne de la recherche, de la pub, d'un courriel ou d'une réponse IA. La vitesse rejoint aussi la visibilité IA, puisque des pages légères rendues côté serveur sont plus faciles à lire et à citer pour n'importe quel robot.
Comment vérifier vos Core Web Vitals ?
Deux outils gratuits vous disent tout. PageSpeed Insights (pagespeed.web.dev) : collez votre URL et lisez la section du haut, « Découvrez ce que vivent vos utilisateurs réels » : ce sont les données terrain des vrais visiteurs Chrome, celles que Google utilise réellement. Le score laboratoire en dessous est un diagnostic, pas votre note : ne paniquez pas dessus. Ensuite, Google Search Console → rapport Core Web Vitals : il montre quels groupes de pages passent ou échouent sur tout le site, pour repérer des schémas (toutes les fiches produit qui échouent au LCP, par exemple) au lieu de tester les URL une à une. Regardez d'abord l'onglet mobile dans les deux outils : c'est sur mobile que la plupart des sites échouent et que vit l'essentiel de votre trafic. Cinq minutes, une fois par mois, suffisent à attraper les régressions avant qu'elles coûtent des positions.
Qu'est-ce qui casse chaque métrique, en général ?
Les coupables sont remarquablement constants. Le LCP casse sur des images héro surdimensionnées (une photo de 2 Mo là où un WebP de 150 Ko suffirait), du code de thème lent qui retarde le rendu, et des polices mal chargées. L'INP casse sur le JavaScript, la mort à petit feu des boutiques gavées d'apps : widgets de chat, popups, trackers et fonctions de thème se disputent le fil principal quand l'utilisateur tape. Le CLS casse sur des images sans dimensions déclarées, des bannières et barres cookies injectées tardivement, et des pubs qui bousculent le contenu. Notez le motif : presque chaque cause revient à « quelque chose a été ajouté sans se demander ce que ça coûte ». C'est pourquoi la vraie correction est architecturale, un build où les images partent optimisées, où les scripts sont rares et différés, où l'espace est réservé avant chargement, plutôt qu'un plugin d'optimisation qui combat les symptômes.
Que privilégions-nous sur nos propres projets ?
Ce n'est pas que de la théorie pour nous : c'est notre façon de construire. Sur chaque boutique que nous livrons, la même priorité revient : rendre l'expérience plus rapide et plus claire pour les visiteurs que vous avez déjà, avant de penser à en attirer davantage. Concrètement, cela veut dire des images au bon poids, un budget de scripts léger, une mise en page qui ne saute pas pendant le chargement, et tout vérifier sur un vrai téléphone plutôt que sur un ordinateur de bureau rapide. C'est précisément ce que mesurent les Core Web Vitals, et c'est l'argument honnête pour les traiter comme une part de la qualité d'un site, pas comme une case technique à cocher.
Les Core Web Vitals font-ils vraiment bouger le classement ?
Réponse honnête : c'est un signal de classement réel mais modeste, plus proche du départage que de l'atout maître : un excellent contenu sur un site lent bat encore un contenu creux sur un site rapide. Alors pourquoi s'en soucier ? Parce que l'effet classement est la plus petite moitié du gain. La lenteur que Google mesure est celle que vos visiteurs ressentent : des pages qui perdent la moitié de leur audience mobile avant de s'afficher ne convertissent pas, quelle que soit leur position. La vitesse se cumule aussi indirectement : un site rapide est exploré plus efficacement, retient plus longtemps, et gagne de meilleurs signaux comportementaux. Considérez les Core Web Vitals comme le bilan de santé de l'expérience que vous vendez, avec le bonus de classement en prime. Les optimiser purement « pour Google » passe à côté : l'argent a toujours été chez les visiteurs.
Sources
Vous voulez un site qui passe les Core Web Vitals et qui est bien construit pour le référencement ? Nous construisons rapide par défaut. Discutons-en.