Google utilise les signaux "page experience" dans son algorithme de classement depuis 2021. Pour beaucoup d'équipes e-commerce, les Core Web Vitals restent ce truc qu'on sait important mais qu'on n'a jamais le temps de traiter. Pendant ce temps, les études continuent de confirmer le lien entre ces métriques et les résultats business : taux de rebond, taux de conversion, revenu par session.
Voici ce que chaque métrique mesure concrètement pour votre boutique, les seuils Google, et où concentrer vos efforts.
Les trois métriques
Largest Contentful Paint (LCP)
Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible à l'écran. Sur une fiche produit, c'est généralement l'image principale. Sur une page catégorie, le hero banner ou la première ligne de vignettes.
Seuils Google (web.dev) :
- Bon : ≤ 2,5 secondes
- À améliorer : 2,5 – 4,0 secondes
- Mauvais : > 4,0 secondes
Pourquoi les sites e-commerce galèrent avec le LCP : les images produit sont souvent l'élément le plus grand, et elles sont servies en haute résolution sans optimisation. Une image hero de 2 Mo fait plonger votre LCP, peu importe la vitesse de votre serveur. Les carrousels aggravent le problème. Le navigateur ne sait pas quelle image sera la "plus grande" tant qu'il n'a pas calculé le layout, ce qui retarde l'affichage.
Ce qui marche :
- Précharger l'image principale :
<link rel="preload" as="image" href="product-main.webp"> - Formats modernes (WebP, AVIF) : 25-35% plus légers que JPEG à qualité équivalente
- Images responsives avec
srcsetpour que les mobiles téléchargent des fichiers adaptés - Dimensions explicites (
widthetheight) sur les balises<img>
Cumulative Layout Shift (CLS)
Le CLS mesure les mouvements visuels inattendus. Vous allez taper sur "Ajouter au panier" et le bouton saute parce qu'une image s'est chargée au-dessus ou qu'une bannière s'est insérée. Google quantifie ça.
Seuils Google :
- Bon : ≤ 0,1
- À améliorer : 0,1 – 0,25
- Mauvais : > 0,25
Les causes habituelles en e-commerce :
- Images sans dimensions : le navigateur rend un espace de hauteur 0, puis l'agrandit quand l'image arrive. Tout ce qui est en dessous descend d'un coup.
- Éléments injectés dynamiquement : bannières "Livraison gratuite !", barres de cookies, badges de promo ("-30%"), popups newsletter qui s'insèrent au-dessus du fold
- Fonts web qui arrivent en retard : quand la police personnalisée remplace la police système, le texte se redistribue et les éléments bougent (Flash of Unstyled Text)
- Widgets d'avis tiers (Trustpilot, Yotpo, Judge.me) qui se chargent en asynchrone et poussent le contenu
Ce qui marche :
- Toujours mettre
widthetheightsur les<img>(ou CSSaspect-ratio) - Réserver l'espace pour le contenu dynamique avec
min-height font-display: swapavec une police de fallback qui a des métriques proches- Charger les bannières de cookies en overlay, pas en élément injecté dans la page
Total Blocking Time (TBT)
Le TBT mesure le temps total où le thread principal du navigateur a été bloqué pendant plus de 50 ms, entre le First Contentful Paint et le Time to Interactive. Concrètement : est-ce que l'utilisateur peut cliquer, scroller et taper sans lag ?
Le TBT est l'équivalent en labo de First Input Delay (FID), que Google a remplacé par Interaction to Next Paint (INP) en mars 2024. Lighthouse continue de mesurer le TBT parce qu'il ne nécessite pas d'interaction utilisateur.
Seuils Google :
- Bon : ≤ 200 ms
- À améliorer : 200 – 600 ms
- Mauvais : > 600 ms
Ce qui bloque le thread principal sur les sites e-commerce :
- Les scripts tiers : analytics, pixels de tracking, chat widgets, outils A/B testing, moteurs de personnalisation. Une analyse HTTP Archive a montré que le JavaScript tiers représente la majorité du temps de blocage sur les sites retail
- Les gros bundles JavaScript : les frameworks SPA (React, Vue, Angular) qui hydratent toute la page au chargement
- Les scripts synchrones dans le
<head>: tout script sansasyncoudeferbloque le parsing HTML
Ce qui marche :
- Différer les scripts non critiques :
<script defer src="..."> - Lazy-load des widgets de chat : les déclencher au scroll ou au clic, pas au chargement de la page
- Code splitting pour charger uniquement le JS de la page courante
- Auditer votre conteneur Google Tag Manager. Les tags s'accumulent et personne ne les supprime.
Mobile vs. Desktop : c'est le mobile qui compte
Un point qui surprend beaucoup d'équipes : Google utilise la performance mobile pour le ranking, pas la desktop. Depuis la fin du passage au mobile-first indexing en 2023, c'est la version mobile de votre site que Google crawle et évalue.
Les mobiles ont moins de puissance CPU, des connexions plus lentes et des écrans plus petits. Un site qui score 95 en desktop Lighthouse peut tomber à 45 en mobile. L'écart est particulièrement marqué sur les sites e-commerce chargés en JavaScript, où le CPU du téléphone peine à parser et exécuter les gros bundles.
PurpleScan lance des audits Lighthouse mobile et desktop à chaque scan. Le dashboard affiche les deux versions côte à côte.
Comment PurpleScan note la performance
PurpleScan utilise Google Lighthouse sous le capot. Le score global suit la pondération Lighthouse :
- TBT : 30%
- LCP : 25%
- CLS : 25%
- Speed Index : 10%
- First Contentful Paint : 10%
PurpleScan traduit le score en note :
- ≥ 0,9 (score 90+) : Bon
- 0,5 – 0,89 : À améliorer
- < 0,5 : Mauvais
La note globale suit le principe du pire cas : si un seul Core Web Vital est "Mauvais", la note globale est "Mauvais". C'est la même logique que Google.
Au-delà du score
Un score de performance sans contexte n'aide pas. "Votre LCP est à 4,2 secondes" ne dit pas quoi corriger. PurpleScan fournit des détails au niveau des ressources :
- Les 10 fichiers les plus lourds chargés par la page, classés par taille de transfert, avec le type de ressource et le domaine
- Un breakdown par domaine externe : chaque tiers qui a chargé des ressources, catégorisé (analytics, pub, CDN, social), avec nombre de requêtes et taille totale
- La timeline réseau de chaque requête : TTFB, durée de téléchargement, temps total
- La répartition par type de ressource : quelle part du poids vient des images, des scripts, des CSS, des fonts
C'est la différence entre "votre score est bas" et "c'est cette image de 1,8 Mo sur la homepage qui plombe votre LCP".
La performance se dégrade toute seule
Les Core Web Vitals ne sont pas un problème qu'on règle une fois. La performance se dégrade naturellement quand on ajoute des features, installe des apps, met à jour des thèmes, lance des campagnes saisonnières. Un site à 90 en janvier peut être à 60 en mars après un popup de soldes, un nouveau widget d'avis et un feed Instagram.
PurpleScan lance Lighthouse selon votre planning (quotidien, hebdomadaire, mensuel) et suit l'évolution des scores. Quand ça baisse, vous le savez.
Commencez par vos pages à plus fort trafic : homepage, pages catégorie principales, fiches produit les plus vendues. C'est là que les gains de performance ont le plus d'impact sur le chiffre d'affaires.