Core Web Vitals pour Shopify : guide complet (2026)

Shopify et Core Web Vitals : vous ne contrôlez pas le serveur

Pour optimiser les Core Web Vitals, Shopify est fondamentalement différent de WordPress ou des sites développés sur mesure. Sur WordPress, vous contrôlez tout : le serveur, la base de données, la couche de cache, chaque ligne de code. Sur Shopify, vous évoluez sur une plateforme managée où certains éléments vous échappent totalement.

D'après le Core Web Vitals Technology Report, Shopify devance WordPress sur les taux de réussite aux CWV sur mobile (environ 65 % contre 44 % fin 2025). L'infrastructure de Shopify est excellente par défaut : des serveurs rapides, un CDN mondial via Cloudflare, la conversion automatique des formats d'images et des thèmes de base pré-optimisés. La plateforme gère parfaitement la partie serveur.

Les problèmes viennent de ce que les marchands ajoutent par-dessus : applications, scripts tiers, modifications du thème, images surdimensionnées et chargement excessif de polices. C'est là que les boutiques Shopify échouent aux Core Web Vitals. Et comme l'accès au serveur et au code source reste restreint, votre stratégie d'optimisation doit s'adapter.

Les Core Web Vitals de Shopify en chiffres

Shopify se classe au 2e rang mondial du CrUX Technology Report pour les taux de réussite aux Core Web Vitals, juste derrière Duda (une plateforme bien moins répandue). Voici les données issues de CrUX et de benchmarks indépendants :

Sources : CrUX Technology Report (juin 2025), analyse CMS de SearchEngineJournal, benchmark Shero Commerce sur 1 000 boutiques (nov. 2025). *Valeurs médianes issues du benchmark Shero, et non le p75 de CrUX.

Le benchmark Shero Commerce mené sur 1 000 boutiques Shopify réelles montre que seules 48 % valident l'ensemble des trois Core Web Vitals sur mobile. Ce chiffre est inférieur aux données globales de CrUX pour Shopify. Cela indique que les boutiques référencées dans CrUX (qui nécessitent un volume de trafic Chrome suffisant) correspondent à des sites plus importants et mieux optimisés. Le LCP mobile médian de 2,26 secondes frôle dangereusement le seuil du « bon » fixé à 2,5 secondes. Le moindre ajout (une application supplémentaire, une image hero non optimisée) peut faire basculer une boutique dans l'échec.

Le CLS et l'INP ne posent pas problème. Avec un CLS médian de 0,01, Shopify est remarquable, et son INP médian de 153 ms se situe confortablement dans la catégorie « bon ». C'est sur le LCP que les boutiques Shopify échouent aux Core Web Vitals.

Les données réelles de CoreDash sur les boutiques Shopify confirment ce constat. Les boutiques qui échouent aux CWV échouent presque systématiquement sur le LCP. Celles qui chargent plus de 8 scripts d'applications tierces affichent un LCP mobile médian supérieur à 3,0 secondes. Celles qui en comptent 3 ou moins maintiennent un LCP médian sous les 2,0 secondes. Dans les données observées, la corrélation entre le nombre d'applications installées et le LCP constitue le premier facteur prédictif d'échec aux CWV sur Shopify.

Ce que vous ne contrôlez pas sur Shopify

Avant d'optimiser, comprenez bien les contraintes. Sur Shopify, impossible de :

• Changer de serveur ou d'hébergement. Shopify tourne sur sa propre infrastructure. Impossible de migrer vers un hébergeur plus rapide, de configurer du cache au niveau serveur ou d'ajuster les paramètres PHP. Point positif : le TTFB de Shopify est généralement excellent (inférieur à 300 ms dans la plupart des régions).
• Supprimer content_for_header. Shopify injecte du JavaScript obligatoire sur chaque page via cette balise Liquid. Elle embarque ses propres outils d'analyse, les scripts de checkout et l'infrastructure de chargement des applications. Impossible de la retirer, et la différer risque de casser le checkout et les fonctionnalités des applications.
• Contrôler le CDN. Shopify s'appuie sur Cloudflare comme CDN. Impossible de configurer des règles de cache, des edge workers ou des en-têtes personnalisés comme vous le feriez sur votre propre compte Cloudflare.
• Accéder à la base de données ou au code backend. Le moteur de templates Liquid de Shopify s'exécute côté serveur, mais vous ne pouvez pas optimiser les requêtes en base de données ni le rendu côté serveur au-delà de ce que Liquid permet.

Toute votre stratégie d'optimisation doit donc se concentrer sur ce que vous pouvez contrôler : le code de votre thème, les applications installées, les images, les polices et les scripts tiers.

Le problème n° 1 des CWV sur Shopify : la surcharge d'applications

