Accueil › Blog › SEO
SEO

Shopify site speed : audit et correctifs réels

Audit de vitesse Shopify : ce que mesure vraiment le rapport de l'admin, les correctifs apps et thème qui paient, et ce que la plateforme verrouille.

Lionel Fenestraz · 21 septembre 2026 · 12 min de lecture · Mis à jour : septembre 2026
Un chronomètre à côté d'un portable affichant la mise en page d'une boutique
Dans cet article

Deux rapports de vitesse pour la même boutique, le même jour, avec des chiffres qui ne collent pas. Aucun n’est cassé. Le rapport de performance web de l’admin Shopify combine les données de ta page d’accueil, de ta page de produit la plus visitée et de ta page de collection la plus visitée des 7 derniers jours, collectées sur navigateurs Chromium et Firefox. Search Console, elle, tire de CrUX, qui ne mesure que Chrome, et uniquement les utilisateurs ayant accepté de partager ces données à l’installation du navigateur. Populations différentes, fenêtres différentes, chiffres différents.

La plupart des audits de vitesse qui arrivent chez moi ont mal commencé. Quelqu’un a vu un vilain chiffre dans l’admin, a paniqué, et la boutique installe depuis deux mois des applis d’optimisation pour le faire remonter. Je procède à l’envers : je décide quel chiffre fait autorité, je cherche ce qui le casse, et je finis presque toujours dans le code que les applis ont laissé dans le thème. Voici cet audit, avec une ligne nette entre ce que tu changes et ce que la plateforme décide à ta place.

En 30 secondes :

  • Le rapport de l’admin et celui de Search Console échantillonnent des populations de navigateurs différentes, donc ils ne coïncideront pas.
  • Google t’évalue sur les données de terrain CrUX, sur une fenêtre glissante de 28 jours, pas sur un score de labo.
  • Désinstaller une appli ne supprime pas son code du thème. C’est la documentation de Shopify qui le dit.
  • Un bon LCP, c’est 2,5 secondes, et un bon INP, 200 millisecondes, au 75e centile.
  • Le temps se gagne en retirant des scripts, pas en ajoutant des outils.

Le score de vitesse de l’admin Shopify mérite-t-il qu’on l’optimise ?

C’est une alarme incendie, pas un objectif. Le score affiché dans l’admin repose bien sur des données réelles : Shopify explique que le système utilise des données utilisateur réelles, appelées Real User Metrics ou RUM, provenant des visiteurs qui utilisent des navigateurs basés sur Chromium et Firefox. C’est mieux qu’une simulation. Le problème est ailleurs.

Ce jeu de données n’est pas celui que Google regarde. Search Console l’écrit noir sur blanc : les données du rapport Signaux web essentiels proviennent du rapport CrUX, qui recueille des métriques anonymisées auprès des utilisateurs réels qui visitent ton URL, ce qu’on appelle des données de terrain. CrUX, c’est Chrome, avec consentement, sur 28 jours. L’admin ajoute Firefox, Edge, Opera et Samsung Internet, et comprime la fenêtre à 7.

Le rapport de l’admin est-il inutile pour autant ? Pas du tout, je le consulte chaque semaine. Avec 7 jours de fenêtre, tu repères le mardi une régression installée le lundi, ce que CrUX ne dira pas avant longtemps. Ce que tu ne dois pas faire, c’est courir après ce chiffre comme si c’était ta note chez Google. Ce n’en est pas une. Si tu pars de zéro, mon guide des Core Web Vitals sur Shopify explique ce que chacune mesure.

Quelle source de données doit trancher quoi ?

Ma règle tient en une phrase : CrUX décide si tu as un problème, le labo décide lequel. Les outils de labo ne disent pas la vérité sur tes utilisateurs, mais ce sont les seuls à livrer la cascade de ressources avec les noms et les poids. Le terrain dit la vérité et n’explique jamais rien.

SourceNatureÉchantillonFenêtreÀ quoi elle sert
Rapport de l’adminTerrain (RUM)Chromium et Firefox7 joursRepérer vite une régression
Signaux web essentiels, Search ConsoleTerrain (CrUX)Chrome consentant28 joursVoir comment Google te note
PageSpeed Insights, bloc terrainTerrain (CrUX)Chrome consentant28 joursVérifier un gabarit
Lighthouse ou PSI, bloc laboLaboratoirePersonne de réelInstantanéNommer la ressource coupable

Les seuils, eux, sont les mêmes partout. Google indique que le LCP doit se produire dans les 2,5 secondes suivant le début du chargement, que les pages devraient afficher un INP de 200 millisecondes ou moins, et que tout se mesure au 75e centile des chargements, séparément sur mobile et sur ordinateur. Le 75e centile, ça veut dire que ton visiteur médian ne compte pas. Celui qui souffre, si.

Pourquoi les applis coûtent-elles autant de vitesse sur Shopify ?

