L'état des performances Shopify en 2026

Points clés à retenir

• Les Core Web Vitals sont un critère de classement Google confirmé, et depuis mars 2024, l’INP a remplacé le FID comme métrique de réactivité. “Bon” signifie un LCP inférieur à 2,5s, un INP inférieur à 200ms et un CLS inférieur à 0,1.¹²
• La vitesse est un levier de conversion, pas seulement de SEO. Un gain de vitesse de 0,1s sur mobile a fait grimper les conversions e-commerce de 8,4 % et le panier moyen de 9,2 % dans l’étude de Deloitte et Google.³
• Seuls 48 % des sites web valident les trois Core Web Vitals sur mobile (Web Almanac 2025). Le LCP est la métrique où la plupart des sites échouent ; l’INP est là où les boutiques Shopify surchargées d’apps souffrent le plus.⁴
• Le plus gros frein pour une boutique Shopify est rarement la plateforme elle-même. C’est l’accumulation de JavaScript lié aux apps, les widgets tiers, les médias lourds en haut de page, et les changements de mise en page (layout shifts) lorsque les scripts se chargent tardivement.
• Le code natif du thème évite la taxe de runtime des apps à chaque visite. Dans notre analyse de plus de 500 boutiques Shopify, les sites utilisant des page builders rendus via des apps étaient systématiquement plus lents que les sites équivalents construits avec le code natif du thème.

La performance Shopify en 2026, en bref : la base de la plateforme est solide et s’améliore, les critères de mesure ont évolué, et presque tous les problèmes que rencontrent les vraies boutiques proviennent de ce que les marchands ajoutent par-dessus.

Tous les quelques mois, un marchand m’envoie un score PageSpeed, généralement dans le rouge, en me posant la même question : est-ce la faute de Shopify, de mon thème, ou des douze apps que j’ai installées l’année dernière ? Vous trouverez ci-dessous les benchmarks de performance Shopify sourcés et les facteurs qui ralentissent la plupart des boutiques.

Pourquoi vous pouvez nous faire confiance

J’ai plus de 15 ans d’expérience en développement, et nous travaillons dans l’écosystème Shopify depuis plus de quatre ans. Nous avons mesuré les Core Web Vitals sur plus de 500 boutiques Shopify et refait des thèmes spécifiquement pour récupérer la vitesse perdue à cause des apps. Nous développons aussi Fudge, l’opérateur IA pour les boutiques Shopify, noté 4.9 sur le Shopify App Store. Son éditeur de boutique et son page builder écrivent les modifications et les pages directement dans votre thème en tant que code natif, plutôt que de les rendre via le runtime d’une app. Ce choix de conception vient directement de ce problème de performance, nous serons donc transparents sur notre parti pris quand c’est le cas.

Pourquoi les performances de la boutique comptent encore plus en 2026

Deux forces font de la vitesse une préoccupation de premier ordre cette année, plutôt qu’un simple bonus technique.

Les Core Web Vitals sont un critère de classement, et l’ensemble de métriques a changé

Google utilise les Signaux Web Essentiels (Core Web Vitals) dans le cadre de ses systèmes de classement de l’expérience sur la page.² C’est vrai depuis un certain temps. Ce qui a changé plus récemment, c’est l’ensemble des métriques lui-même.

En mars 2024, l’Interaction to Next Paint (INP) a remplacé le First Input Delay (FID) comme Signal Web Essentiel de la réactivité.¹ Le FID ne mesurait que le délai lors de la première interaction d’un utilisateur. L’INP mesure la latence des interactions tout au long de la visite, de sorte qu’il capture les clics lents, les menus qui laguent et les réponses molles d’ajout au panier que le FID ignorait discrètement. C’est un critère plus difficile et plus juste.

Les trois seuils pour une « bonne » expérience, mesurés au 75e centile des chargements de pages réels, sont :

• LCP (Largest Contentful Paint) : 2,5 s ou moins - vitesse d’affichage du contenu principal
• INP (Interaction to Next Paint) : 200 ms ou moins - réactivité de la page aux interactions
• CLS (Cumulative Layout Shift) : 0,1 ou moins - à quel point la mise en page bouge pendant le chargement²

Ce sont les seuils officiels de Google. Une page qui les rate n’est pas disqualifiée de la recherche, mais elle subit un désavantage concurrentiel face aux boutiques qui les valident.

La vitesse booste la conversion, avec de vrais revenus à la clé

