Tu installes une app Shopify en deux clics. Avis clients, popup de réduction, chat support. Chacune promet de t’aider à vendre plus. Et chacune dépose, sans rien te dire, un bout de JavaScript sur toutes tes pages.
Tu ne le vois pas dans l’admin. Tu le payes sur le terrain, à chaque visite mobile. Un site qui rame, c’est un client qui part avant même de voir ton produit. Akamai mesurait déjà en 2017 qu’un délai de 100 ms sur le temps de chargement faisait baisser les conversions, et Deloitte chiffrait en 2020 l’impact de 0,1 seconde gagnée sur le chiffre d’affaires retail. Les apps font partie de cette dette invisible.
Si tu n’as pas lu mon article sur INP, lis-le d’abord, il pose le cadre Core Web Vitals. Ici je vais plus loin : comment isoler le coût de chaque app, une par une, et décider laquelle tu gardes et laquelle tu vires.
L’idée n’est pas de tout supprimer. Certaines apps rapportent largement plus que ce qu’elles coûtent en performance. D’autres ralentissent ton site pour une fonctionnalité que personne n’utilise. Le but, c’est de savoir laquelle est dans quel camp. Avec des chiffres, pas au feeling.
Tu vas voir une méthode simple, une matrice de décision, les trois familles d’apps qui plombent le plus, un cas client réel, et un audit que tu peux faire toi-même en 30 minutes.
Le coût invisible des apps Shopify
Quand tu installes une app, elle ne se contente pas d’ajouter un bouton. Dans la majorité des cas, elle injecte un script externe dans ton thème. Ce script vit sur un serveur qui n’est pas le tien, souvent à l’autre bout du monde, sur une infrastructure que tu ne contrôles pas.
Résultat, à chaque chargement de page, le navigateur de ton visiteur doit faire plusieurs choses avant même d’afficher quoi que ce soit. Une résolution DNS pour trouver le domaine de l’app. Une connexion TLS pour sécuriser l’échange. Le téléchargement du fichier JavaScript. Puis son exécution sur le fil principal du navigateur.
Chacune de ces étapes a un coût en millisecondes. La résolution DNS oblige le navigateur à demander à un serveur distant l’adresse réelle du domaine de l’app, ce qui peut prendre de quelques dizaines à quelques centaines de millisecondes selon la latence réseau. La connexion TLS ajoute ensuite un échange de clés et de certificats avant que le moindre octet utile ne circule. Sur mobile, en 4G, ces allers-retours s’additionnent vite et se font sentir.
Quand le fichier arrive enfin, il faut encore le télécharger en entier, puis le parser et le compiler avant exécution. Un script d’app de plusieurs centaines de kilo-octets, ce n’est pas juste un transfert : c’est aussi du travail de décodage pour le moteur JavaScript. Et chaque domaine externe supplémentaire relance tout le cycle DNS et TLS depuis zéro, parce que la connexion à un serveur ne sert pas à joindre un autre.
Cette exécution est le point le plus douloureux. Le fil principal ne fait qu’une chose à la fois. Pendant qu’il traite le script d’une app, il ne peut pas répondre aux clics ni afficher le contenu. C’est exactement ce que mesure l’INP, la réactivité de ta page aux interactions, détaillée par Google sur web.dev.
Le détail qui aggrave tout, c’est que ces scripts s’exécutent en bloc, sans laisser respirer le navigateur. Une longue tâche JavaScript qui occupe le fil principal pendant plusieurs centaines de millisecondes gèle l’interface entière pendant ce temps. Le visiteur tape sur un bouton, rien ne répond, il retape, il s’agace. Ce blocage est invisible pour toi qui testes depuis un ordinateur puissant, mais bien réel sur le smartphone d’entrée de gamme de ton client.
Concrètement, les apps touchent plusieurs Core Web Vitals à la fois. Le LCP, parce que le navigateur est occupé à charger des scripts au lieu d’afficher ton image produit. L’INP, parce que le fil principal reste bloqué quand le visiteur clique. Le CLS, quand une bannière ou un widget apparaît tardivement et décale la mise en page.
Le pire, c’est que beaucoup d’apps chargent du code sur toutes tes pages, même là où elles ne servent à rien. Une app d’avis produits qui se charge sur ta page panier. Un popup marketing qui s’exécute sur ta page de confirmation de commande. Du travail pur pour le navigateur, zéro bénéfice pour le visiteur.
Pour voir l’ampleur du problème, ouvre Chrome DevTools et utilise l’onglet Coverage. Il te montre, page par page, quelle part du JavaScript chargé est réellement exécutée et quelle part dort. L’onglet Network te montre de son côté chaque domaine externe sollicité et le poids transféré, et l’onglet Performance révèle les longues tâches qui bloquent le fil principal. La documentation de Google sur la performance et l’INP est un bon point de départ pour comprendre la lecture de ces mesures, sur web.dev. Tu seras souvent surpris par la quantité de code chargé pour rien.
L’objectif n’est pas de diaboliser les apps. C’est de rendre visible ce qui était invisible, pour pouvoir décider en connaissance de cause.
La matrice de décision
Une fois que tu sais qu’une app a un coût, la vraie question devient simple. Est-ce que ce qu’elle t’apporte vaut ce qu’elle te coûte ? Pour répondre sans te perdre, croise deux axes : la valeur business de l’app et son coût en performance.
| | Coût perf BAS | Coût perf HAUT | |------------------|---------------|----------------| | Valeur HAUTE | Garde | Optimise | | Valeur BASSE | Garde ou OK | Supprime |
Valeur haute, coût bas. C’est la case rêvée, en haut à gauche. L’app rapporte et ne ralentit presque rien. Un exemple typique, une app de paiement bien intégrée qui s’appuie sur l’infrastructure native de Shopify, ou un outil analytics léger chargé en arrière-plan. Tu gardes, tu ne touches à rien, et tu passes ton énergie ailleurs. Ces apps sont rares mais elles existent, et il faut savoir les reconnaître pour ne pas perdre de temps à les optimiser inutilement.
Valeur haute, coût haut. Le cas tendu, en haut à droite. L’app est utile, voire indispensable, mais elle pèse lourd. Une app d’avis clients qui booste vraiment ta conversion entre dans cette case. La tentation serait de la supprimer pour gagner en vitesse, mais tu perdrais alors une vraie source de revenus. La bonne réponse, c’est l’optimisation : chargement différé, exécution seulement sur les pages produit, suppression des fonctionnalités annexes que tu n’utilises pas. Tu gardes le bénéfice, tu rabotes le coût.
Valeur basse, coût bas. Zone grise, en bas à gauche. L’app ne sert pas à grand-chose mais elle ne fait pas de mal non plus. Tu peux la garder par confort ou la désinstaller pour simplifier ta stack. Pas d’urgence, mais un bon ménage de printemps ne fait jamais de mal, parce que chaque app installée reste une dépendance de plus à surveiller, à mettre à jour et à payer.
Valeur basse, coût haut. La candidate à la suppression immédiate, en bas à droite. Une fonctionnalité que personne n’utilise et qui ralentit tout le monde. C’est là que tu récupères le plus de performance pour le moins d’effort. Aucun arbitrage à faire, aucun revenu à protéger : tu vires sans hésiter, et tu sens souvent la différence dès le test suivant.
Le seul moyen fiable de placer une app dans la bonne case, c’est de mesurer. Le ressenti se trompe presque toujours, parce qu’une app discrète à l’écran peut être un monstre de JavaScript en coulisses, et inversement. Voici la méthode, valable pour n’importe quelle app.
Lance d’abord PageSpeed Insights sur une page représentative, en notant les valeurs mobiles de LCP, INP et CLS. C’est ta baseline. Désactive ensuite l’app que tu veux tester, depuis ton thème ou via l’app elle-même. Relance PageSpeed Insights sur la même page, dans les mêmes conditions.
La différence entre les deux mesures, c’est le coût réel de l’app. Pas une estimation, pas un ressenti. Un chiffre. Si désactiver une app fait gagner une seconde de LCP sur mobile, tu sais exactement ce qu’elle te coûtait. Et tu sais ce que tu récupères en la traitant.
Attention à un détail : les données terrain de PageSpeed, issues de CrUX, reflètent les 28 derniers jours de vrais visiteurs. Pour un test rapide, fie-toi surtout aux mesures en laboratoire qui réagissent immédiatement à ton changement.
Les 3 catégories d’apps qui plombent le plus
Au fil des audits, trois familles reviennent presque systématiquement en tête des coupables. Elles ont un point commun : elles chargent du JavaScript lourd, souvent sur toutes les pages, pour une fonctionnalité qui pourrait être bien plus légère.
Les apps d’avis clients
Loox, Judge.me, Yotpo, Stamped, Okendo. Les avis clients sont précieux pour la conversion, personne ne dit le contraire. Le problème, c’est leur poids.
Ces apps chargent souvent leurs scripts, leurs polices et leurs images sur l’ensemble du site, alors que les avis ne servent que sur les pages produit. Elles affichent aussi des carrousels et des étoiles qui se rendent tardivement, ce qui provoque du décalage de mise en page et plombe ton CLS.
Les symptômes sont reconnaissables. Tu vois apparaître les étoiles de notation une fraction de seconde après le reste de la fiche produit, et le texte en dessous saute vers le bas au moment où le widget s’installe. Sur ta page panier ou ta page de contact, le profileur Network montre des requêtes vers le domaine de l’app alors qu’aucun avis n’est affiché. C’est du chargement à vide, payé par tous les visiteurs.
La solution n’est pas de supprimer les avis. C’est de les contenir. Charge le widget uniquement sur les pages produit, en conditionnant l’injection du script au type de template. Réserve un espace fixe pour le bloc d’avis avec une hauteur minimale en CSS, afin que la zone ne saute plus quand le contenu arrive. Et si l’app propose une version allégée ou un mode de chargement différé, active-le. Tu gardes la preuve sociale, tu perds le surpoids.
Les popups marketing
Privy, OptiMonk, Justuno, Wisepops. Le popup qui capture des emails ou propose une réduction. Utile pour la liste de diffusion, mais souvent désastreux pour l’expérience.
Ces apps s’exécutent sur toutes les pages, dès le chargement, pour pouvoir déclencher leur popup au bon moment. Elles surveillent en permanence le comportement du visiteur, ce qui occupe le fil principal. Et le popup lui-même, en surgissant, peut décaler le contenu et nuire à l’INP au moment où le visiteur veut justement cliquer.
Les symptômes typiques : un défilement qui accroche légèrement parce que des écouteurs d’événements tournent en boucle pour détecter l’intention de sortie, et une overlay qui s’affiche pendant que le visiteur est déjà en train d’interagir avec la page. Dans l’onglet Performance, tu repères ces longues tâches récurrentes liées au suivi du comportement, qui n’apportent rien tant que le popup n’est pas déclenché.
L’approche saine, c’est de différer leur chargement après l’affichage du contenu principal. Concrètement, tu retardes l’initialisation du script de quelques secondes ou jusqu’au premier défilement, parce que le visiteur n’a pas besoin de voir un popup dans la première seconde, il a besoin de voir ton produit. Limite aussi le nombre de scénarios actifs. Un popup bien réglé suffit, dix règles concurrentes ne font qu’alourdir la page et se marcher dessus.
Les widgets de chat
Tidio, Crisp, Intercom, Gorgias. Le petit bouton de chat en bas à droite. Rassurant pour le support, mais c’est l’un des plus gros consommateurs de JavaScript du lot.
Un widget de chat charge fréquemment une interface complète, des dépendances et parfois une connexion temps réel, le tout dès l’ouverture de la page. Pour un bouton sur lequel la grande majorité des visiteurs ne cliquera jamais. C’est typiquement de la valeur potentiellement haute mais au coût très élevé si rien n’est fait.
Le symptôme le plus parlant, c’est dans l’onglet Network : tu vois plusieurs centaines de kilo-octets se télécharger juste pour afficher une bulle, plus une connexion qui reste ouverte en arrière-plan. Sur un mobile modeste, ce poids retarde directement le moment où ta page devient pleinement interactive, alors que le bouton de chat reste inutilisé dans l’immense majorité des sessions.
La bonne pratique consiste à charger le widget seulement à l’interaction. Tu affiches un simple bouton léger, une image ou un élément HTML statique, et le vrai script du chat ne se télécharge que lorsque le visiteur clique dessus. La plupart de ces outils proposent désormais ce mode de chargement à la demande dans leurs réglages. Le support reste disponible, sans pénaliser les 95 % qui ne l’ouvriront pas.
Cas concret : Mabonatur, boutique Shopify espagnole, +42% sur mobile
Mabonatur est une boutique Shopify espagnole dans le secteur de la santé naturelle. Quand on a commencé à travailler ensemble, le constat était clair côté mobile : les Core Web Vitals étaient en échec et l’expérience traînait sur smartphone.
La cause n’était jamais un seul gros problème. C’était une accumulation. Une stack d’apps qui s’étaient empilées au fil des mois, un thème chargé d’options, et un mobile qui en payait le prix. Le genre de situation où chaque brique semble justifiée prise isolément, mais où l’addition devient insupportable pour le navigateur.
Le diagnostic a commencé par un inventaire complet de la stack apps, passé au crible de la matrice valeur contre coût décrite plus haut. App par app, on a mesuré la baseline, désactivé, re-mesuré. Certaines apps utiles ont été conservées et optimisées. D’autres, à faible valeur et coût élevé, ont été retirées.
Cette discipline du test isolé a été décisive. En désactivant une app à la fois plutôt que tout d’un coup, on a pu attribuer chaque gain à une cause précise, sans confondre les effets. C’est ce qui a permis de garder ce qui rapportait vraiment et de couper net ce qui ne servait à personne, sans débat ni intuition hasardeuse.
Le travail a aussi porté sur le thème lui-même. Optimisation du chargement des polices pour éviter qu’elles ne bloquent l’affichage du texte. Correctif sur un carrousel qui provoquait du décalage de mise en page et faisait grimper le CLS. Mise en place de lazy loading sur les widgets non critiques, pour qu’ils ne se chargent qu’au moment utile plutôt qu’au démarrage.
En parallèle, un travail de refonte sur le SEO technique a accompagné l’optimisation des performances. Les deux vont de pair : un site plus rapide est aussi un site mieux exploré et mieux indexé.
Le résultat publié pour ce projet, c’est une amélioration de +42% sur mobile. Pas en ajoutant des choses, mais en mesurant, en triant et en allégeant. C’est toute la logique de cet article appliquée à un cas réel.
Si tu veux voir le détail du projet, c’est ici : Voir le cas Mabonatur sur mon portfolio.
Audit DIY de ta stack apps en 30 minutes
Tu n’as pas besoin d’attendre un audit complet pour avancer. Voici une démarche que tu peux faire seul, sur ta propre boutique, avec juste un navigateur et un peu de méthode.
Lister toutes tes apps
Va dans ton admin Shopify, section Apps. Note chaque app installée, même celles dont tu as oublié l’existence. Tu seras souvent surpris d’en trouver une ou deux que tu ne reconnais plus. Cette liste est ta base de travail.
Te poser la question pour chaque app
Pour chaque app, demande-toi honnêtement ce qu’elle t’apporte. Une vente mesurable, un gain de temps réel, ou juste une habitude. Si tu ne sais pas répondre, c’est déjà un signal. Place-la mentalement dans la matrice valeur contre coût.
Mesurer la baseline PageSpeed Insights
Lance PageSpeed Insights sur une page produit et sur ta page d’accueil. Note les valeurs mobiles de LCP, INP et CLS. C’est ton point de référence avant toute modification. Garde une capture, tu vas comparer.
Désactiver les apps candidates
Commence par les apps à faible valeur que tu as repérées. Désactive-les une par une, jamais toutes en même temps, sinon tu ne sauras pas laquelle change quoi. Procède sur un thème de test ou en dehors des heures de pointe.
Re-mesurer après chaque désactivation
Après chaque app désactivée, relance PageSpeed Insights sur les mêmes pages, dans les mêmes conditions. La différence avec ta baseline te donne le coût réel de cette app précise. Note tout dans un tableau simple.
Décider
Avec tes chiffres en main, tranche. Tu supprimes les apps à faible valeur et coût élevé. Tu optimises celles qui sont utiles mais lourdes. Tu gardes le reste. Tu viens de transformer un ressenti flou en décisions chiffrées.
En une demi-heure, tu passes d’un site dont tu subis la lenteur à un site dont tu comprends la lenteur. Et comprendre, c’est déjà la moitié du travail.
Apps : moins, mieux, mesure
Tes apps Shopify ne sont ni bonnes ni mauvaises en soi. Elles ont un coût, et ce coût se mesure. La seule erreur, c’est de les empiler sans jamais regarder ce qu’elles font à ta vitesse mobile.
Moins d’apps, mieux choisies, et chaque décision appuyée sur un chiffre. C’est la différence entre un site qui rame en silence et un site qui convertit. Si tu veux d’abord cadrer ta démarche autour des Core Web Vitals, repasse par mon article sur INP. Et si tu hésites à faire ce travail seul ou à le déléguer, j’ai écrit un guide dédié sur l’audit Shopify en DIY ou avec un expert pour t’aider à choisir.
