Une application de devis ralentit-elle une boutique Shopify ? Ce qu'elle charge, mesuré

Une application de devis fait tourner trois choses sur une vitrine Shopify : une intégration d'application (app embed) qui charge son script et ses styles sur chaque page, des blocs d'application (app blocks) sur les pages où se trouvent le bouton ou l'affichage des prix, et des requêtes vers son propre serveur via le proxy d'application (app proxy). Qu'elle ralentisse une boutique dépend moins de la taille de l'application que de quatre comportements : si quelque chose bloque le rendu, combien de travail elle fait sur le thread principal, si elle lance des requêtes avant que la page soit utilisable, et si son bouton décale la mise en page en apparaissant.

Nous en avons mesuré une - QuotWay - comme Shopify mesure les applications pour son programme Built for Shopify : Lighthouse mobile sur la page d'accueil, une page produit et une page de collection, pondérées à 17 %, 40 % et 43 %, avec l'application activée puis désactivée. Sur 42 mesures, la médiane pondérée était de 82,0 avec l'application et de 80,7 sans - un écart plus petit que le bruit d'une mesure à l'autre, qui a atteint 17 points entre deux mesures de la même page. Le script de l'application a coûté de 28 à 63 ms de temps sur le thread principal par page et environ 37 Ko par page vue à froid. Le jeu de données complet est publié avec cet article.

Cette page expose ce qui s'exécute, comment Shopify le mesure, ce que nous avons mesuré et comment, les modes de chargement qui ont limité le coût, et une méthode pour mesurer vous-même n'importe quelle application. La méthode et la check-list sont neutres vis-à-vis des fournisseurs ; la mesure porte sur notre propre application, et elle est étiquetée comme telle.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 28 septembre 2026 ; les sources sont en fin de page.

Ce qu'une application de devis fait tourner sur une vitrine

Les extensions d'application de thème (theme app extensions) sont aujourd'hui la façon d'ajouter tout cela. Built for Shopify les exige pour les applications qui touchent à la boutique en ligne, et elles s'accompagnent d'une garantie qui compte pour la performance longtemps après le départ d'une application : « Lorsque les marchands désinstallent des applications, les blocs associés à ces applications sont automatiquement et entièrement supprimés des thèmes de la boutique en ligne. » Le code qu'une ancienne application a collé dans les fichiers du thème y reste jusqu'à ce que quelqu'un le supprime.

Shopify fixe aussi des limites de taille à ces extensions. Celles qui sont imposées sont larges - 10 Mo pour l'extension entière, 100 Ko de Liquid - mais deux sont seulement suggérées : 10 Ko de JavaScript compressé et 100 Ko de CSS compressé. Retenez le mot « suggérées » ; il revient dans la mesure.

Comment Shopify mesure l'impact d'une application

Pour le statut Built for Shopify, « votre application ne doit pas réduire le score de performance Lighthouse de la boutique de plus de dix points ». La méthode de Shopify, d'après sa page sur la performance des vitrines :

• Lighthouse mobile, sur un thème propre comme Horizon.
• Avant et après l'installation et la configuration de l'application.
• Trois pages, pondérées selon leur poids dans les ventes : accueil 17 %, produit 40 %, collection 43 %.
• La mise en garde de Shopify lui-même : « les scores Lighthouse peuvent varier d'une exécution à l'autre », donc faites la moyenne de plusieurs.

Cette pondération explique pourquoi un bouton sur la page produit compte davantage qu'une bannière sur la page d'accueil : les pages produit et collection font 83 % du score.

Le score de laboratoire ne dit pas tout. Le tableau de bord de performance web de Shopify rapporte les Core Web Vitals issus de visites réelles au 75e percentile - « bon » signifie un LCP inférieur ou égal à 2 500 ms, un INP inférieur ou égal à 200 ms et un CLS inférieur ou égal à 0,1 - avec jusqu'à 36 heures de délai. Un test de laboratoire vous dit ce que coûte une application dans des conditions contrôlées ; le tableau de bord vous dit ce que les acheteurs ont réellement eu.

Ce que nous avons mesuré