L’argument du référencement (SEO) n’est que la moitié de l’équation. L’autre moitié est que les boutiques plus rapides vendent plus.

L’étude contrôlée la plus citée ici est le rapport « Milliseconds Make Millions » de Deloitte et Google, qui a mesuré 37 sites de marques sur plus de 30 millions de sessions. Une amélioration de 0,1 seconde du temps de chargement sur mobile a augmenté les taux de conversion du retail de 8,4 % et la valeur moyenne des commandes de 9,2 %.³ Un dixième de seconde produit une variation des revenus frôlant les deux chiffres. Notre guide de vitesse mobile Shopify explique comment capturer cette augmentation sur les connexions 3G et les appareils bas de gamme, là où les gains sont les plus importants.

Pour vous donner une idée de l’ampleur de l’enjeu au niveau du checkout, la propre étude commanditée par Shopify indique que la conversion de son checkout est jusqu’à 36 % plus élevée, et 15 % plus élevée en moyenne, que les checkouts concurrents.⁵ La plateforme a fait un vrai travail sur les parties qu’elle contrôle. C’est sur la vitrine, avant le checkout, que la plupart des marchands laissent encore de l’argent sur la table.

Pour un aperçu catégorie par catégorie des taux de conversion, consultez nos benchmarks de taux de conversion Shopify.

Les seuils des Core Web Vitals, et comment le web s’en sort

Avant d’examiner Shopify spécifiquement, il est utile de savoir à quoi ressemble la “norme” sur l’ensemble du web, car les boutiques Shopify sont évaluées sur la même base.

Le Web Almanac de HTTP Archive, qui analyse des millions d’origines réelles, a révélé qu’en juillet 2025, seuls 48 % des sites web validaient les trois Core Web Vitals sur mobile, contre 36 % deux ans plus tôt.⁴ Voici le détail par métrique :

Deux choses ressortent.

Premièrement, le passage à l’INP a placé la barre plus haut. L’Almanac 2024 a révélé que 48 % des sites mobiles auraient validé l’ensemble des critères avec l’ancienne métrique FID, mais que seuls 43 % y parvenaient avec l’INP.⁶ Le web n’est pas devenu plus lent. L’outil de mesure est devenu plus juste.

Deuxièmement, l’INP s’améliore rapidement mais reste le point sensible pour les sites interactifs. Les taux de réussite de l’INP sur mobile sont passés de 55 % en 2022 à 64 % en 2023 et 74 % en 2024,⁶ puis à 77 % en 2025.⁴ L’écart entre le desktop et le mobile reste important, et l’INP est précisément la métrique qui se dégrade avec un JavaScript lourd, car chaque script que le navigateur doit parser et exécuter entre en compétition avec le main thread qui gère les clics (taps).

Gardez ça en tête, car c’est au niveau du JavaScript que l’histoire de Shopify prend tout son sens.

Où en sont réellement les boutiques Shopify

Shopify se situe au-dessus de la moyenne du e-commerce sur la métrique que la plateforme contrôle le plus directement. L’analyse e-commerce du Web Almanac note que Shopify maintient de bons taux de réussite LCP depuis 2022, un groupe qu’elle ne partage qu’avec une poignée de plateformes.⁷ Ce n’est pas un hasard. Chaque boutique Shopify tourne sur le même CDN, le même edge caching et le même Liquid rendu côté serveur. Les bases du first-paint sont donc excellentes par défaut, d’une manière qu’une plateforme auto-hébergée ne peut garantir.

Là où les boutiques Shopify ont du mal, c’est au même endroit que le reste du web interactif : l’INP. Et là, la cause n’est presque jamais la plateforme. C’est le JavaScript côté client que les marchands empilent par-dessus.

Une petite note d’honnêteté sur les chiffres. Les données globales publiques concernant “la part des boutiques Shopify qui valident les trois Core Web Vitals” varient énormément selon les sources et les périodes de mesure. Je ne vais donc pas citer un pourcentage global comme s’il était définitif. Les faits défendables et sourcés sont les suivants : le LCP au niveau de la plateforme Shopify est régulièrement bon,⁷ le taux de réussite pour les trois métriques sur l’ensemble du web est de 48 % sur mobile,⁴ et l’INP est la métrique qui subit le plus de pression. Le reste du score d’une boutique est déterminé par ce que le marchand y ajoute.

Les plus grands facteurs de ralentissement sur Shopify

