Core Web Vitals porte mal son nom mais l’idée est bonne. Ces indicateurs mesurent trois aspects vécus directement par l’acheteur : le temps avant que la page semble prête, le délai de réaction à une action, et les déplacements inattendus de l’interface. Google les exprime en millisecondes, soit l’unité la moins susceptible de débloquer un budget.
Voici la traduction : trois indicateurs, leur coût réel, et la cause Magento la plus courante.
Utilisez les données terrain, pas les données labo. Le rapport Core Web Vitals de Search Console reflète ce que de vrais visiteurs sur de vrais appareils ont vécu sur 28 jours glissants. Un test Lighthouse sur votre ordinateur ne montre qu’une visite simulée, une seule fois.
LCP : délai avant que la page paraisse prête
Largest Contentful Paint mesure le moment où le plus grand élément visible — souvent une image principale ou un visuel produit — termine son affichage. Le seuil Google : 2,5 secondes pour une bonne expérience, 4 secondes au-delà desquelles la note devient mauvaise.
D’un point de vue commercial, LCP détermine si un visiteur issu d’une publicité payante voit votre produit. Quelqu’un qui clique sur une annonce Shopping depuis un mobile a une attention brève et peu patiente : une boutique qui met quatre secondes à afficher une image produit paie des clics qu’elle ne convertit pas. Si vous faites de l’acquisition payante, LCP est un indicateur d’efficacité média avant d’être technique.
Les causes habituelles sous Magento
- Un temps de réponse initial lent. Cache de page manqué, base de données sous-dimensionnée ou configuration Varnish non adaptée à votre structure d’URL. Aucun élément du front-end ne peut masquer un serveur lent.
- Images catalogue non optimisées. Photos produits téléchargées en qualité impression et redimensionnées côté navigateur. Le traitement d’image de Magento aide, mais ne compense pas un fichier source de 4 Mo.
- CSS et JavaScript bloquants pour l’affichage. Le bundle par défaut de Luma bloque le premier affichage, comme presque tous les scripts tiers ajoutés dans le head.
- Polices web sans « font-display: swap ». Le texte est prêt mais invisible, en attente du fichier de police.
L’ordre compte. Optimiser les images alors que le serveur répond en 1,8 seconde, c’est traiter la mauvaise priorité. Mesurez d’abord le temps de réponse initial : s’il dépasse 600 ms, c’est là qu’il faut agir.
INP : délai avant que la page réagisse
Interaction to Next Paint mesure le délai entre l’action d’un acheteur et la réaction visible de la page. Moins de 200 ms est jugé bon ; au-delà de 500 ms, la note est mauvaise et l’utilisateur a l’impression que le site ne fonctionne pas.
INP est l’indicateur qui vous coûte des paniers, pas seulement des sessions. Il est le plus mauvais là où l’impact est maximal : sélection de déclinaison, modification de quantité dans le mini-panier, filtres sur une page catégorie, étape de choix du mode d’expédition. Un acheteur qui clique deux fois sur une taille faute de retour visuel ajoute une ligne en double ou, plus souvent, quitte le site.
Les causes habituelles sous Magento
- Recalculs Knockout.js sur Luma. Le mini-panier et le tunnel de commande sont les zones Knockout les plus lourdes du thème, donc les plus lentes à réagir.
- Gestionnaires de tags tiers et scripts de personnalisation qui monopolisent le Main Thread pendant que l’utilisateur tente d’utiliser la page.
- Navigation à facettes qui recharge toute la page à chaque filtre, au lieu de mettre à jour localement.
- Widgets de chat et d’avis initialisés au chargement plutôt qu’à l’interaction.
INP est le plus souvent causé par un composant acheté, non développé en interne. Auditez les scripts tiers avant de modifier le thème.
CLS : la page bouge-t-elle sous le doigt de l’utilisateur
Cumulative Layout Shift mesure les déplacements inattendus — contenu qui saute lors du chargement tardif d’images, bannières ou widgets. Un bon score est inférieur à 0,1.
CLS vous coûte de deux façons, l’une évidente, l’autre moins. La première : les clics ratés ; un acheteur appuie sur Ajouter au panier, une bannière s’affiche au-dessus, il clique ailleurs. La seconde : la confiance. Une page qui bouge pendant le chargement fait amateur, et cette impression nuit au taux de conversion dès la première visite.
Les causes habituelles sous Magento
- Images sans attributs width et height, empêchant le navigateur de réserver l’espace avant l’arrivée du fichier.
- Blocs CMS et bannières promotionnelles injectés au-dessus de la ligne de flottaison après le premier affichage.
- Bannières cookies et consentement qui déplacent la page au lieu de s’afficher en superposition.
- Widgets tiers — avis, badges de confiance, chat — intégrés dans des conteneurs sans hauteur réservée. Ce cas est quasi systématique, et presque toujours trivial à corriger.
CLS est le plus simple et le moins coûteux des trois à corriger, mais reste souvent ignoré car il ne « semble » pas relever de la performance. Il s’agit généralement de quelques lignes de CSS pour réserver les espaces nécessaires.
Comment prioriser quand les trois métriques échouent
Les trois indicateurs ne posent presque jamais problème au même degré, et ne méritent pas la même attention. Notre ordre :
- CLS en premier. C’est le plus rapide à corriger, le plus facile à vérifier, et il élimine un problème sans contrepartie.
- LCP en second, en commençant par le temps de réponse du serveur (time-to-first-byte) et les images. C’est ici que votre budget d’acquisition se dilue.
- INP en dernier, car c’est le plus complexe et celui qui demande le plus souvent de retirer un élément apprécié par un décideur.
Segmentez par gabarit avant de commencer. La plupart des boutiques Magento que nous auditons ont une page d’accueil qui passe et des pages catégorie qui échouent, avec des actions différentes à mener sur chacune. Les moyennes globales masquent le problème réel pour lequel vous payez.
Ce que cela donne concrètement
Lorsque nous avons repris la boutique Magento de Careshop, la plainte initiale était classique — le site semblait lent — et les causes étaient réparties sur les trois indicateurs et le serveur. L’ordre ci-dessus n’est pas théorique : c’est celui qui a permis d’obtenir des résultats sans refonte du storefront.
Si l’écart restant après ce travail reste important, la question devient front-end. Nous avons rédigé un cadre budgété pour choisir entre Hyvä, une PWA ou rester sur Luma. Ne commencez pas par là. Commencez par la mesure.
Définir un objectif réaliste
Chercher un score Lighthouse parfait n’est pas un bon usage du budget technique. Le signal de classement Google repose sur un seuil de passage/échec au 75e percentile des visites réelles — il vous faut que la majorité des sessions réelles soient bonnes, sur les gabarits qui comptent. C’est un objectif atteignable sur Magento sans tout reconstruire.
Fixez donc l’objectif : gabarits catégorie et produit validant les trois indicateurs sur données terrain mobile, sur une fenêtre continue de 28 jours. C’est un objectif auquel une équipe technique peut être tenue et qu’une équipe financière peut comprendre. Un score sur 100 mesuré sur desktop n’a pas ce sens.
C’est autour de ce travail que s’articulent nos missions d’optimisation de la vitesse de page, et pour les catalogues retail c’est souvent la prestation technique la plus rentable de l’année.
Questions fréquentes
Les Core Web Vitals influencent-ils réellement le classement Google ?
Ils sont un signal de classement confirmé, mais leur poids reste faible — la pertinence et la qualité du contenu priment. L’argument commercial le plus solide reste la conversion : la lenteur qui fait échouer l’évaluation vous coûte des ventes, indépendamment de votre positionnement.
Pourquoi Search Console ne donne-t-il pas le même score que Lighthouse ?
Ils mesurent des choses différentes. Lighthouse est un test en laboratoire sur un appareil simulé ; Search Console fournit des données réelles issues des utilisateurs Chrome sur 28 jours glissants. Ce sont ces données de terrain que Google utilise et qui reflètent vos clients réels. Il est normal que les deux diffèrent ; fiez-vous aux données de terrain.
Combien de temps après une correction avant de voir les chiffres bouger ?
La fenêtre de données terrain est de 28 jours : une correction appliquée aujourd’hui ne sera pleinement visible qu’au bout de quatre semaines, et la tendance n’est fiable qu’après six. Évitez d’évaluer — ou d’annuler — le travail avant la fin du premier mois.
Quelle métrique corriger en priorité sur une boutique Magento ?
Presque toujours CLS. C’est la moins coûteuse à corriger, la plus rapide à vérifier, et il s’agit souvent de réserver l’espace pour les images et widgets tiers. C’est aussi la métrique la plus souvent négligée car elle ne donne pas l’impression d’un problème de vitesse.
Peut-on réussir les Core Web Vitals avec le thème Luma par défaut ?
Oui. Cela demande de la rigueur — audit des extensions, report du JavaScript, pipeline d’images, optimisation du cache et du serveur — mais un résultat satisfaisant sur Luma est atteignable pour la plupart des catalogues. Changer de thème permet d’aller plus loin, mais ce n’est pas une condition d’entrée.
Évaluez ce que cela vous coûte
Nous auditons vos données terrain par gabarit, identifions l’indicateur qui pose problème, et vous expliquons ce qu’il faudrait pour corriger — en tenant compte de l’ensemble des extensions, pas en les écartant. Contactez notre équipe ; réponse sous un jour ouvré.