Core Web Vitals pour l'E-commerce : Pourquoi les visiteurs à forte intention obtiennent les pires performances

Le problème de performance invisible dans l'e-commerce

Beaucoup de mes clients se soucient profondément de réussir les Core Web Vitals. Réussir signifie que 75 % de l'ensemble du trafic devrait avoir une bonne expérience. Un objectif admirable. Mais en optimisant pour ces 75 %, un groupe restreint mais critique d'environ 5 % est négligé : les visiteurs qui vont se convertir en clients.

L'ironie ? Ces visiteurs à forte intention obtiennent souvent les pires performances sur votre site. Non pas parce que vous avez oublié d'optimiser. Parce que votre système de mise en cache les exclut activement.

Dernière révision par Arjen Karel en mars 2026

Pourquoi vos données CrUX cachent le problème

L'optimisation des Core Web Vitals, principalement en raison du bonus de classement Google, a tendance à se concentrer sur l'optimisation pour le visiteur légèrement en dessous de la moyenne. Dans l'e-commerce, il est très judicieux d'aller au-delà et d'ajouter une attention particulière sur les visiteurs à forte intention. Ce sont les visiteurs qui se convertissent en clients.

Selon une recherche de Deloitte et Google, une amélioration de 0,1 seconde de la vitesse de page entraîne une augmentation de 9,1 % des actions d'ajout au panier pour les sites de vente au détail. C'est aussi le moment exact où la mise en cache cesse de fonctionner pour eux.

Nous pouvons généralement identifier ces utilisateurs par le nombre d'articles dans leur panier.

Il y a un autre angle mort. CrUX (le rapport sur l'expérience utilisateur Chrome) suit uniquement les utilisateurs Chrome dont la synchronisation est activée. De nombreux acheteurs e-commerce utilisent Safari sur mobile ou des navigateurs sans synchronisation. Votre tableau de bord CrUX pourrait afficher des scores verts alors que vos acheteurs réels vivent une expérience très différente. C'est pourquoi un score CrUX réussi ne raconte pas toute l'histoire.

Le précipice du cache : que se passe-t-il lorsqu'un utilisateur ajoute au panier

Voici le problème : l'ajout d'articles à un panier d'achat détruit votre mise en cache. Et la mise en cache est ce qui rend votre site rapide.

Les plugins de mise en cache désactivent la mise en cache de la page complète pour les utilisateurs avec un contenu dynamique. Quelque chose d'aussi simple que des "articles dans un panier d'achat" force le serveur à reconstruire la page entière à chaque requête. Cela augmente considérablement votre 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 typique, le TTFB passe d'environ 100 ms (en cache) à 1 600 ms ou plus (sans cache). Il s'agit d'une multiplication par 16 du temps de réponse du serveur au moment où quelqu'un ajoute un produit à son panier. J'ai vu des cas où des utilisateurs connectés de WooCommerce attendent 5 à 9 secondes pour une page qui se charge en moins d'une seconde pour les visiteurs anonymes.

Comment chaque plateforme gère cela

WooCommerce définit plusieurs cookies lorsqu'un utilisateur ajoute au panier : woocommerce_cart_hash, woocommerce_items_in_cart et wp_woocommerce_session. Au moment où un plugin de mise en cache (WP Rocket, LiteSpeed Cache, WP Super Cache) détecte ces cookies, il contourne le cache pour chaque page. Pas seulement la page du panier. Votre page d'accueil, vos pages de produits, vos pages de catégories : toutes sans cache. En plus de cela, WooCommerce déclenche une requête AJAX vers /?wc-ajax=get_refreshed_fragments à chaque chargement de page pour maintenir le widget de mini-panier à jour. Cette requête à elle seule peut prendre 2 à 3 secondes sur un hébergement mutualisé.

C'est l'une des raisons pour lesquelles WooCommerce a le taux de réussite des Core Web Vitals le plus bas de toutes les principales plateformes e-commerce. Selon le Web Almanac 2025, seulement 33 % des sites WooCommerce réussissent les trois Core Web Vitals sur ordinateur, contre 76 % pour Shopify.

Shopify gère cela mieux grâce à son infrastructure CDN gérée, mais même Shopify ne peut pas mettre en cache les pages contenant des objets customer ou cart. La différence est que le TTFB de base de Shopify (environ 0,51 seconde) est déjà suffisamment rapide pour que la pénalité liée à l'absence de cache soit plus faible.

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

Vos meilleurs clients obtiennent vos pires pages

Les chiffres rendent cela douloureux. Farfetch a mesuré une baisse de 1,3 % du taux de conversion pour chaque augmentation de 100 ms du LCP. Blue Triangle a trouvé une baisse de 40 à 50 % du taux de conversion lorsque le LCP passe de 2 secondes à 4 ou 5 secondes.

Un visiteur parcourt votre site rapide et mis en cache. Il trouve un produit qu'il aime. Il clique sur "ajouter au panier". À ce moment exact, la mise en cache s'arrête et son TTFB bondit de 100 ms à 1 600 ms. À partir de là, chaque page qu'il visite (comparaison de produits, vérification de l'expédition, passage en caisse) n'est pas mise en cache. Les personnes les plus susceptibles d'acheter parcourent désormais la version la plus lente de votre site.