Dans toutes les boutiques que nous avons auditées, les mêmes coupables reviennent sans cesse. Aucun d’entre eux n’est Shopify. Et tous s’accumulent.

La lourdeur du JavaScript des applications

C’est le facteur le plus important. La page web mobile médiane envoie déjà environ 570 Ko de JavaScript.⁸ Sur une boutique Shopify exécutant une pile d’applications typique, ce nombre grimpe rapidement, car la plupart des applications injectent leur propre bundle de scripts à chaque chargement de page, que le visiteur interagisse ou non avec la fonctionnalité.

Une application d’avis clients, une app d’upsell, un convertisseur de devises, un widget de chat et un page builder peuvent chacun ajouter des dizaines, voire des centaines de kilo-octets. Le navigateur doit tout télécharger, parser et exécuter, et cette exécution est exactement ce qui pousse l’INP au-delà des 200 ms. La fonctionnalité pourrait être utilisée par 2 % des visiteurs. Le coût d’exécution est payé par 100 % d’entre eux.

Les widgets tiers

Lié mais distinct : les scripts chargés depuis le domaine d’un tiers. Les avis, les pop-ups de preuve sociale, le chat en direct, les analytics au-delà de l’essentiel, et les lecteurs vidéo intégrés contactent tous un serveur tiers avant de s’afficher. Chacun ajoute une requête DNS, une connexion et un poids que vous ne contrôlez pas. Lorsque ce tiers connaît des ralentissements, votre LCP s’en ressent.

Images non optimisées et médias “hero”

Les images des produits et lifestyle sont le contenu le plus lourd sur la plupart des vitrines, et le média “hero” (bannière principale) est généralement l’élément LCP. À elle seule, une image non compressée de 1,5 Mo sur une connexion mobile peut exploser le budget de 2,5 s du LCP. Les correctifs sont peu glamour mais efficaces : servez du WebP ou AVIF, redimensionnez les images pour l’appareil et différez tout ce qui se trouve sous la ligne de flottaison. Notre guide expliquant comment charger les images en différé sur Shopify (lazy load) détaille la mécanique sans casser l’élément LCP au-dessus de la ligne de flottaison.

Surcharge du thème et scripts bloquant le rendu

Les thèmes accumulent du poids au fil du temps. Les sections qui ne sont plus utilisées, les fonctionnalités superposées par des développeurs successifs et les scripts chargés dans l’en-tête du document qui bloquent le premier affichage s’additionnent. Un script bloquant le rendu dans le <head> oblige le navigateur à arrêter de construire la page jusqu’à ce qu’il télécharge et s’exécute. Déplacer les scripts non critiques en « defer » et supprimer le code mort du thème est souvent le travail le plus rentable sur une boutique ancienne. Consultez notre guide sur comment accélérer un thème Shopify pour découvrir les leviers spécifiques.

Décalage de mise en page dû aux éléments à chargement tardif

Le CLS est la métrique que la plupart des boutiques réussissent, mais les échecs sont évitables et perturbants. Une bannière qui pousse le contenu vers le bas lors de son chargement, une image sans dimensions, un changement de police qui refusionne le texte, ou une barre de cookies qui apparaît après l’affichage font tous bouger la page sous le doigt de l’acheteur. Réserver de l’espace pour les éléments tardifs résout presque tout. Pour le workflow de diagnostic complet et le correctif pour chaque cause, consultez notre guide sur le Cumulative Layout Shift sur Shopify.

Le problème du poids des apps : code natif vs widgets empilés

Prenez un peu de recul par rapport aux coupables individuels et un schéma se dessine. Presque chaque facteur de ralentissement mentionné ci-dessus est une variante de la même chose : du code qui s’exécute sur l’appareil du visiteur à chaque visite, pour faire fonctionner une feature qui aurait pu être rendue une seule fois sur le serveur.

C’est le problème structurel du modèle surchargé d’apps. Une app qui génère une partie de votre page via son propre runtime doit charger ce runtime pour que le visiteur puisse voir le résultat. Un page builder qui rend des pages via le SDK d’une app ajoute son bundle à chaque page qu’il touche. La boutique paie une taxe à chaque visite pour le simple confort de l’éditeur.

Le code natif du thème n’a pas cette taxe. Lorsqu’une page est écrite en Liquid, CSS et HTML directement dans le thème, le serveur la rend exactement comme n’importe quelle autre page Shopify. Il n’y a pas de SDK d’app à télécharger, de layout à hydrater, ni de runtime de builder en compétition pour le main thread.

