Core Web Vitals en e-commerce : pourquoi les visiteurs à forte intention subissent les pires performances

Le problème de performance invisible en e-commerce

Beaucoup de mes clients tiennent absolument à valider les Core Web Vitals. Valider signifie que 75 % du trafic global doit bénéficier d'une bonne expérience. Un objectif louable. Mais en optimisant pour ces 75 %, un groupe restreint mais critique d'environ 5 % est oublié : les visiteurs qui vont convertir en clients.

L'ironie ? Ces visiteurs à forte intention d'achat subissent souvent les pires performances du site. Pas parce que vous avez oublié d'optimiser. Mais parce que votre système de cache les exclut activement.

Pourquoi vos données CrUX masquent le problème

L'optimisation des Core Web Vitals, motivée avant tout par le bonus de classement sur Google, a tendance à cibler le visiteur situé légèrement sous la moyenne. En e-commerce, il est bien plus pertinent d'aller au-delà et de porter une attention particulière aux visiteurs à forte intention. Ce sont eux qui se convertissent en clients.

D'après une étude de Deloitte et Google, une amélioration de 0,1 seconde de la vitesse de page entraîne une hausse de 9,1 % des ajouts au panier sur les sites marchands. C'est aussi le moment précis où le cache cesse de fonctionner pour eux.

On identifie généralement ces utilisateurs au nombre d'articles dans leur panier.

Il existe un autre angle mort. Le CrUX (Chrome User Experience Report) ne suit que les utilisateurs de Chrome ayant activé la synchronisation. Or, beaucoup d'acheteurs en ligne utilisent Safari sur mobile ou des navigateurs non synchronisés. Votre tableau de bord CrUX peut afficher des scores au vert alors que vos véritables acheteurs vivent une expérience très différente. C'est pourquoi un score CrUX validé ne dit pas tout.

La rupture de cache : ce qui se passe lors de l'ajout au panier

Voici le problème : ajouter des articles au panier anéantit votre cache. Et c'est le cache qui rend le site rapide.

Les plugins de cache désactivent le cache de page intégrale dès qu'un utilisateur déclenche du contenu dynamique. Un élément aussi anodin que « des articles dans un panier » oblige le serveur à reconstruire entièrement la page à chaque requête. Cela augmente nettement le Time to First Byte, ce qui ralentit directement le Largest Contentful Paint et le First Contentful Paint.

Les chiffres sont spectaculaires. Sur un site WooCommerce classique, le TTFB passe d'environ 100 ms (avec cache) à 1 600 ms ou plus (sans cache). Le temps de réponse serveur est multiplié par 16 dès qu'un visiteur ajoute un produit à son panier. J'ai vu des utilisateurs connectés attendre 5 à 9 secondes sur WooCommerce pour une page qui se charge en moins d'une seconde pour un visiteur anonyme.

Le comportement selon chaque plateforme

WooCommerce installe plusieurs cookies dès qu'un utilisateur ajoute un article au panier : woocommerce_cart_hash, woocommerce_items_in_cart et wp_woocommerce_session. Dès qu'un plugin de cache (WP Rocket, LiteSpeed Cache, WP Super Cache) détecte ces cookies, il contourne le cache pour chaque page. Pas seulement la page panier. La page d'accueil, les fiches produits, les pages de catégories : plus rien n'est en cache. En plus de cela, WooCommerce déclenche une requête AJAX vers /?wc-ajax=get_refreshed_fragments à chaque chargement de page pour mettre à jour le widget du mini-panier. Cette seule requête peut prendre 2 à 3 secondes sur un hébergement mutualisé.

C'est l'une des raisons pour lesquelles WooCommerce a le plus faible taux de réussite aux Core Web Vitals parmi toutes les grandes plateformes e-commerce. Selon le Web Almanac 2025, seuls 33 % des sites WooCommerce valident les trois Core Web Vitals sur desktop, contre 76 % pour Shopify.

Shopify s'en sort mieux grâce à son infrastructure CDN infogérée, mais même Shopify ne peut pas mettre en cache les pages contenant des objets customer ou cart. La différence, c'est que le TTFB de base de Shopify (environ 0,51 seconde) est déjà suffisamment rapide pour limiter la pénalité hors cache.

