Core Web Vitals pour l'e-commerce : seuils LCP, INP et CLS par plateforme

On s'intéresse en général aux Core Web Vitals d'un site e-commerce après avoir vu des chiffres rouges dans Google Search Console, ou après avoir entendu dire que « Google pénalise les sites lents ». La réalité est plus nuancée : les Core Web Vitals sont un signal de classement parmi d'autres, et la performance obtenue dépend fortement de la plateforme sur laquelle tourne la boutique. L'introduction générale aux trois métriques et à leur mesure est traitée dans notre article sur les Core Web Vitals — ici, on se concentre sur ce qui est spécifique à l'e-commerce : des catalogues avec des milliers de photos produits, des scripts de paiement et de recommandation, des bannières et des pop-ups qui décalent la mise en page au pire moment possible.

Trois métriques et leurs seuils — mesurés au 75e centile

Les Core Web Vitals (« Signaux Web essentiels » dans la documentation française de Google) sont trois métriques de performance, chacune avec un seuil « bon / à améliorer / mauvais » précisément défini :

• LCP (Largest Contentful Paint) — le temps nécessaire pour afficher le plus grand élément visible de la page. Selon web.dev : « Une valeur LCP satisfaisante est de 2,5 secondes ou moins ». Le tableau des seuils de Google classe comme « médiocre » un LCP supérieur à 4 000 ms ; entre les deux, une amélioration est nécessaire. Dans une boutique, le LCP est souvent déterminé par la photo principale du produit, un carrousel promotionnel sur la page d'accueil, ou la première rangée d'une grille de catégorie.
• INP (Interaction to Next Paint) — le temps entre une interaction de l'utilisateur (clic, appui, frappe au clavier) et le moment où le navigateur met réellement à jour l'écran en réponse. web.dev indique : « Un INP inférieur ou égal à 200 millisecondes signifie que la page a une bonne réactivité » et « un INP supérieur à 500 millisecondes signifie que la page a une mauvaise réactivité ». Entre ces deux valeurs, la réactivité est à améliorer. C'est la métrique directement liée au bouton « Ajouter au panier », aux filtres de catégorie et aux configurateurs de variantes.
• CLS (Cumulative Layout Shift) — une mesure des décalages de mise en page inattendus. Selon web.dev : « Une valeur CLS de 0,1 ou moins est considérée comme bonne. Les valeurs médiocres sont supérieures à 0,25. » Dans une boutique, le coupable habituel est une bannière de consentement aux cookies, un pop-up de réduction, ou une publicité chargée tardivement qui s'insère au-dessus du contenu juste quand le client commence à faire défiler la page.

Les trois seuils sont mesurés au 75e centile des visites, séparément pour le mobile et l'ordinateur. web.dev le formule ainsi : « un bon seuil à mesurer est le 75e centile de vos chargements de page, segmentés entre appareils mobiles et ordinateurs. » Pour une métrique donnée, web.dev précise : « si au moins 75 % des pages vues d'un site atteignent le seuil "bon", le site est classé comme ayant de bonnes performances pour cette métrique ». Pour réussir l'évaluation Core Web Vitals dans son ensemble, il faut franchir cette barre sur les trois métriques à la fois : les outils d'évaluation « doivent considérer qu'une page est conforme si elle atteint les objectifs recommandés au 75e centile pour les trois métriques Core Web Vitals ».

L'INP remplace le FID — le changement du 12 mars 2024

Si vous êtes tombé sur un article ou une formation qui liste encore le FID (First Input Delay) comme une des trois métriques Core Web Vitals, vous consultez une version obsolète. Google l'a annoncé sur le blog web.dev : « La métrique "Interaction to Next Paint" est désormais une métrique Core Web Vitals stable qui remplace le First Input Delay », en précisant que ce changement « représente une avancée significative dans la façon dont nous mesurons la réactivité des interactions et comble de nombreuses lacunes du FID ». L'article porte une date de dernière mise à jour du 12/03/2024 — le 12 mars 2024. Chrome a ensuite abandonné le FID : ses outils ne garantissent plus sa disponibilité, et « les développeurs auront jusqu'au 9 septembre 2024 pour effectuer la transition vers INP ».