Parce que leur code survit à la désinstallation. Shopify le dit sans détour : la désinstallation d’une appli ne supprime pas automatiquement son code de ton thème, et la même page demande d’évaluer les applis installées et le code tiers pour vérifier qu’ils apportent assez de valeur pour compenser la perte de performance.

Traduit en ce que je trouve sur une boutique de trois ans : le script d’un guide des tailles retiré en 2024, deux widgets d’avis parce qu’on a changé de prestataire sans nettoyer, et un gestionnaire de balises qui traîne les pixels de l’agence précédente. Rien de tout ça n’apparaît dans la liste des applis. Tout ça s’exécute à chaque chargement.

La documentation thèmes est tout aussi directe. Elle demande d’identifier et de supprimer ou différer les scripts d’applis qui bloquent l’analyse du HTML avant tout rendu de contenu, et d’auditer tout ce qui se charge en retirant ce qui ne mérite pas son coût. Ce « ne le mérite pas », c’est la partie difficile : chaque appli a dans l’entreprise quelqu’un qui la défend.

Pour démêler ça, je duplique le thème, je retire un bloc à la fois, et je mesure. Jamais tous d’un coup. C’est lent et c’est la seule façon d’attribuer le gain. Si tu traînes aussi des soucis de gabarit, mon tour d’horizon des erreurs SEO courantes sur Shopify recoupe cette liste.

Quels problèmes de thème peux-tu corriger toi-même ?

Ceux qui touchent à la façon dont l’image principale est découverte et peinte, et sur une fiche c’est presque toujours l’élément LCP. Les règles de Shopify sont ici concrètes, et pas besoin d’être développeur pour les appliquer.

  • Ne charge jamais l’image LCP en lazy loading. Shopify prévient que loading="lazy" sur l’image LCP la retarde jusqu’à la fin du layout. C’est l’erreur la plus coûteuse et la plus facile, parce que le réglage s’applique souvent d’un bloc à tout le thème.
  • Utilise <img> plutôt qu’une image de fond CSS pour le héros, afin que le scanner de préchargement la découvre tôt.
  • Applique fetchpriority="high" à l’image LCP pour signaler son importance avant que le navigateur ne termine le layout.
  • Mets toujours width et height, ou utilise image_tag qui les ajoute seul, et génère les URL avec image_url plutôt qu’à la main.

Viennent ensuite les blocages de rendu. La même page signale que les feuilles de style et les scripts bloquants placés dans le <head> sont la raison habituelle d’un LCP tardif, et recommande de charger de façon synchrone le seul CSS critique de la fenêtre initiale. Pas de tout différer : de décider ce qui entre dans le premier écran.

Et puis il y a Liquid, là où se cache le temps serveur. Shopify demande d’éliminer les schémas en O(n²), boucles imbriquées et accès aux metafields dans les boucles compris, qui font croître le temps de rendu de façon quadratique, et de garder la pagination sous 25 000 objets. Sur une grosse collection, une boucle imbriquée mal placée pèse plus lourd que toutes tes images réunies. Pour le code, j’ai écrit sur Liquid appliqué au SEO et sur l’optimisation des images.

Dans quel ordre je mène l’audit ?

Toujours le même, et toujours en mesurant avant de toucher à quoi que ce soit. L’ordre n’a rien de décoratif : chaque étape élimine des hypothèses pour la suivante, et en sauter une t’amène à optimiser ce qui n’était pas le problème.

  1. Note l’état de départ dans les deux sources terrain. Admin et Search Console, le même jour, captures comprises. Sans référence, tu n’as pas un audit, tu as des avis.
  2. Sépare par gabarit. Accueil, collection et fiche ont des problèmes distincts et partagent rarement le même coupable. Un mauvais LCP seulement sur les fiches désigne la galerie.
  3. Identifie le vrai élément LCP sur le pire gabarit, avec l’onglet performance du navigateur. Ne le devine pas. Sur une demi-douzaine de boutiques, ce n’était pas l’image que tout le monde croyait.
  4. Liste tout ce qui s’exécute avant cette peinture : scripts dans le <head>, blocs d’applis intégrés, conteneurs de balises, polices personnalisées.
  5. Croise cette liste avec les applis installées. Ce qui s’exécute sans correspondre à aucune appli active est un résidu de désinstallation, et c’est le meilleur rapport effort/résultat de l’audit.
  6. Duplique le thème et retire un élément à la fois, en mesurant en labo après chaque changement.
  7. Vérifie les règles d’image : pas de lazy loading sur le héros, fetchpriority sur la LCP, dimensions déclarées, image_url partout.
  8. Traque les boucles imbriquées et les accès aux metafields dans les boucles dans les sections qui affichent de longues listes.
  9. Publie et attends. CrUX bouge sur 28 jours, donc la confirmation n’arrivera pas en 48 heures, quelle que soit ton impatience.

L’étape 9 est celle que personne ne supporte. Le travail est fait, quelqu’un ouvre Search Console le lendemain, rien n’a bougé, et la conclusion tombe : ça n’a servi à rien. C’est à ça que sert le rapport de l’admin.