Les applications installées constituent la première cause d'échec aux Core Web Vitals sur Shopify. Chaque application peut injecter du JavaScript et du CSS sur l'ensemble des pages de votre boutique, y compris là où elle n'est pas utilisée. Une application d'avis qui se charge sur la page d'accueil. Un widget de recommandation produit qui s'exécute sur la page de contact. Un compte à rebours actif sur chaque fiche produit, même sans promotion en cours.

Comment les applications injectent leur code

Les applications Shopify injectent du code de plusieurs façons, ce qui compte pour le nettoyage :

• App Embeds (éditeur de thème) : ils se désactivent directement dans l'éditeur de thème sous « App Embeds ». C'est la méthode la plus propre et la plus simple à gérer.
• Snippets de thème : certaines applications ajoutent du code directement dans les fichiers de votre thème lors de l'installation. Désinstaller l'application ne supprime pas toujours ce code. Vous devez inspecter manuellement snippets/ et sections/ pour traquer les résidus.
• API ScriptTag : les applications peuvent injecter des scripts par programmation sans toucher aux fichiers du thème. Ils se chargent via content_for_header. Désinstaller l'application les supprime, mais le script peut rester en cache.
• Loaders tiers : certaines applications chargent du JavaScript externe depuis leur propre CDN, ce qui génère des résolutions DNS et des requêtes réseau supplémentaires.

Méthode d'audit des applications

Voici comment j'audite l'impact des applications Shopify sur les performances :

1. Passez la page d'accueil, une fiche produit, une page de collection et la page panier dans PageSpeed Insights. Notez les scores LCP, INP et CLS.
2. Ouvrez les Chrome DevTools et allez dans l'onglet Coverage. Rechargez la page et observez le pourcentage de JavaScript inutilisé. Sur les boutiques Shopify surchargées, 60 % à 80 % du JavaScript chargé ne sert absolument à rien sur une page donnée.
3. Vérifiez l'onglet Network filtré sur le JavaScript. Triez par taille. Identifiez les scripts provenant des applications par rapport à ceux de votre thème. La colonne « Initiator » indique ce qui a chargé chaque script.
4. Désactivez les applications une par une (ou coupez leurs App Embeds) et retestez. Mesurez l'impact individuel de chaque application sur l'INP et le LCP.
5. Pour chaque application, tranchez : la valeur business justifie-t-elle le coût en performance ? Peut-on la remplacer par une alternative plus légère ? Peut-on la charger uniquement sur des types de pages précis ?

Les données CoreDash issues de projets d'optimisation Shopify montrent l'impact typique d'un nettoyage : supprimer un seul script de widget d'avis inutile a amélioré l'INP médian de 45 ms sur une boutique. Supprimer trois applications inutilisées (un outil de popup désactivé, un programme de fidélité et un widget de chat obsolète) a réduit le JavaScript total de la page de 380 Ko et amélioré le LCP mobile de 1,1 seconde. Chaque application que vous n'utilisez plus ralentit votre boutique pour rien. Supprimez-la.

Corriger le LCP sur Shopify

Sur les boutiques Shopify, l'élément LCP est presque toujours l'image de la bannière hero sur la page d'accueil, l'image principale sur les fiches produits ou la bannière sur les pages de collection. Le CDN de Shopify sert automatiquement les images au format WebP, ce qui aide. Mais plusieurs optimisations restent entièrement à votre charge.

Précharger l'image hero

Le filtre Liquid image_tag de Shopify intègre un paramètre preload. Lorsqu'il est défini sur true, Shopify envoie un en-tête HTTP Link avec rel=preload directement depuis le serveur. Le navigateur le reçoit avant même de commencer à analyser le HTML : c'est le signal de préchargement le plus précoce possible. Il inclut aussi automatiquement les attributs imagesrcset et imagesizes de la balise, garantissant un préchargement responsive parfait, sans aucun risque d'écart d'URL.

Combinez cela avec fetchpriority: 'high' sur la balise <img> et loading: 'eager' pour désactiver le lazy loading appliqué par défaut par Shopify. Pour l'image hero, voici le code :

{{ section.settings.hero_image | image_url: width: 1200 | image_tag:
    preload: true,
    fetchpriority: 'high',
    loading: 'eager',
    sizes: '100vw'
}}

Cette seule ligne vous apporte : le préchargement par en-tête HTTP (le plus rapide possible), fetchpriority="high" sur la balise <img>, un chargement immédiat au lieu du lazy loading, des attributs width et height automatiques (évitant le CLS) et la génération automatique du srcset. Définissez systématiquement fetchpriority="high" sur l'image hero, même sans préchargement.

Si votre thème utilise une image d'arrière-plan CSS pour le hero

