Shopify lent : pourquoi, et ce qu’on peut réellement y faire

Ce que Shopify gère, et ce qui dépend de vous

Shopify est une plateforme hébergée. Une partie du sujet « performance » vous échappe complètement — et c’est une bonne nouvelle. Une autre partie vous appartient entièrement, et c’est là que tout se joue.

Autrement dit : le temps de réponse serveur (TTFB) est rarement votre problème sur Shopify, sauf quand votre Liquid est réellement coûteux à rendre. Tout le reste — ce que le navigateur télécharge, analyse et exécute avant d’afficher quelque chose d’utile — dépend de décisions que vous, ou vos prestataires, avez prises.

C’est exactement la ligne que je suis sur mes missions Shopify : je ne cherche pas à « optimiser Shopify », je cherche ce que la boutique fait faire au navigateur du client, et pourquoi.

Les causes de lenteur que je retrouve le plus souvent

Les apps, et surtout celles qui ne sont plus là

C’est le premier poste, de loin. Chaque app qui s’intègre à la vitrine charge au minimum son propre JavaScript, souvent son CSS, parfois une bibliothèque complète. Trois apps qui embarquent chacune leur version de la même bibliothèque, et vous servez trois fois le même code.

Plus pernicieux : les résidus. Quand une app moderne s’installe via une extension de thème (app embed block ou app block dans une section), la désinstaller retire proprement son code. Mais pendant des années, les éditeurs ont demandé de coller un snippet dans theme.liquid ou dans un fichier du thème. Ce code-là ne part jamais tout seul. Sur les boutiques que je reprends, je trouve régulièrement des appels vers des domaines d’apps résiliées depuis longtemps : le navigateur tente la connexion, attend, échoue, parfois lève une erreur JavaScript qui bloque le reste du script sur la page.

Symptôme typique à surveiller : des erreurs 404 ou des échecs DNS dans l’onglet Réseau de la console, vers des domaines que vous ne reconnaissez pas.

Des sections qui coûtent cher

Un thème Online Store 2.0 bien construit est rapide. Ce sont les ajouts qui pèsent :

• Un carrousel plein écran en haut de la page d’accueil, avec trois à cinq images chargées d’un coup alors qu’une seule est visible.
• Une vidéo d’arrière-plan auto-hébergée, chargée avant même que la page soit lisible.
• Une section « produits recommandés » ou « collection en vedette » réglée sur trente ou cinquante produits, chacun avec ses variantes, ses images et ses badges.
• Des aperçus rapides (quick view) qui préchargent tout le contenu produit de la grille, au cas où.

Le Liquid qui travaille trop

Le rendu Liquid se fait côté Shopify, mais il n’est pas gratuit. Les boucles imbriquées, l’accès répété à des metafields dans une grille de produits, les recherches dans collections.all, les calculs faits produit par produit dans un template : tout cela allonge le temps de génération de la page. Shopify plafonne d’ailleurs les boucles for sur les collections et les produits (50 éléments par défaut) précisément pour éviter les dérives — quand on doit aller au-delà, c’est paginate qu’il faut utiliser, pas un contournement.

Les images

Shopify sert les images depuis son CDN et sait les redimensionner à la volée. Encore faut-il que le thème le lui demande. Une image de bannière téléversée en 4000 px de large et affichée sans filtre image_url avec une largeur explicite, c’est plusieurs mégaoctets pour rien. À l’inverse, l’image principale d’une page produit ou d’une bannière d’accueil ne doit pas être en chargement différé : c’est presque toujours l’élément LCP, et la mettre en loading="lazy" ajoute mécaniquement du retard.

Les polices

Les polices de la bibliothèque Shopify sont servies depuis le même domaine que le reste des ressources : pas de connexion supplémentaire à ouvrir. Dès qu’on passe à une police externe chargée depuis un autre domaine, on ajoute une résolution DNS, une négociation TLS et un risque de texte invisible pendant le chargement. Quand une police personnalisée est imposée par la charte, je l’héberge dans les fichiers du thème, en WOFF2, avec font-display: swap et un preload sur le seul fichier réellement utilisé au-dessus de la ligne de flottaison.

Les scripts tiers ajoutés à la main

Chat, bandeaux de consentement, tests A/B, gestionnaires de balises qui déclenchent eux-mêmes dix autres scripts. Ce sont souvent les plus lourds, et personne ne les compte parce qu’ils ne sont pas dans la facture des apps. Le sujet rejoint d’ailleurs celui du tracking e-commerce : un empilement de balises mal maîtrisé coûte à la fois en vitesse et en fiabilité des données.

Mesurer correctement : Core Web Vitals, tableau de bord Shopify, limites de Lighthouse

Avant de toucher au thème, il faut savoir ce qu’on cherche à améliorer. Trois indicateurs comptent, et ils ne se corrigent pas de la même façon.

LCP, INP, CLS