Observation QuotWay, 28 septembre 2026. Lighthouse 13.5.0, mobile, limitation simulée (150 ms d'aller-retour, 1,6 Mbit/s, CPU ralenti 4×), cache du navigateur vidé avant chaque mesure. Une boutique de développement Shopify sur le thème Savor avec d'autres applications installées - donc pas une boutique propre, mais la comparaison isole l'application : les mesures « désactivée » chargent le même HTML avec les trois fichiers de l'application et le chemin de son proxy d'application bloqués, si bien que la seule différence entre activée et désactivée est le code de l'application. Sept tours, activée et désactivée entrelacées, en alternant celle qui passait en premier.

<rect x="70" y="180" width="70" height="120" fill="#0f766e"/><line x1="105" y1="144" x2="105" y2="234" stroke="#1a1a2e" stroke-width="2"/><line x1="97" y1="144" x2="113" y2="144" stroke="#1a1a2e" stroke-width="2"/><line x1="97" y1="234" x2="113" y2="234" stroke="#1a1a2e" stroke-width="2"/><text x="105" y="288" text-anchor="middle" fill="#ffffff" font-weight="700">80</text>
<rect x="160" y="168" width="70" height="132" fill="#94a3b8"/><line x1="195" y1="162" x2="195" y2="210" stroke="#1a1a2e" stroke-width="2"/><line x1="187" y1="162" x2="203" y2="162" stroke="#1a1a2e" stroke-width="2"/><line x1="187" y1="210" x2="203" y2="210" stroke="#1a1a2e" stroke-width="2"/><text x="195" y="288" text-anchor="middle" fill="#1a1a2e" font-weight="700">82</text>
<text x="150" y="324" text-anchor="middle" font-weight="700" fill="#1b3a5c">Accueil (17 %)</text>

<rect x="340" y="150" width="70" height="150" fill="#0f766e"/><line x1="375" y1="126" x2="375" y2="204" stroke="#1a1a2e" stroke-width="2"/><line x1="367" y1="126" x2="383" y2="126" stroke="#1a1a2e" stroke-width="2"/><line x1="367" y1="204" x2="383" y2="204" stroke="#1a1a2e" stroke-width="2"/><text x="375" y="288" text-anchor="middle" fill="#ffffff" font-weight="700">85</text>
<rect x="430" y="168" width="70" height="132" fill="#94a3b8"/><line x1="465" y1="150" x2="465" y2="228" stroke="#1a1a2e" stroke-width="2"/><line x1="457" y1="150" x2="473" y2="150" stroke="#1a1a2e" stroke-width="2"/><line x1="457" y1="228" x2="473" y2="228" stroke="#1a1a2e" stroke-width="2"/><text x="465" y="288" text-anchor="middle" fill="#1a1a2e" font-weight="700">82</text>
<text x="420" y="324" text-anchor="middle" font-weight="700" fill="#1b3a5c">Produit (40 %)</text>

<rect x="610" y="180" width="70" height="120" fill="#0f766e"/><line x1="645" y1="156" x2="645" y2="216" stroke="#1a1a2e" stroke-width="2"/><line x1="637" y1="156" x2="653" y2="156" stroke="#1a1a2e" stroke-width="2"/><line x1="637" y1="216" x2="653" y2="216" stroke="#1a1a2e" stroke-width="2"/><text x="645" y="288" text-anchor="middle" fill="#ffffff" font-weight="700">80</text>
<rect x="700" y="186" width="70" height="114" fill="#94a3b8"/><line x1="735" y1="168" x2="735" y2="216" stroke="#1a1a2e" stroke-width="2"/><line x1="727" y1="168" x2="743" y2="168" stroke="#1a1a2e" stroke-width="2"/><line x1="727" y1="216" x2="743" y2="216" stroke="#1a1a2e" stroke-width="2"/><text x="735" y="288" text-anchor="middle" fill="#1a1a2e" font-weight="700">79</text>
<text x="690" y="324" text-anchor="middle" font-weight="700" fill="#1b3a5c">Collection (43 %)</text>

<rect x="250" y="350" width="14" height="14" fill="#0f766e"/><text x="270" y="361">Activée</text>
<rect x="340" y="350" width="14" height="14" fill="#94a3b8"/><text x="360" y="361">Désactivée (même HTML, app bloquée)</text>
<text x="640" y="361">Moustaches : extrêmes de 7 mesures</text>

Comment le lire. L'écart pondéré est de 1,3 point en faveur de l'application, et il ne signifie rien : au sein d'un même tour, l'écart activée moins désactivée sur une page est allé de −11 à +17. La lecture honnête est aucun effet mesurable sur le score Lighthouse dans cette configuration - et non que l'application rend une boutique plus rapide. Le seuil de dix points de Built for Shopify est bien au-delà de tout ce que ces données peuvent distinguer.

Ce que l'application a réellement coûté, d'après les mêmes mesures :

Le chiffre que nous préférerions ne pas publier. Le script pèse environ 31 Ko compressé - trois fois les 10 Ko suggérés par Shopify pour le JavaScript d'une extension d'application de thème. C'est une suggestion, pas une limite imposée, et dans ces mesures il n'a pas fait bouger le score, parce qu'il se charge sans bloquer et fait peu de travail tant qu'un acheteur n'ouvre pas le formulaire de devis. Il reste la cible évidente d'une réduction, et le build impose un budget de taille pour qu'il ne puisse pas grossir sans qu'on le remarque.

Les données brutes - les 42 mesures, avec les réglages - sont publiées dans storefront-lighthouse-2026-09-28.json.

Ce qui a limité le coût

Cinq modes de chargement expliquent le résultat, et toute application de vitrine peut être jugée à leur aune.

1. Rien sur le chemin critique. Le script est async et la feuille de style du panneau est injectée comme lien non bloquant. Un script ou une feuille de style qui bloque le rendu est la seule chose qui coûte à coup sûr des points sur chaque page, c'est pourquoi les recommandations de Shopify pour les thèmes disent de « supprimer les applications qui bloquent le rendu ».
2. La configuration dans le HTML, pas récupérée. Les réglages de l'application et les textes destinés à l'acheteur sont rendus dans la page en JSON par Liquid, si bien que le script les lit au lieu de les demander à un serveur. Avec un aller-retour de 150 ms, chaque requête évitée est du temps que l'acheteur n'attend pas.
3. Le travail à l'interaction. La configuration du formulaire de devis ne se charge que lorsqu'un acheteur l'ouvre pour la première fois. Les recommandations de Shopify disent la même chose : « Charger le JavaScript lors de l'interaction de l'utilisateur. »
4. Les données rendues côté serveur suppriment la dernière requête. Sur la page de collection, un bloc rend dans le HTML les données d'éligibilité de chaque fiche produit, et la requête disparaît ; sur les pages d'accueil et produit, dont les fiches n'avaient pas ce bloc, le script fait une requête et met la réponse en cache pendant cinq minutes. La mesure montre directement la différence.
5. Le bouton existe avant l'exécution du script. Le bouton de devis est rendu en Liquid, mis en forme par une petite feuille de style, et le script ne fait que le brancher - il n'apparaît donc pas d'un coup en poussant la page vers le bas. Le petit CLS de la page produit (0,039, bien en dessous du seuil « bon » de 0,1) est le prochain point à examiner.

Mesurer n'importe quelle application vous-même

La méthode ci-dessus fonctionne pour n'importe quelle application, y compris celle d'un concurrent, et ne demande aucun accès à son code.

1. Prenez les trois pages de Shopify sur la boutique où l'application est configurée : l'accueil, une page produit où l'application est active, une page de collection.
2. Trouvez les URL de l'application dans l'onglet réseau du navigateur - ses fichiers sur le CDN de Shopify (le dossier assets/ de l'extension) et le chemin de son proxy d'application sous le domaine de la boutique.
3. Lancez Lighthouse mobile deux fois par tour : une fois normalement, une fois avec ces URL bloquées (--blocked-url-patterns dans la CLI Lighthouse, une fois par motif). Même HTML, même boutique, même minute.
4. Faites au moins cinq tours, entrelacés, et comparez les médianes ; pondérez les pages 17/40/43. Une seule paire avant-après n'est pas une preuve - nos propres mesures ont varié jusqu'à 17 points sur la même page.
5. Lisez les diagnostics, pas seulement le score : ressources bloquant le rendu, la ligne de l'application dans « Temps d'exécution JavaScript », requêtes lancées avant l'interaction, et décalages de mise en page près des éléments de l'application.
6. Vérifiez ensuite les données de terrain dans le tableau de bord de performance web de Shopify quelques jours après un changement, parce que les scores de laboratoire n'incluent ni appareils réels ni acheteurs réels.

Pour un coup d'œil rapide sur une page, PageSpeed Insights utilise le même moteur Lighthouse ; pour une boutique de développement protégée par mot de passe, lancez la CLI Lighthouse dans un navigateur qui a déjà saisi le mot de passe de la vitrine.

Une check-list de l'empreinte sur la vitrine

• L'application utilise-t-elle une extension d'application de thème (intégration et blocs d'application), et non des script tags ou des fichiers de thème modifiés ?
• Son script est-il async ou defer, et une feuille de style bloque-t-elle le rendu ?
• Combien de Ko ajoute-t-elle par page, compressés, face aux 10 Ko suggérés par Shopify pour le JavaScript ?
• Quelles requêtes partent avant que l'acheteur n'interagisse, et ces données pourraient-elles être rendues dans la page à la place ?
• Son élément visible est-il rendu en Liquid, ou injecté par un script après le chargement ?
• Se charge-t-elle sur chaque page, ou seulement là où elle sert ?
• Que laisse-t-elle derrière elle à la désinstallation ? Avec les extensions d'application de thème, les blocs sont supprimés automatiquement.
• A-t-elle été mesurée comme Shopify mesure - et l'éditeur publie-t-il les chiffres ?

Le reste d'une évaluation d'application - traitement des données, versions d'API, application des règles - est dans comment évaluer une application Shopify B2B, et la revue de sécurité côté boutique est la check-list de revue de sécurité B2B.

Où se situe QuotWay

La mesure ci-dessus porte sur l'extension de vitrine de QuotWay : une intégration d'application sur chaque page, plus les blocs bouton de devis et bouton de panier que place le marchand, et des blocs facultatifs d'affichage des prix. Elle fonctionne sur tous les forfaits, y compris le forfait Lite gratuit - le détail des forfaits est sur la page des tarifs, et ce que QuotWay peut faire et ne peut pas faire liste les options de vitrine forfait par forfait. La façon dont la vitrine, la couche de devis et Shopify se répartissent le travail est dans ce qui reste dans Shopify et ce qui revient à la couche de devis.

Questions fréquentes

Les applications de devis ralentissent-elles une boutique Shopify ?

Elles le peuvent, mais la taille de l'application compte moins que sa façon de se charger. Un script ou une feuille de style qui bloque le rendu coûte des points sur chaque page ; un script async qui fait peu de chose tant qu'un acheteur n'interagit pas peut ne rien coûter de mesurable. Dans notre test de 42 mesures, l'effet d'une application de devis sur le score Lighthouse mobile pondéré était plus petit que l'écart entre deux mesures de la même page.

Comment Shopify mesure-t-il l'effet d'une application sur la vitesse de la boutique ?

Shopify lance Lighthouse sur mobile avant et après l'installation et la configuration de l'application, sur un thème propre, sur la page d'accueil, une page produit et une page de collection pondérées à 17 %, 40 % et 43 %. Pour le statut Built for Shopify, l'application ne doit pas réduire ce score de plus de dix points.

Comment vérifier la vitesse de ma boutique Shopify ?

Deux moyens, pour deux questions. PageSpeed Insights (ou la CLI Lighthouse) donne un score de laboratoire pour une page dans des conditions fixes - servez-vous-en pour comparer avant et après un changement. Le tableau de bord de performance web de Shopify affiche les Core Web Vitals issus de visites réelles au 75e percentile, avec jusqu'à 36 heures de délai - servez-vous-en pour voir ce que les acheteurs ont réellement vécu.

Quelle est la différence entre les script tags et les intégrations d'application ?

Les script tags injectent du JavaScript distant dans chaque page et, selon Shopify, « ne peuvent être utilisés qu'avec les thèmes vintage » ; les applications de l'App Store qui s'intègrent à un thème doivent utiliser à la place des extensions d'application de thème. Une intégration d'application fait partie d'une extension d'application de thème : le marchand peut l'activer ou la désactiver dans l'éditeur de thème, et elle est supprimée automatiquement quand l'application est désinstallée.

Désinstaller une application supprime-t-il son code de mon thème ?

Pour les applications construites avec des extensions d'application de thème, oui - Shopify indique que les blocs de l'application « sont automatiquement et entièrement supprimés des thèmes de la boutique en ligne ». Le code qu'une ancienne application a collé directement dans les fichiers du thème n'est pas supprimé et doit être trouvé et effacé à la main.

Quelle taille devrait avoir le JavaScript de vitrine d'une application ?

Shopify suggère 10 Ko compressés pour le JavaScript d'une extension d'application de thème. C'est une suggestion plutôt qu'une limite imposée, et le mode de chargement compte davantage que la taille : dans notre test, un script async de 31 Ko compressé n'a pas modifié le score de façon mesurable. Considérez la suggestion comme le budget à viser et la mesure comme le test.

Sources

Pages Shopify, lues le 28 septembre 2026 :

• Exigences Built for Shopify - la règle des dix points, les extensions d'application de thème, la suppression à la désinstallation
• Performance des vitrines pour les applications - la méthode avant-après, le mobile, les pondérations 17/40/43
• Configuration des extensions d'application de thème - limites de taille imposées et suggérées
• ScriptTag - thèmes vintage uniquement
• Bonnes pratiques de performance pour les thèmes - async et defer, applications bloquant le rendu, JavaScript à l'interaction
• Tableau de bord de performance web - Core Web Vitals de terrain et seuils

Notre mesure : 42 mesures Lighthouse le 28 septembre 2026, données et réglages dans storefront-lighthouse-2026-09-28.json. Le comportement de chargement de QuotWay est décrit d'après le code source de son extension.