À travers les sites surveillés par CoreDash, nous voyons les utilisateurs avec panier subir un TTFB 3 à 5 fois pire que les visiteurs anonymes sur les plateformes e-commerce auto-hébergées. Sur les plateformes gérées comme Shopify, l'écart est plus faible (1,5 à 2x) mais reste mesurable.

Comment détecter cela dans vos données RUM

Vous ne pouvez pas voir ce problème dans Lighthouse ou PageSpeed Insights. Ces outils testent en tant que visiteurs anonymes sans cookies. Vos scores de laboratoire sembleront excellents pendant que vos acheteurs réels galèrent.

Pour trouver ce problème, vous avez besoin du Real User Monitoring. Segmentez vos données RUM selon que l'utilisateur a défini 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 votre problème.

Dans la plupart des plateformes d'analyse, vous pouvez également segmenter par type de page. Comparez vos pages de listes de produits (généralement en cache) avec vos pages de panier et de paiement (jamais en cache). Une différence de TTFB de plus de 500 ms entre ces types de pages est un signal d'alarme indiquant que votre server waiting duration nécessite une attention particulière.

Comment corriger les performances pour les visiteurs à forte intention

Corrigez le backend avant de compter sur la mise en cache. Ne comptez pas uniquement sur les plugins de mise en cache. Analysez votre code backend, optimisez les requêtes de base de données et affinez votre serveur pour garantir un TTFB rapide même sans mise en cache. Un site lent sans cache sera catastrophiquement lent pour les utilisateurs avec panier. La sous-partie cache duration du TTFB ne devrait pas faire tout le gros du travail.

Utilisez la mise en cache partielle (mise en cache de fragments). Mettez en cache les parties coûteuses de votre page séparément. 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 lorsque le cache de la page complète est désactivé. Lorsqu'un utilisateur avec panier demande une page, votre CMS l'assemble à partir de fragments mis en cache au lieu de tout régénérer à partir de zéro. Cela peut réduire le TTFB sans cache de 60 à 80 %.

Effectuez le rendu des composants dynamiques côté client. C'est l'approche de Magento 2 et elle fonctionne. Servez la majorité de la page sous forme de HTML mis en cache (rendu côté serveur). Utilisez ensuite JavaScript et un petit appel API pour récupérer les parties dynamiques (nombre d'articles dans le panier, salutation de l'utilisateur, recommandations personnalisées) après le chargement de la page. Le navigateur obtient immédiatement le HTML rapide et mis en cache. Les éléments dynamiques se remplissent un instant plus tard. Votre LCP et FCP restent rapides car ils sont pilotés par la structure en cache, et non par le contenu dynamique.

Le framework headless de Shopify (Hydrogen) fait exactement cela : les données de produit sont agressivement mises en cache avec des TTL longs, 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. Ce modèle évite également les problèmes d'INP car la récupération dynamique se produit de manière asynchrone au lieu de bloquer l'interaction de l'utilisateur.

Implémentez une gestion efficace des clés de cache. Utilisez des clés simples pour les éléments statiques (l'URL est souvent suffisante comme clé de cache) et des clés complexes pour le contenu dynamique qui inclut l'ID utilisateur, les ID de produits et les horodatages. Cela vous permet de mettre en cache au niveau de l'utilisateur au lieu de choisir entre "entièrement mis en cache" et "pas mis en 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 bascule pour cela. Cela élimine un appel AJAX de 2 à 3 secondes à chaque chargement de page pour les utilisateurs avec panier.

Envisagez la composition côté edge. Si vous utilisez Cloudflare, les Workers peuvent assembler des pages au niveau de l'edge : servir le corps de la page mis en cache depuis le CDN et injecter des fragments dynamiques (panier, infos utilisateur) via des sous-requêtes séparées. Cloudflare a publié une implémentation d'Edge Side Includes pour les Workers qui fait exactement cela, gardant votre TTFB rapide tout en servant du contenu personnalisé.