• LCP (Largest Contentful Paint) : le moment où le plus gros élément visible est affiché. Seuil : 2,5 secondes. Sur une boutique, c’est presque toujours l’image de bannière ou l’image produit principale. Les leviers : poids et dimensions de l’image, chargement prioritaire, absence de script bloquant avant elle.
• INP (Interaction to Next Paint) : le temps que met la page à réagir visuellement à une interaction. Seuil : 200 millisecondes. C’est l’indicateur du JavaScript en trop. Un tiroir de panier qui recalcule tout, des écouteurs d’événements posés par cinq apps sur le même bouton, une bibliothèque lourde qui occupe le fil principal : c’est là que ça se voit.
• CLS (Cumulative Layout Shift) : les décalages visuels après affichage. Seuil : 0,1. Sur Shopify, les coupables sont toujours les mêmes : bandeau de livraison offerte injecté après coup, pop-up d’app, bandeau de consentement, images sans attributs width et height, bascule de police.

Ces seuils s’évaluent au 75^e centile des visites réelles, pas sur un test isolé. Une page peut être excellente sur votre fibre et catastrophique sur un mobile en 4G dégradée — et c’est le second cas qui décide de votre chiffre d’affaires.

Le rapport Performance web de Shopify

Dans l’admin, Analyses > Rapports > Performance web affiche LCP, INP et CLS mesurés sur vos visiteurs réels, ventilés par type de page. C’est le tableau de bord que je regarde en premier, pour une raison simple : il répond à la seule question qui compte au début — quel type de page pose problème, et pour quelle proportion de visiteurs ? Une page d’accueil correcte et des pages produit en rouge, ce n’est pas le même chantier qu’une boutique lente partout.

Pourquoi Lighthouse ment (un peu)

Lighthouse et les scores qui en dérivent sont des mesures de laboratoire : un appareil mobile simulé, un réseau bridé, une seule exécution. Sur Shopify, plusieurs biais s’ajoutent :

• Le score est très variable d’une exécution à l’autre. Deux tests à cinq minutes d’intervalle peuvent différer de quinze points sans qu’on ait rien changé.
• Un test lancé depuis un lien de prévisualisation de thème ou en étant connecté comme membre du personnel ne charge pas exactement la même chose qu’un vrai visiteur.
• Certains scripts tiers réagissent aux outils automatisés et se comportent différemment.
• Le checkout n’est pas concerné : il est servi et optimisé par Shopify.
• Une boutique protégée par mot de passe ne produit pas de données de terrain exploitables.

Lighthouse reste utile pour identifier : la liste des ressources bloquantes, le détail du JavaScript inutilisé, l’élément LCP repéré. Mais comme juge de paix, il ne vaut rien face aux données de terrain. Je m’en sers comme d’un scanner, jamais comme d’un objectif. Je développe cette approche sur ma page optimisation de la performance.

Deux outils spécifiques à Shopify

L’extension Shopify Theme Inspector pour Chrome profile le temps de rendu Liquid, section par section : c’est le seul moyen simple de voir qu’une boucle produit consomme l’essentiel du temps serveur. Et shopify theme check, livré avec le Shopify CLI, signale en analyse statique les motifs Liquid coûteux, les filtres obsolètes et les ressources mal appelées. Les deux se lancent en quelques minutes et donnent des pistes autrement invisibles.

Nettoyer un thème Shopify sans rien casser

Un nettoyage de thème n’est pas un grand soir. C’est une suite de retraits, un par un, chacun vérifié. Voici l’ordre dans lequel je procède.

1. Travailler sur une copie, jamais sur le thème publié

Boutique en ligne > Thèmes > … > Dupliquer. C’est non négociable. Sur les projets où le code mérite d’être suivi dans le temps, je récupère le thème avec shopify theme pull et je le versionne avec Git : chaque retrait devient un commit, donc un retour en arrière possible.

2. Faire l’inventaire réel

Trois listes à croiser :

• Les apps installées dans l’admin, avec pour chacune la question : à quoi sert-elle encore, aujourd’hui, dans le parcours d’achat ?
• Les intégrations d’applications (app embeds) activées dans l’éditeur de thème : certaines restent allumées alors que l’app n’est plus utilisée.
• Le code du thème lui-même. Je cherche dans tous les fichiers les <script src=, les <link rel="stylesheet" vers des domaines externes, et les snippets au nom d’un éditeur d’app. theme.liquid et les fichiers de snippets/ concentrent l’essentiel.

3. Comparer avec le thème d’origine

C’est l’étape que presque personne ne fait, et c’est la plus rentable. Je télécharge une copie vierge de la même version du thème et je compare fichier par fichier. On voit alors immédiatement ce qui a été ajouté, par qui, et dans quel but — y compris les modifications faites en urgence un vendredi soir il y a trois ans.

4. Retirer, puis mesurer

Un retrait à la fois, avec un contrôle de la boutique après chacun : page d’accueil, collection, produit, ajout au panier, passage au checkout, sur mobile et sur ordinateur. Retirer cinq choses d’un coup et constater qu’un bouton ne fonctionne plus, c’est cinq hypothèses à tester au lieu d’une.