La différence n'est pas cosmétique. Le FID ne mesurait que le délai avant que le navigateur commence à traiter la toute première interaction — et seulement la première. L'INP mesure la réactivité sur l'ensemble du cycle de vie de la page, pour toutes les interactions, et retient l'interaction la plus lente observée, en ignorant les valeurs aberrantes. Une boutique où ajouter le premier produit au panier semble instantané, mais où filtrer une catégorie après avoir défilé commence à traîner, aurait pu bien se classer en FID et mal en INP. Si votre outil de reporting ou votre extension SEO affiche encore le FID comme métrique de réactivité principale, c'est le signe qu'il n'a pas été mis à jour depuis mars 2024.

Le poids réel dans le classement de Google

Les Core Web Vitals font officiellement partie de l'expérience de page — le groupe de signaux que Google utilise pour décrire la qualité d'utilisation d'une page. La documentation Search Central de Google est directe à ce sujet : « La recherche Google s'efforce de toujours afficher le contenu le plus pertinent, même si l'expérience sur la page est décevante. » Elle poursuit : « Il n'y a pas qu'un seul signal. Nos principaux systèmes de classement tiennent compte de différents signaux qui coïncident avec l'expérience globale sur la page. » Et la partie qui compte le plus pour un propriétaire de boutique qui regarde un rapport dans Search Console : « L'obtention de bons résultats dans des rapports tels que le Rapport Core Web Vitals de la Search Console ou dans des outils tiers ne garantit pas que vos pages s'afficheront en haut des résultats de recherche Google. »

La même page ajoute une précision un paragraphe plus loin : « Les Core Web Vitals sont utilisées par nos systèmes de classement », mais « au-delà des Core Web Vitals, d'autres aspects de l'expérience sur la page ne contribuent pas directement à améliorer le classement de votre site Web dans les résultats de recherche. » Conclusion pratique : les CWV sont un signal réel mais limité — ils agissent surtout comme un facteur de départage quand vous êtes en concurrence avec des sites de qualité de contenu globalement comparable. Un score vert dans Search Console ne compensera pas un contenu produit pauvre ou une page non indexée ; un bon contenu avec un CWV faible peut toujours devancer un contenu plus faible avec un bon CWV. Ce n'est pas une raison d'ignorer la performance — c'est une raison de ne pas en faire votre seul levier SEO.

Données de champ et données de laboratoire — d'où viennent vraiment les chiffres

Les deux types de données éclairent des aspects différents de la performance, et il vous faut les deux :

• Les données de champ viennent d'utilisateurs réels. web.dev les définit ainsi : « Les données de champ sont déterminées en surveillant tous les utilisateurs qui accèdent à une page et en mesurant un ensemble donné de métriques de performances pour chacune des expériences individuelles de ces utilisateurs. » La source est le CrUX (Chrome User Experience Report) — developer.chrome.com le décrit comme un ensemble de données qui reflète la façon dont des utilisateurs réels de Chrome vivent leur expérience sur des destinations populaires du Web. C'est bien le CrUX — pas la mesure d'un robot d'exploration — qui alimente le rapport Core Web Vitals dans Search Console (voir plus bas).
• Les données de laboratoire proviennent d'un environnement contrôlé : « Les données de laboratoire sont déterminées en chargeant une page Web dans un environnement contrôlé avec un ensemble prédéfini de conditions réseau et d'appareil » (web.dev). C'est le résultat d'un test PageSpeed Insights ou d'une exécution locale de Lighthouse — reproductible, mais déconnecté des conditions réseau réelles de vos clients.

Quel score compte le plus ? web.dev est direct : « Si vous disposez à la fois de données sur le terrain et de données de laboratoire pour une page donnée, vous devez utiliser les données sur le terrain pour hiérarchiser vos efforts. » Les données de laboratoire sont utiles pour diagnostiquer une cause précise (quel script bloque le rendu, quelle image est trop lourde) — mais pas pour juger si votre boutique franchit le seuil CWV dans son ensemble.