Certains thèmes Shopify affichent la bannière hero via la propriété CSS background-image plutôt qu'avec une balise <img>. C'est un antipattern majeur pour le LCP. Vous perdez fetchpriority, vous perdez le srcset automatique, vous perdez le préchargement par en-tête HTTP de Shopify, et le navigateur ne peut même pas commencer à récupérer l'image avant d'avoir téléchargé et analysé le fichier CSS.

La vraie solution consiste à remplacer l'arrière-plan CSS par une balise <img> pour exploiter correctement image_tag. Cela nécessite de modifier le code du thème, mais c'est la seule approche propre.

Si vous ne pouvez vraiment pas modifier le template, vous pouvez ajouter une directive de préchargement manuelle dans theme.liquid :

{%- if template == 'index' -%}
  <link rel="preload" as="image" href="{{ section.settings.hero_image | image_url: width: 1200 }}">
{%- endif -%}

Attention : l'URL du preload doit correspondre exactement à celle du CSS, y compris le paramètre de version ?v= de Shopify et le paramètre &width=. S'il y a la moindre différence, le navigateur télécharge l'image deux fois, ce qui dégrade les performances au lieu de les améliorer.

Pour la stratégie complète de préchargement d'image LCP, consultez comment précharger l'image LCP.

Ne pas appliquer de lazy loading au-dessus de la ligne de flottaison

De nombreux thèmes Shopify appliquent loading="lazy" à toutes les images, y compris au hero. Cela indique au navigateur de déprioriser l'image la plus importante de la page. Veillez à ce que votre thème exclue du lazy loading les images situées au-dessus de la ligne de flottaison. Sur les thèmes modernes utilisant le filtre image_tag de Shopify, utilisez loading: 'eager' pour les images hero.

Optimiser la taille des images

Le CDN de Shopify peut redimensionner les images à la volée via des paramètres d'URL, mais vos templates Liquid doivent demander la bonne dimension. Ne chargez pas une image de 2 000 px de large si elle ne s'affiche qu'en 800 px. Utilisez le balisage d'image responsive de Shopify avec des attributs srcset et sizes appropriés. Consultez notre guide sur l'optimisation des images.

Corriger l'INP sur Shopify

Sur Shopify, les échecs à l'INP sont presque toujours causés par du JavaScript qui bloque le main thread. L'injection native de content_for_header par Shopify ajoute déjà une base de JavaScript incompressible. Tout ce que vous ajoutez par-dessus aggrave la situation.

Différer les scripts tiers non critiques

Les widgets de chat (Tidio, Zendesk, Intercom), les applications d'avis (Judge.me, Yotpo, Loox), les outils de personnalisation (popups Klaviyo, Privy) et les outils d'analytics (Google Analytics, Facebook Pixel, Hotjar) ne doivent pas se charger pendant le rendu initial de la page. La bonne approche repose sur requestIdleCallback : le navigateur ne charge ces scripts que lorsque le main thread est inactif, généralement quelques secondes après l'affichage de la page.

N'utilisez pas de différé basé sur l'interaction (charger des scripts au premier scroll, clic ou tap). Si un utilisateur clique sur un bouton et que le site réagit en chargeant 500 Ko de JavaScript tiers sur ce même événement, le main thread se retrouve bloqué et cette interaction hérite d'un score INP catastrophique. L'intérêt même de différer est de libérer le main thread pour les interactions de l'utilisateur, pas d'entrer en conflit avec elles.

Remplacez l'attribut src par data-src sur les scripts non critiques, puis réinjectez-les lorsque le navigateur est inactif :

<script>
(window.requestIdleCallback || function(cb) { setTimeout(cb, 1); })(function() {
  document.querySelectorAll('script[data-src]').forEach(function(s) {
    s.src = s.dataset.src;
  });
});
</script>

Le fallback avec setTimeout prend en charge Safari, qui n'implémente pas requestIdleCallback. Contrairement à requestIdleCallback, il n'attend pas une véritable période d'inactivité. Mais il permet tout de même de découper l'exécution sur le main thread, et les scripts injectés dynamiquement contournent de toute façon le preload scanner, ce qui en fait un fallback tout à fait convenable en pratique.

Pour d'autres stratégies pour différer le JavaScript, consultez 14 méthodes pour différer le JavaScript.

Réduire le JavaScript du thème

Les thèmes Online Store 2.0 de Shopify (comme Dawn) sont conçus pour être légers, mais de nombreux thèmes tiers ajoutent un JavaScript très lourd pour des méga-menus, des sliders produits, des modales d'aperçu rapide et des animations. Auditez le JavaScript de votre thème avec l'onglet Coverage des Chrome DevTools. Si votre thème charge plus de 200 Ko de JavaScript, identifiez les fonctionnalités que vous pouvez désactiver ou remplacer par des solutions en pur CSS.

Corriger le CLS sur Shopify

Sur les boutiques Shopify, le Cumulative Layout Shift est généralement causé par trois facteurs : des images sans dimensions, le basculement de polices (font swapping) et du contenu injecté dynamiquement par des applications.