Notre test de vitesse des page builders Shopify montre comment mesurer cet écart sur votre propre boutique. L’écart est architectural, ce n’est pas une erreur de configuration que l’on peut corriger avec quelques réglages. Un runtime peut être allégé, mais il ne pèsera jamais zéro octet.

C’est exactement là que Fudge se positionne, et la raison pour laquelle nous l’avons construit ainsi. Vous décrivez la page, Fudge la rédige dans votre thème sous forme de code natif, et la page publiée a la même empreinte JavaScript que si un développeur l’avait codée à la main. Le plafond sur Lighthouse est fixé par votre thème, vos images et vos autres apps, pas par le builder. Fudge peut également lancer un audit de vitesse quand vous le souhaitez, trouver le code laissé par des apps désinstallées dans votre thème et préparer un nettoyage que vous n’aurez plus qu’à approuver.

À quoi ressemble une “bonne” performance, et comment y parvenir

Les objectifs concrets pour une page Shopify sur mobile, mesurés au 75e centile des utilisateurs réels :

• LCP inférieur à 2,5 s - l’image hero ou le titre s’affiche rapidement
• INP inférieur à 200 ms - les clics, menus et ajouts au panier semblent instantanés
• CLS inférieur à 0,1 - rien ne saute lorsque la page se stabilise
• Poids total de la page inférieur à 1,5 Mo, hors vidéo

La voie pour les atteindre de manière cohérente est moins exotique que la plupart des marchands ne le pensent. Dans l’ordre d’importance des rendements :

1. Auditez les applications. Désinstallez tout ce qui n’est utilisé que par une infime partie des visiteurs et vérifiez s’il ne reste pas des balises de script dans le thème après suppression. C’est généralement la victoire la plus importante.
2. Corrigez les médias hero. Formats modernes, bonnes tailles, bons attributs de chargement. Pas cher et très impactant sur le LCP.
3. Différez le JavaScript non critique et supprimez les scripts bloquant le rendu dans le <head>.
4. Réservez de l’espace pour les bannières, les images et les intégrations afin de tuer les décalages de mise en page (CLS).
5. Mesurez avec des données d’utilisateurs réels, et non avec un seul test Lighthouse. Un chargement synthétique peut s’éloigner de 30 % de la médiane. Utilisez les données de terrain du 75e centile issues du rapport sur l’expérience utilisateur Chrome (CrUX) ou de la Search Console comme source de vérité, et traitez Lighthouse comme un outil de dépistage relatif.

Le constat récurrent : la majeure partie du travail relève de la soustraction, pas de l’addition. Les boutiques les plus rapides ne sont pas celles avec le plus d’applications d’optimisation. Ce sont celles qui portent le moins de poids.

Perspectives : l’avenir des performances Shopify

Voici ce sur quoi je parierais pour l’année prochaine.

Le standard de base de la plateforme continue de s’élever, et l’écart avec la couche applicative se creuse. Le travail de Shopify côté serveur et CDN a rendu les fondations très solides. À mesure que la plateforme s’améliore, la part du score d’une boutique déterminée par le JavaScript tiers croît, au lieu de se réduire. La différence entre une boutique épurée et une boutique surchargée devient plus visible, et non moins.

L’INP reste la métrique qui sépare les bonnes boutiques des moyennes. Le LCP et le CLS sont de plus en plus résolus par les configurations par défaut et de meilleurs thèmes. L’INP dépend directement de la quantité de JavaScript exécutée sur le thread principal, et ça, c’est une décision du marchand. Les boutiques qui traitent chaque nouvelle installation d’application comme une décision de performance prendront de l’avance sur celles qui ne le font pas.

Le code natif devient l’attente par défaut pour l’édition de vitrine. Pour les boutiques qui font de l’acquisition payante, où les calculs de type Deloitte signifient que chaque 100 ms de LCP se traduit par un véritable ROAS,³ la question cesse d’être « quel éditeur est le plus facile » et devient « lequel n’ajoute rien à la page ». C’est un cadre différent de celui sur lequel la catégorie a été vendue il y a quelques années.

Le gros titre pour 2026 se maintient : Shopify vous donne une fondation rapide, et la plupart des boutiques dépensent cette avance en poids qu’elles n’avaient pas besoin de porter. La bonne nouvelle, c’est qu’il s’agit du problème le plus facile à corriger dans les performances e-commerce, car presque tout est sous votre contrôle.

FAQ