PageSpeed Insights (PSI) combine les deux perspectives dans un seul rapport : « PSI fournit à la fois des données de laboratoire et des données sur le terrain concernant une page », et les données d'utilisateurs réels s'appuient sur le jeu de données du Chrome User Experience Report (CrUX), sur « la période de collecte des 28 derniers jours ». Le score Lighthouse dans PSI se répartit en tranches : « Un score de 90 ou plus est considéré comme bien », « un score compris entre 50 et 89 points nécessite une amélioration », et « un score inférieur à 50 points est considéré comme médiocre. » Le rapport Core Web Vitals dans Google Search Console s'appuie sur ces mêmes données de champ — selon la description de Google : « Le rapport Core Web Vitals affiche les performances des URL regroupées par état ("Médiocre", "Amélioration nécessaire", "Bon") », par métrique, et par groupes de pages similaires, où le statut d'un groupe est « défini par défaut sur l'état le plus lent qui lui est attribué pour ce type d'appareil » — c'est-à-dire celui de sa métrique la moins bonne. La source des données est « le rapport d'expérience utilisateur Chrome (ou "rapport CrUX") », donc toujours le CrUX, pas un test ponctuel.

Les Core Web Vitals selon la plateforme e-commerce — plus du double d'écart

La théorie dit qu'il n'y a qu'un seul seuil pour tout le monde. En pratique, la plateforme sur laquelle tourne votre boutique influence fortement vos chances de le franchir. Le HTTP Archive Web Almanac 2025 (chapitre 13, « Ecommerce », données de juillet 2025, publication janvier 2026) a mesuré la part de sites avec un « bon » score CWV — c'est-à-dire franchissant les trois seuils au 75e centile — répartie par plateforme e-commerce :

Le chapitre résume ainsi : « un site est considéré comme "bon" en CWV lorsqu'il franchit les trois seuils » (traduction libre), et attribue l'écart entre plateformes à une seule métrique : « le LCP est le principal facteur de différenciation » (traduction libre). Pour WooCommerce, cela se voit clairement : son point faible est précisément le LCP (45 % de bons scores sur ordinateur, 39 % sur mobile selon les tableaux détaillés du chapitre), alors que l'INP se porte bien pour cette plateforme (99 % de bons scores sur ordinateur, 88 % sur mobile), et le CLS atteint 68 % sur ordinateur et 85 % sur mobile. Le principal goulot d'étranglement est donc le temps de rendu du plus grand élément de page ; le chapitre relie les résultats plus faibles de WooCommerce à sa « nature infiniment personnalisable » (traduction libre), et les meilleurs résultats ailleurs à des plateformes qui proposent des thèmes rapides et des écosystèmes d'applications étroitement contrôlés.

Deux réserves sur ce tableau. D'abord : les données sont mondiales — le Web Almanac détecte les plateformes par identification technologique (Wappalyzer) sur un large échantillon de sites dans le monde entier ; il n'existe pas de ligne séparée pour la Suisse ni pour aucun autre pays. Aucune étude spécifique au CWV par plateforme en Suisse n'a été trouvée pour compléter ces données. Ensuite : aucune édition du Web Almanac (2024 ou 2025) ne publie un chiffre agrégé unique pour « % de sites e-commerce avec un bon CWV » — seulement la répartition par plateforme ci-dessus. Considérez ce tableau comme indiquant où se situe le problème typique d'une technologie donnée, pas comme un verdict sur votre boutique en particulier — on peut obtenir un résultat nettement meilleur ou pire que la moyenne sur la même plateforme.

Ce qui dégrade le plus souvent le LCP, l'INP et le CLS dans une boutique

Chacune des trois métriques a ses points faibles typiques en e-commerce. Le chapitre Web Almanac 2025 pointe les sources habituelles : pour le LCP — images hero, grilles de produits et CSS/JS bloquant le rendu ; pour l'INP — JavaScript lourd, scripts tiers et concurrence pour le thread principal ; pour le CLS — images produits chargées tardivement, widgets de personnalisation et bannières promotionnelles (traduction libre). Aucune des sources vérifiées ne publie de répartition en pourcentage des causes spécifique à la Suisse ou à un autre marché en particulier :