Définir les dimensions des images dans les templates Liquid

Vérifiez dans vos templates Liquid si des balises <img> manquent d'attributs width et height. Le filtre image_tag de Shopify peut les générer automatiquement :

{{ product.featured_image | 
   image_tag: widths: '200,400,800', sizes: '(max-width: 768px) 100vw, 50vw' }}

Cela génère des images responsives avec les bonnes dimensions et empêche tout décalage de mise en page au chargement.

Réserver de l'espace pour le contenu dynamique

Les App Embeds qui injectent des étoiles d'avis, des badges de confiance, des comptes à rebours ou des barres d'annonce après le chargement provoquent du CLS. Pour chaque élément dynamique, réservez l'espace nécessaire avec la propriété CSS min-height afin que le contenu autour ne saute pas lors de l'apparition de l'élément. C'est particulièrement critique pour les éléments injectés au-dessus du contenu existant.

Optimiser le chargement des polices

Si votre thème Shopify charge des polices web personnalisées, assurez-vous qu'elles utilisent font-display: swap avec une police de fallback bien calibrée. Préchargez vos fichiers de polices principaux pour réduire le délai d'affichage du texte avec la bonne typographie. Ne chargez que les graisses et styles strictement nécessaires. Consultez notre guide sur l'optimisation des polices.

Choix du thème Shopify et performances

Le choix de votre thème définit le niveau de performance de base de votre boutique. Le projet ThemeVitals suit les données CrUX réelles des thèmes Shopify. Enseignements clés :

• Dawn (le thème gratuit par défaut de Shopify) obtient d'excellents résultats constants sur les Core Web Vitals, car il a été conçu avec la performance en priorité.
• Les thèmes riches en sections, en animations et en fonctionnalités natives (méga-menus, aperçu rapide de produit, tiroirs de panier AJAX) ont tendance à embarquer plus de JavaScript et affichent un moins bon INP.
• Les thèmes Online Store 2.0 sont généralement plus rapides que les anciens thèmes, car ils exploitent l'architecture moderne de sections et de chargement des ressources de Shopify.

Si vous choisissez un nouveau thème, vérifiez ses données CrUX sur ThemeVitals avant d'acheter. L'optimisation de performance la moins chère consiste à démarrer directement avec un thème rapide.

Ce que Shopify fait bien par défaut

Shopify fait beaucoup de choses correctement dès l'installation :

• Infrastructure rapide : les serveurs de Shopify et le CDN Cloudflare assurent un TTFB bas et régulier à l'échelle mondiale.
• WebP automatique : le CDN de Shopify convertit automatiquement les images au format WebP lorsque le navigateur le prend en charge.
• HTTP/2 et Brotli : activés par défaut sur l'ensemble des boutiques Shopify.
• CDN d'images avec redimensionnement à la volée : vous pouvez demander n'importe quelle image à n'importe quelle largeur via des paramètres d'URL.
• Indices de préconnexion (preconnect) : Shopify insère automatiquement des indices preconnect pour les domaines de son CDN.

Ces réglages par défaut expliquent pourquoi les performances de base de Shopify sont bonnes. Votre mission consiste simplement à ne pas ruiner ces atouts avec un excès d'applications et de scripts.

Surveiller votre boutique Shopify

Le tableau de bord administrateur de Shopify affiche un « Speed Score », mais ce chiffre simplifié repose sur Lighthouse et ne reflète pas vos véritables Core Web Vitals. Pour un suivi réel des performances :

• Google Search Console : consultez le rapport Core Web Vitals pour obtenir les field data sur l'ensemble de votre boutique
• CoreDash : installez le snippet RUM ultra-léger (une seule ligne de code dans theme.liquid) pour obtenir des données Core Web Vitals en temps réel, segmentées par type de page, appareil et pays
• PageSpeed Insights : testez les URL spécifiques de vos fiches produits, collections et page d'accueil pour obtenir des données de diagnostic

Mesurez après chaque installation d'application, mise à jour de thème ou lancement de campagne saisonnière. Sur Shopify, les régressions de performance sont presque toujours provoquées par un élément récemment ajouté.

Les données de suivi de CoreDash montrent que la cause la plus fréquente de régression des CWV sur Shopify est l'installation d'une nouvelle application qui injecte du JavaScript sur l'ensemble du site. En moyenne, une nouvelle application Shopify ajoute 50 Ko à 150 Ko de JavaScript à chaque chargement de page. Pour une boutique située juste à la limite du seuil LCP (entre 2,3 et 2,5 secondes), une seule installation d'application peut la faire basculer dans le rouge. La deuxième cause la plus courante concerne les opérations saisonnières : bannières du Black Friday, popups pour les fêtes et comptes à rebours promotionnels ajoutés pour un événement puis oubliés.