5. Traiter l’image LCP en priorité

Sur la plupart des boutiques, c’est le gain le plus rapide. Concrètement : appeler l’image avec image_url et une largeur adaptée, fournir un srcset et un sizes cohérents, poser width et height pour réserver la place, retirer le loading="lazy" sur cette image-là et ajouter fetchpriority="high". Un carrousel n’a besoin de charger que sa première diapositive.

6. Publier au bon moment

Jamais un vendredi, jamais pendant une campagne. On publie à une heure creuse, on garde l’ancien thème sous la main pour un retour arrière immédiat, et on surveille les commandes et les erreurs JavaScript dans les heures qui suivent. Si quelque chose se comporte mal, on republie l’ancien thème en un clic — c’est un des rares avantages structurels de Shopify, autant s’en servir.

Les erreurs qui font perdre du temps

• Installer une app d’optimisation de la vitesse. Elle ajoute un script pour compenser les effets d’autres scripts. Dans le meilleur des cas, elle différera du JavaScript qui n’aurait pas dû être là. Dans le pire, elle cassera une app de panier ou un pixel de conversion. Le problème n’est pas résolu, il est déplacé.
• Courir après un score. Passer de 42 à 58 sur Lighthouse ne veut rien dire si le LCP de terrain n’a pas bougé. Et l’inverse arrive aussi : un score modeste avec d’excellentes données réelles.
• Différer tout le JavaScript sans distinction. Ajouter defer partout casse en général le tiroir de panier, le sélecteur de variantes ou un pixel. Chaque script a ses dépendances.
• Supprimer des apps sans vérifier leurs traces. Désinstaller l’app ne retire pas le code collé à la main dans le thème. La facture baisse, pas le temps de chargement.
• Changer de thème en espérant que ça règle le problème. Un thème neuf est rapide le premier jour. Si on réinstalle les mêmes douze apps et qu’on recolle les mêmes scripts, on revient au point de départ en six mois — avec, en prime, tout le paramétrage à refaire.
• Optimiser avant de mesurer. C’est la plus coûteuse. On passe deux jours sur les images alors que le problème réel était un script de chat qui bloquait le rendu.

La méthode que je recommande

Elle tient en six étapes, et l’ordre compte plus que le détail.

1. Relever les données de terrain. Rapport Performance web de l’admin Shopify, par type de page. On note l’état de départ, on sait ce qu’on cherche à améliorer et pour quelles pages.
2. Établir la liste des vrais coupables. Onglet Réseau sur un profil mobile bridé, sans être connecté à l’admin. On trie par poids et par temps de blocage. On note les domaines inconnus.
3. Faire l’inventaire apps + code. Ce qui est utile, ce qui fait doublon, ce qui est résiduel. Cette liste vaut souvent une réduction d’abonnements en plus du gain de vitesse.
4. Nettoyer sur un thème dupliqué. Un retrait à la fois, avec contrôle du parcours d’achat complet après chacun.
5. Traiter l’image LCP et les polices. Ce sont les deux chantiers qui donnent le plus pour le moins d’effort, une fois le superflu retiré.
6. Publier, puis remesurer sur plusieurs semaines. Les données de terrain sont glissantes : elles mettent du temps à refléter un changement. Une lecture au bout de quelques jours n’est pas une conclusion.

Si la lenteur s’accompagne d’une conversion décevante, ne traitez pas les deux sujets comme un seul : la vitesse est une condition, pas une cause suffisante. J’en parle dans trafic sans ventes sur Shopify, et le travail de fond est décrit sur ma page optimisation de la conversion.

Et si vous ne savez pas par quel bout prendre le sujet, c’est précisément ce que fait le diagnostic e-commerce : mesurer, identifier ce qui pèse réellement, et vous rendre une liste ordonnée — pas une liste de bonnes pratiques génériques.

Checklist

• Relever LCP, INP et CLS par type de page dans Analyses > Rapports > Performance web avant toute modification.
• Analyser la page d’accueil et une page produit dans l’onglet Réseau, en profil mobile bridé et sans être connecté à l’admin.
• Lister les domaines externes appelés par la boutique et identifier ceux qui ne correspondent à aucune app active.
• Rechercher dans tout le thème les <script src= et les snippets laissés par des apps désinstallées.
• Vérifier les intégrations d’applications (app embeds) activées dans l’éditeur de thème.
• Comparer le thème publié avec une copie vierge de la même version pour repérer toutes les modifications.
• Vérifier que l’image LCP n’est pas en chargement différé et qu’elle est servie à la bonne largeur via image_url.
• Poser width et height sur les images et vérifier ce qui s’injecte après le chargement (bandeaux, pop-ups).
• Travailler sur un thème dupliqué, retirer un élément à la fois, tester le parcours d’achat complet après chaque retrait.
• Remesurer sur plusieurs semaines après publication, en gardant l’ancien thème disponible pour un retour arrière.

Questions fréquentes