• Le LCP bute en général sur ce qu'il mesure précisément : le temps d'affichage du plus grand élément visible. Dans une boutique, c'est le plus souvent la photo principale du produit ou la bannière hero de la page d'accueil : un fichier trop lourd, un mauvais format, l'absence de priorité de chargement (preload), ou un serveur qui répond lentement aux données produit avant que le navigateur puisse commencer à afficher quoi que ce soit.
• L'INP se dégrade sous l'accumulation de JavaScript exécuté en réponse à l'interaction de l'utilisateur — scripts de paiement, calculateurs de frais de livraison, chats, recommandations « produits similaires », qui écoutent tous les mêmes clics et se disputent le thread principal du navigateur. Le client clique sur « Ajouter au panier », et la page est justement occupée par autre chose.
• Le CLS se dégrade à cause de contenu inséré après que la page a déjà été rendue, sans espace réservé pour lui — bannières de consentement aux cookies, pop-ups de réduction, publicités chargées tardivement, ou images sans dimensions définies qui « surgissent » et poussent tout ce qui se trouve en dessous.

Le mécanisme sous-jacent est le même dans chaque cas : quelque chose se charge plus tard que prévu, ou occupe le thread du navigateur plus longtemps que prévu. La correction commence par l'identification de l'élément précis — c'est à cela que servent les données de laboratoire, pas les données de champ.

Un plan d'amélioration sur 30 jours

1. Semaine 1 — mesurer avant de commencer à corriger quoi que ce soit. Lancez le test de vitesse de site Digital Vantage sur la page d'accueil, une liste de catégorie et une page produit — trois modèles différents avec des profils de problèmes différents. Vérifiez en parallèle le rapport Core Web Vitals dans Search Console, pour avoir aussi des données de champ, pas seulement un test ponctuel.
2. Semaine 2 — le LCP. Identifiez quel élément est retenu comme « plus grand élément visible » sur chacun des trois modèles. Vérifiez son format, la taille du fichier et s'il porte une priorité de chargement. Vérifiez aussi le temps de réponse du serveur — une image optimisée ne sert à rien si le backend lui-même répond lentement.
3. Semaine 3 — l'INP. Passez en revue les scripts qui se chargent et s'exécutent sur les pages produit et dans le panier. Les scripts dont vous n'avez pas besoin immédiatement (chats, pixels marketing, widgets d'avis) peuvent souvent se charger avec un délai, après la première interaction de l'utilisateur.
4. Semaine 4 — le CLS. Passez en revue les pages avec une limitation réseau activée et vérifiez ce qui décale la mise en page : bannières cookies, pop-ups, images sans dimensions définies. Réservez-leur de l'espace à l'avance plutôt que de les insérer après coup.
5. Après 30 jours — mesurez à nouveau. Comparez votre résultat de test et les données de Search Console avec le point de départ. Les données de champ couvrent une fenêtre glissante des 28 derniers jours : vous ne verrez donc l'effet complet d'un changement qu'environ quatre semaines après sa mise en ligne, pas le lendemain.

Vous pouvez réaliser une partie de ce travail vous-même si vous avez accès au code du modèle et à quelqu'un capable de le modifier ; d'autres parties — notamment les changements côté serveur, un CDN d'images ou la refonte du chargement des scripts — nécessitent généralement un développeur. Il n'existe pas de prix moyen crédible et publiquement disponible pour ce type de travail d'optimisation, en Suisse non plus, donc nous n'en citons aucun ici — le coût dépend du nombre de modèles que compte une boutique, du nombre de scripts tiers intégrés et de l'endroit où se situe le problème : dans le code ou dans l'hébergement lui-même. Si vous préférez confier cela à quelqu'un qui mesure d'abord et chiffre ensuite un périmètre précis, contactez-nous.