Qu’est-ce que tu ne corrigeras jamais ?

Plus de choses que tu ne voudrais, et le savoir fait gagner des semaines. Le rendu Liquid se fait sur les serveurs de Shopify, les images sont livrées par leur CDN, et le checkout ne vit pas dans ton thème. Tu peux écrire du Liquid moins cher. Pas changer où il s’exécute. Le conseil de garder la pagination sous 25 000 objets est une limite de plateforme déguisée en bonne pratique.

Il y a aussi des scripts que tu n’auras pas le droit de retirer, pour des raisons qui ne sont pas techniques : le pixel d’un canal que le client facture, l’outil d’accessibilité exigé par le juridique, le chat du service client. Là, il reste à négocier quand ils se chargent plutôt que s’ils se chargent, en les sortant du chemin critique du premier rendu.

Mon critère pour clore un audit : si le LCP passe sous le seuil sur les gabarits qui rapportent et que l’INP ne s’envole pas à l’ouverture du sélecteur de variantes, j’ai fini. Courir après les dixièmes rapporte plus ailleurs, en général sur l’expérience d’achat mobile, qui est un problème de conversion et non de millisecondes. J’en parle dans le CRO mobile pour l’e-commerce.

Questions fréquentes

Pourquoi mon score dans l’admin Shopify ne correspond-il pas à PageSpeed Insights ?

Parce qu’ils ne mesurent pas la même chose. L’admin utilise des données réelles issues de Chromium et Firefox sur les 7 derniers jours. Le bloc terrain de PageSpeed Insights s’appuie sur CrUX, qui ne couvre que Chrome et uniquement les utilisateurs consentants, sur 28 jours. Avec des échantillons et des périodes différents, une correspondance exacte serait suspecte.

Quels seuils Core Web Vitals dois-je atteindre ?

Un LCP dans les 2,5 secondes, un INP de 200 millisecondes ou moins, un CLS sous 0,1. Tout se juge au 75e centile des chargements, séparément sur mobile et sur ordinateur. Shopify en donne une lecture pratique : au moins 75 % de tes chargements doivent obtenir un bon score sur les trois métriques pour qu’un moteur de recherche juge ta performance bonne.

Les applis d’optimisation de vitesse du App Store valent-elles le coup ?

Ça dépend de ce qu’il y a en dessous, mais ma réponse par défaut est de ne pas commencer par là. Une appli de plus, c’est un script de plus à chaque chargement, et c’est justement le problème que tu cherches à résoudre. Nettoie d’abord les résidus des anciennes applis et corrige les règles d’image. S’il reste de la marge, évalue les outils.

Combien de temps avant qu’une amélioration se voie ?

En labo, immédiatement. Dans Search Console, des semaines, parce que CrUX travaille sur une fenêtre glissante de 28 jours et doit accumuler assez de nouveaux chargements. Le rapport de l’admin, avec ses 7 jours, te confirme le premier que tu vas dans le bon sens. Ne décide rien sur une seule journée de données.

Un thème payant règle-t-il le problème de vitesse ?

Pas toujours, et dans la plupart des cas il ne règle que le point de départ. Un thème bien construit offre un meilleur démarrage, mais la dégradation arrive après, avec les applis, les pixels et les sections empilées pendant deux ans. J’ai vu des thèmes payants au LCP pire que des thèmes gratuits restés propres. L’entretien pèse plus que l’achat.

La vitesse se gagne en retirant

Après un bon nombre d’audits, ma conclusion manque de panache : presque tout le temps récupérable était déjà dans la boutique, sous forme de code que quelqu’un a installé et que personne n’a retiré. Aucune technique avancée là-dedans. Un inventaire, de la patience, et l’envie de discuter avec celui qui défend une appli inutilisée depuis un an.

L’autre chose apprise à la dure : n’optimise pas contre un chiffre qui n’est pas celui qui te note. Le rapport de l’admin est un bon détecteur de fumée parce qu’il réagit en quelques jours. Celui de Search Console reflète ce que Google voit, avec son échantillon Chrome et ses 28 jours. Les confondre mène à fêter des progrès qui n’ont pas eu lieu. Si le reste attend encore, mon guide SEO pour Shopify donne l’ordre à suivre.

Si tu veux que je regarde ta boutique et que je te dise ce qui peut sortir sans rien casser, réserve 30 minutes de consulting.

Lionel Fenestraz — Consultant Google Ads & Meta Ads Freelance
Lionel Fenestraz
Consultant PPC & CRO Freelance · Google Partner · CXL Certified · Google Ads Search Certified
Plus de 7 ans à gérer des campagnes Google Ads et Meta Ads pour des marques de location saisonnière, B2B et ecommerce. Trilingue ES/EN/FR.
Premier appel gratuit

Vos campagnes publicitaires
pourraient-elles mieux performer ?

30 minutes pour analyser votre situation et vous dire exactement ce que je changerais. Sans pitch, sans proposition commerciale.

Réserver un appel →
30 min · Google Meet · Sans engagement