Magento 2 a trouvé une solution astucieuse : la page complète est toujours en cache, même pour les utilisateurs avec un panier. Le contenu dynamique (mini-panier, message d'accueil, état des stocks) est récupéré côté client via un appel AJAX vers /customer/section/load/ et stocké dans le localStorage du navigateur. La page elle-même reste dans le cache pleine page. C'est le problème du « slow by design » résolu directement au niveau de l'architecture.

Vos meilleurs clients subissent vos pires pages

Les chiffres sont cruels. Farfetch a mesuré une baisse de 1,3 % du taux de conversion pour chaque tranche de 100 ms d'augmentation du LCP. Blue Triangle a constaté une chute de 40 à 50 % des conversions quand le LCP passe de 2 secondes à 4 ou 5 secondes.

Un visiteur parcourt votre site rapide et mis en cache. Il trouve un produit qui lui plaît. Il clique sur « ajouter au panier ». À cet instant précis, le cache s'arrête et son TTFB bondit de 100 ms à 1 600 ms. À partir de là, chaque page consultée (comparer des produits, vérifier les frais de port, passer commande) est servie sans cache. Vos acheteurs les plus probables naviguent désormais sur la version la plus lente du site.

Sur les sites surveillés par CoreDash, les utilisateurs avec un panier subissent un TTFB 3 à 5 fois plus lent que les visiteurs anonymes sur les plateformes auto-hébergées. Sur les plateformes infogérées comme Shopify, l'écart est plus faible (1,5 à 2x), mais reste mesurable.

Comment détecter ce problème dans vos données RUM

Ce problème est invisible dans Lighthouse ou PageSpeed Insights. Ces outils testent en tant que visiteurs anonymes, sans cookies. Vos scores lab data sembleront parfaits alors que vos acheteurs réels rencontrent des lenteurs.

Pour détecter ce problème, vous avez besoin de Real User Monitoring. Segmentez vos données RUM selon la présence ou non d'un cookie de panier. Comparez le TTFB, le FCP et le LCP entre ces deux segments. Si vous constatez un écart de 2x ou plus, le contournement du cache est bien votre problème.

Sur la plupart des plateformes d'analyse, vous pouvez également segmenter par type de page. Comparez vos pages de catalogue (généralement en cache) avec vos pages panier et commande (jamais en cache). Un écart de TTFB supérieur à 500 ms entre ces types de pages est un signal d'alerte : le server waiting duration demande une intervention.

Comment corriger les performances pour les visiteurs à forte intention

Optimisez le backend avant de compter sur le cache. Ne vous reposez pas uniquement sur des plugins de cache. Analysez votre code backend, optimisez les requêtes en base de données et réglez votre serveur pour garantir un TTFB rapide même sans cache. Un site lent sans cache sera catastrophique pour les utilisateurs avec un panier. La sous-partie cache duration du TTFB ne doit pas faire tout le travail à elle seule.

Utilisez la mise en cache partielle (fragment caching). Mettez en cache séparément les éléments lourds de la page. Les descriptions de produits, les menus de navigation et le contenu du pied de page changent rarement et peuvent être mis en cache dans Memcached ou Redis, même quand le full page cache est désactivé. Quand un utilisateur avec un panier demande une page, le CMS l'assemble à partir de fragments en cache au lieu de tout régénérer de zéro. Cela peut réduire le TTFB hors cache de 60 à 80 %.

Rendez les composants dynamiques côté client. C'est l'approche de Magento 2, et elle fonctionne. Servez la majeure partie de la page sous forme de HTML mis en cache (rendu côté serveur). Puis utilisez JavaScript et un appel API léger pour charger les parties dynamiques (compteur de panier, message d'accueil, recommandations personnalisées) après le chargement de la page. Le navigateur reçoit immédiatement le HTML rapide issu du cache. Les données dynamiques viennent s'y insérer un instant plus tard. Le LCP et le FCP restent rapides parce qu'ils dépendent du socle mis en cache, pas du contenu dynamique.

Le framework headless de Shopify (Hydrogen) applique exactement ce principe : les données produits sont mises en cache agressivement avec de longs TTL, tandis que les données du panier et du client utilisent CacheNone() et sont récupérées côté client après le chargement. Cette méthode évite également les problèmes d'INP, car la récupération dynamique s'effectue de manière asynchrone au lieu de bloquer les interactions de l'utilisateur.

Gérez efficacement vos clés de cache. Utilisez des clés simples pour les éléments statiques (l'URL suffit souvent comme clé de cache) et des clés complexes pour le contenu dynamique, incluant l'ID utilisateur, les ID de produits et des horodatages. Cela permet de mettre en cache à l'échelle de chaque utilisateur, au lieu de devoir choisir entre « entièrement en cache » et « pas de cache du tout ».

Désactivez les fragments de panier sur les pages sans panier. Si vous utilisez WooCommerce, désactivez l'appel à wc-ajax=get_refreshed_fragments sur les pages qui n'affichent pas de mini-panier. Plusieurs plugins de performance (Perfmatters, FlyingPress) proposent une option dédiée. Cela supprime un appel AJAX de 2 à 3 secondes à chaque chargement de page pour les utilisateurs avec un panier.

Envisagez la composition à l'edge. Si vous utilisez Cloudflare, les Workers peuvent assembler les pages à l'edge : servir le corps de page en cache depuis le CDN et injecter les fragments dynamiques (panier, infos utilisateur) via des sous-requêtes distinctes. Cloudflare a publié une implémentation d'Edge Side Includes pour les Workers qui réalise précisément cela, préservant la rapidité du TTFB tout en fournissant un contenu personnalisé.