Pourquoi c'est important pour votre boutique
60–80%
du temps d'exécution des scripts provient des applications tierces
3+ sec
de retard dû aux scripts d'applications sur une boutique typique
7%
de baisse de conversion par 1 seconde de retard
La solution facile : l'optimisation automatique des scripts
Les scripts tiers sont le problème de vitesse le plus difficile à résoudre manuellement — vous ne pouvez pas modifier le code des applications, et un report naïf casse leur fonctionnement. Thunder Page Speed Optimizer a été conçu spécifiquement pour résoudre ce problème.
Ce que Thunder fait avec vos scripts d'applications :
Report intelligent des scripts
Diffère les scripts tiers tout en préservant l'ordre d'exécution et les dépendances
Cartographie des dépendances
Comprend quels scripts dépendent les uns des autres — ne cassera pas vos applications
Rapport d'impact par application
Montre exactement combien de millisecondes chaque application ajoute au chargement de votre page
S'adapte automatiquement aux changements
Nouvelle application installée ? Thème mis à jour ? Thunder s'adapte automatiquement
Amélioration moyenne : +27 points PageSpeed
Les boutiques avec beaucoup d'applications voient les plus gros gains — souvent des temps de chargement 20-60 % plus rapides. Note de 4.6★ · Plus de 20,000 boutiques.
Plan gratuit disponible · Aucune carte bancaire requise · Configuration en 30 secondes · Compatible avec tous les thèmes
1. Que sont les scripts tiers (et pourquoi devriez-vous vous en soucier) ?
Chaque fois que vous installez une application depuis l'App Store de Shopify, cette application a besoin d'un moyen d'afficher ses fonctionnalités sur votre vitrine. Un widget d'avis doit afficher des étoiles. Une application de chat doit montrer une bulle de discussion. Un popup d'email doit... eh bien, apparaître.
Pour cela, chaque application injecte des fichiers JavaScript (scripts) dans le HTML de votre boutique. On les appelle « scripts tiers » parce qu'ils proviennent de serveurs externes — pas de l'infrastructure de Shopify ni du code de votre thème.
Voici le problème : le navigateur de votre visiteur doit télécharger, analyser et exécuter chacun de ces scripts avant de pouvoir finir de charger la page. Et contrairement au code de votre thème, que Shopify a optimisé et sert depuis son CDN, les scripts tiers proviennent de dizaines de serveurs différents aux performances variables.
🔴 Le problème central : votre thème se charge une fois et pèse peut-être 200-400 Ko de JavaScript. Mais les scripts d'applications tierces peuvent collectivement ajouter 1-3 Mo de JavaScript supplémentaire — 3 à 10 fois plus que votre thème entier. Chaque kilo-octet doit être téléchargé sur la connexion de votre visiteur et traité par le CPU de son appareil.
Ce n'est pas qu'une préoccupation théorique. Les recherches du HTTP Archive et de Google montrent systématiquement que le JavaScript tiers représente 60-80 % du temps total d'exécution des scripts sur le site e-commerce moyen. Sur les boutiques Shopify en particulier, nous avons vu ce chiffre atteindre 85 % sur les boutiques chargées en applications.
L'ironie cruelle ? La plupart de ces scripts se chargent sur chaque page de votre boutique, même quand les fonctionnalités de l'application ne sont pas visibles. Le JavaScript de votre widget d'avis se charge sur votre page d'accueil, votre page à propos, votre page de contact — partout — alors que les avis ne s'affichent que sur les pages produit.
2. Comment les scripts tiers se chargent dans votre navigateur
Pour comprendre pourquoi les scripts tiers sont si dommageables pour la performance, vous devez comprendre comment les navigateurs chargent une page. Voici la version simplifiée :
Le HTML arrive
Le navigateur reçoit le HTML de votre page depuis les serveurs de Shopify. C'est rapide — l'infrastructure de Shopify est solide.
Le navigateur commence à analyser le HTML
En lisant le HTML, il découvre les ressources à charger : fichiers CSS, fichiers JavaScript, images, polices.
⚠️ Les balises script bloquent le rendu
Quand l'analyseur rencontre une balise <script> sans async ni defer, il arrête tout. Il doit télécharger le script, l'analyser et l'exécuter avant de continuer. C'est ce qu'on appelle le « blocage du rendu ».
⚠️ Chaque script fait des requêtes réseau
Beaucoup de scripts d'applications ne sont pas autonomes. Ils chargent des fichiers supplémentaires — données de configuration, templates de widgets, bibliothèques d'analytics. Chacun exige sa propre résolution DNS, sa connexion et son téléchargement.
La page s'affiche enfin
Ce n'est qu'une fois tous les scripts bloquants exécutés que le navigateur affiche la page. Votre visiteur a fixé un écran vide ou à moitié chargé pendant tout ce temps.
Beaucoup de développeurs d'applications n'ajoutent pas les attributs async ou defer à leurs balises script — soit parce qu'ils ne connaissent pas les bonnes pratiques de performance, soit parce que leurs scripts dépendent d'un état précis du DOM. Résultat : leurs scripts empêchent votre page de s'afficher — ce qui nuit directement à vos scores Largest Contentful Paint (LCP) et Interaction to Next Paint (INP).
La chronologie du chargement
0ms — HTML reçu depuis Shopify
50ms — CSS analysé, la mise en page commence
100ms — ⏸ Script : review-widget.js (bloquant, 300ms)
400ms — ⏸ Script : chat-app.js (bloquant, 250ms)
650ms — ⏸ Script : analytics.js (bloquant, 200ms)
850ms — ⏸ Script : popup-builder.js (bloquant, 350ms)
1200ms — ⏸ Script : loyalty-program.js (bloquant, 200ms)
1400ms — ⏸ Chaque script charge 2-3 scripts DE PLUS...
2800ms — Les scripts finissent enfin de s'exécuter
3000ms — 🖼️ La page s'affiche (le visiteur voit le contenu)
Chronologie simplifiée montrant comment le blocage des scripts retarde l'affichage de la page
Dans cet exemple, 2.8 secondes des 3 secondes de chargement sont consacrées aux seuls scripts tiers. Le contenu réel de la page — vos produits, vos images, votre image de marque — pourrait se charger en moins de 500 ms si les scripts n'étaient pas dans le chemin.
3. Exemples réels : combien chaque type d'application vous coûte
Toutes les applications ne pèsent pas le même poids. Voici ce que nous observons typiquement sur les boutiques Shopify, sur la base de mesures réelles :
💬 Widgets de chat en direct
300–500msExemples : Tidio, Gorgias, Zendesk Chat, LiveChat, Intercom
Les widgets de chat comptent parmi les applications les plus lourdes. Ils chargent un framework d'interface complet, établissent une connexion WebSocket, récupèrent l'historique des conversations et affichent une bulle de chat animée. Intercom charge à lui seul 300-500 Ko de JavaScript. La majeure partie s'exécute sur chaque page, alors que la plupart des visiteurs ne cliquent jamais sur la bulle de chat.
⭐ Widgets d'avis
200–400msExemples : Judge.me, Loox, Yotpo, Stamped.io, Okendo
Les applications d'avis chargent leur JavaScript principal, puis font des appels API pour récupérer les données d'avis, afficher les notes en étoiles et mettre en place les fonctionnalités interactives (carrousels de photos, filtrage, tri). Même sur les pages sans aucun avis affiché, le script se charge et s'initialise quand même. Judge.me est l'une des options les plus légères ; Yotpo et Loox ont tendance à être plus lourds.
📧 Email marketing et popups
200–350msExemples : Klaviyo, Omnisend, Privy, Justuno, OptiMonk
Ceux-ci chargent des scripts pour l'affichage des formulaires, le suivi des utilisateurs, la logique des popups (chronométrage, règles de ciblage, tests A/B) et incluent souvent leurs propres frameworks CSS. Le JavaScript embarqué de Klaviyo est particulièrement lourd, car il suit le comportement des utilisateurs à des fins de segmentation — en chargeant du code d'analytics, du suivi de session et des gestionnaires de formulaires sur chaque page.
📊 Analytics et suivi
100–300msExemples : Google Analytics, Facebook Pixel, TikTok Pixel, Hotjar, Lucky Orange, Pinterest Tag
Les scripts d'analytics sont sournois. Chacun semble petit — peut-être 50-100 Ko. Mais les boutiques font souvent tourner 4-6 scripts de suivi simultanément : GA4, Facebook Pixel, TikTok Pixel, Hotjar pour les heatmaps, plus l'application d'analytics de la boutique elle-même. Ils totalisent collectivement 300-600 Ko, et chacun déclenche en plus des requêtes réseau pour envoyer les données de suivi.
🏷️ Google Tag Manager (GTM)
300–800msLe conteneur de scripts tiers n°1. GTM n'est pas juste un script de plus — c'est un script qui charge d'autres scripts.
Le conteneur GTM lui-même pèse 80-100 Ko et plus. Mais le vrai coût vient de ce qu'il y a dedans : Meta Pixel (80-150 Ko), TikTok Pixel (100-200 Ko), le suivi de conversion Google Ads (50-100 Ko), le suivi Klaviyo (100-200 Ko), Hotjar (150-300 Ko), et tout ce qui s'est accumulé au fil du temps. Un conteneur GTM typique déclenche 5-15 scripts supplémentaires, ajoutant 300-800 ms de temps de chargement total.
Comment auditer votre conteneur GTM :
- Ouvrez Google Tag Manager et sélectionnez votre conteneur.
- Allez dans Balises — comptez combien sont actives. La plupart des boutiques en ont 10-30+.
- Vérifiez le déclencheur de chaque balise — s'il indique « All Pages », demandez-vous : celle-ci doit-elle vraiment se déclencher partout ?
- Cherchez les balises zombies d'anciennes campagnes (vieilles audiences Facebook, outils abandonnés).
- Utilisez le mode Preview de GTM pour voir exactement quelles balises se déclenchent sur chaque page et combien de temps elles prennent.
Balises lourdes courantes dans GTM :
⚡ L'approche de Thunder : au lieu de différer les balises individuelles dans GTM (ce qui exige une expertise GTM), Thunder diffère le conteneur GTM entier. Quand GTM se charge plus tard, toutes les balises qu'il contient se chargent aussi plus tard — automatiquement. Cette seule optimisation peut économiser 300-800 ms sans toucher à votre configuration GTM. Essayez-le gratuitement →
GTM, Meta et TikTok : corriger une chute de score sans supprimer l’attribution à l’aveugle
Une forte baisse après l’ajout de GTM et de pixels est un signal de diagnostic, pas une raison de supprimer Google Tag Manager. Le même fournisseur est souvent chargé plusieurs fois : via les événements client ou pixels Shopify, l’application Google & YouTube, un extrait du thème et GTM.
- Lancez le test de vitesse Shopify gratuit sur la page d’accueil et une page produit.
- Vérifiez les événements client, intégrations d’apps, applications de canal de vente, code du thème et GTM Preview pour les identifiants et balises « All Pages » en double.
- Conservez un seul chemin d’installation intentionnel par fournisseur, puis testez les événements pageview, produit, ajout au panier et achat.
Les balises de consentement et d’attribution requise ne doivent pas être trop retardées. Les balises marketing facultatives peuvent charger après le contenu visible ou seulement sur les modèles concernés. Identifiez d’abord tout script Shopify ou Google inconnu avec l’analyseur Shopify.
🎨 Constructeurs de pages et applications d'upsell
200–500msExemples : PageFly, Shogun, GemPages, ReConvert, Bold Upsell
Les constructeurs de pages comme PageFly injectent leur propre framework de rendu, qui se charge sur chaque page — même celles que vous n'avez pas construites avec l'application. Les applications d'upsell chargent la logique de recommandation de produits, les scripts de modification du panier et les interfaces de popups sur chaque page, pour être prêtes quand un client ajoute au panier.
🔔 Preuve sociale et urgence
100–250msExemples : Sales Pop, Fomo, badges de confiance, comptes à rebours, compteurs de stock
Ils semblent légers, mais ils causent souvent des décalages de mise en page (problèmes de CLS). Ils injectent des éléments dans la page après le chargement — popups de notification, barres de badges de confiance, comptes à rebours — en déplaçant le contenu et en créant une expérience utilisateur saccadée. En plus, chacun est un script de plus que votre navigateur doit traiter.
4. L'effet cascade : la mort par mille scripts
Aucune application seule ne tue votre vitesse. C'est la combinaison qui le fait. Voici à quoi ressemble une boutique Shopify typique chargée en applications :
Une pile d'applications réelle (15 applications)
Trois secondes pleines de retard — rien qu'à cause des scripts d'applications. Ajoutez le JavaScript de votre thème (~300 ms), le CSS (~100 ms), les images (~500 ms) et les polices (~200 ms), et vous obtenez un chargement de page de plus de 4 secondes sur une bonne connexion. Sur un appareil mobile en 3G, doublez ce chiffre. Si votre boutique ressemble à cela, notre guide étape par étape vous accompagne pour corriger chaque couche — pas seulement les scripts.
15 apps
nombre moyen d'applications sur une boutique Shopify
~200ms
retard moyen par script d'application
3+ sec
retard total dû aux scripts tiers
Mais le calcul est en réalité pire qu'une simple addition. Les scripts n'additionnent pas juste leur temps de façon linéaire — ils se disputent les ressources :
- • Contention réseau : les navigateurs limitent les connexions simultanées par domaine (généralement 6). Quand 15 applications essaient de se charger depuis 15 domaines différents en même temps, elles font la queue et s'attendent les unes les autres.
- • Contention CPU : JavaScript est monothread. Pendant qu'un script s'exécute sur le thread principal, tous les autres scripts doivent attendre. C'est pourquoi l'INP (Interaction to Next Paint) en souffre — le navigateur ne peut pas répondre aux clics de l'utilisateur pendant qu'il est occupé à exécuter le code des applications.
- • Pression mémoire : chaque script alloue de la mémoire. Sur les smartphones d'entrée de gamme (qui représentent une grande partie des acheteurs mobiles), une utilisation excessive de la mémoire ralentit le navigateur, voire le fait planter.
- • Requêtes secondaires : la plupart des scripts d'applications chargent des ressources supplémentaires. Un widget d'avis charge son script principal, puis ce script charge du CSS, des icônes de police et des données API. Le « script unique » d'une application peut déclencher 5-10 requêtes réseau supplémentaires.
💡 À retenir : le problème n'est pas qu'une application isolée soit « trop lente ». C'est le poids accumulé de toutes vos applications qui se chargent simultanément, en concurrence pour la bande passante réseau, le temps CPU et la mémoire. La solution n'est pas forcément de supprimer des applications — c'est de contrôler quand et comment elles se chargent.
5. Comment auditer les scripts tiers sur votre boutique
Avant de pouvoir corriger le problème, vous devez identifier précisément quels scripts en sont la cause. Commencez par une mesure de référence rapide — testez la vitesse de votre boutique pour voir où vous en êtes maintenant. Utilisez ensuite ces méthodes, de la plus technique à la plus simple :
Méthode 1 : l'onglet Network de Chrome DevTools
C'est la vue la plus détaillée de ce qui se charge sur votre page.
- Ouvrez votre boutique dans Chrome. Appuyez sur F12 (ou clic droit → Inspecter) pour ouvrir DevTools.
- Cliquez sur l'onglet Network.
- Cochez la case « Disable cache » (simule un visiteur qui vient pour la première fois).
- Rechargez la page (Ctrl+Shift+R pour un rechargement complet).
- Cliquez sur le filtre « JS » pour n'afficher que les fichiers JavaScript.
- Triez par la colonne « Size » ou « Time » pour trouver les scripts les plus lourds/lents.
Ce qu'il faut chercher : les scripts venant de domaines que vous ne reconnaissez pas sont des scripts tiers. Les schémas courants incluent cdn.judge.me, static.klaviyo.com, widget.intercom.io, etc. Notez le domaine, la taille du fichier et le temps de chargement de chacun.
Méthode 2 : l'outil Coverage de Chrome
L'outil Coverage montre quelle part de chaque fichier JavaScript est réellement utilisée sur la page en cours. Cela révèle le gaspillage — des scripts qui chargent des centaines de Ko mais n'utilisent que 10-20 % de leur code.
- Ouvrez DevTools (F12).
- Appuyez sur Ctrl+Shift+P (menu de commandes) et tapez « Coverage ».
- Cliquez sur « Show Coverage ».
- Cliquez sur le bouton de rechargement dans le panneau Coverage.
- Une fois la page chargée, triez par « Unused Bytes ».
Signal d'alarme : si un script a 80 %+ d'octets inutilisés, il charge bien plus de code que nécessaire pour la page en cours. C'est courant avec les gros bundles d'applications qui incluent des fonctionnalités pour toutes les pages mais n'en utilisent qu'une fraction sur chacune.
Méthode 3 : « Reduce JavaScript Execution Time » de PageSpeed Insights
L'approche la plus simple. Passez votre boutique dans PageSpeed Insights et cherchez ces diagnostics précis :
- « Reduce JavaScript execution time » — liste les scripts les plus lourds par temps d'exécution
- « Reduce the impact of third-party code » — montre les scripts tiers groupés par fournisseur avec leur temps de blocage
- « Minimize main-thread work » — montre la répartition du temps total sur le thread principal par catégorie
- « Avoid enormous network payloads » — signale les ressources surdimensionnées
Méthode 4 : utiliser le scanner d'applications de Thunder (la plus simple)
Thunder analyse automatiquement vos applications Shopify installées et génère un rapport d'impact sur la vitesse par application — montrant exactement combien de millisecondes et de kilo-octets chaque application ajoute au chargement de votre page. Aucune connaissance de DevTools requise. Installez l'application, et le rapport apparaît dans votre tableau de bord Shopify.
6. Comment corriger les scripts tiers lents
⚠️ Difficulté : intermédiaire à avancée. L'optimisation manuelle des scripts exige de comprendre l'ordre d'exécution du JavaScript, les chaînes de dépendances et le templating Liquid de Shopify. Une seule erreur peut casser votre checkout ou vos applications. Thunder automatise tout cela avec une configuration en 30 secondes.
Une fois les coupables identifiés, voici ce que vous pouvez faire — par ordre d'efficacité :
Correctif 1 : supprimez ce dont vous n'avez pas besoin
Le script le plus rapide est celui qui ne se charge jamais. Passez en revue vos applications installées et évaluez honnêtement chacune :
- Les applications essayées une fois puis oubliées. Vérifiez votre admin Shopify → Applications. Vous seriez surpris du nombre d'applications « d'essai » encore installées.
- Les fonctionnalités en double. Vous faites tourner à la fois Klaviyo et Omnisend ? Vous utilisez Loox et Judge.me ? Choisissez-en un.
- Les applications à faible valeur. Cette notification « Sales Pop » qui affiche « Quelqu'un à Toronto vient d'acheter... » ? Elle ajoute 100-200 ms de temps de chargement. Génère-t-elle vraiment des conversions, ou n'est-ce que du bruit ?
- Les restes saisonniers. Le compte à rebours des fêtes encore installé en février ? Supprimez-le.
Étape cruciale : après la désinstallation, vérifiez le code de votre thème. Allez dans Boutique en ligne → Thèmes → Modifier le code et cherchez le nom de l'application dans theme.liquid et les fichiers layout/. Beaucoup d'applications laissent derrière elles des balises de script qui continuent de se charger même après la désinstallation.
Correctif 2 : trouvez des alternatives plus légères
Toutes les applications d'une même catégorie n'ont pas le même impact sur la performance. Par exemple :
- Avis : Judge.me est nettement plus léger que Yotpo ou Loox
- Email marketing : Shopify Email est plus léger que Klaviyo pour les besoins basiques
- Chat : Shopify Inbox est plus léger qu'Intercom ou Gorgias
- Analytics : les analytics intégrés de Shopify + GA4 peuvent suffire sans Hotjar, Lucky Orange ET Mixpanel
Correctif 3 : différez les scripts non critiques
Pour les applications que vous voulez garder, la meilleure option suivante est de changer quand leurs scripts se chargent. Au lieu de bloquer le rendu de la page, différez-les jusqu'à ce que le contenu principal soit visible :
- Approche manuelle : modifiez le
theme.liquidde votre thème et ajoutezdeferaux balises de script des applications. Risqué — peut casser les applications si c'est mal fait. - Retarder jusqu'à l'interaction : certains développeurs utilisent une technique où les scripts ne se chargent qu'après la première interaction de l'utilisateur (défilement, clic, toucher). Cela améliore radicalement le chargement initial, mais les fonctionnalités ne sont pas prêtes immédiatement.
- Utiliser un optimiseur de scripts : des outils comme Thunder automatisent ce processus, en différant intelligemment les scripts tout en maintenant leur fonctionnement. Consultez notre guide complet d'optimisation de la vitesse pour plus de détails.
Correctif 4 : le chargement conditionnel (scripts par page)
Pourquoi charger le script de votre widget d'avis sur la page d'accueil quand les avis ne s'affichent que sur les pages produit ? Le chargement conditionnel garantit que les scripts ne se chargent que là où ils sont nécessaires.
En Liquid, vous pouvez envelopper les balises de script des applications dans des conditions de template :
{% if template contains 'product' %}
<script src="review-widget.js"></script>
{% endif %}
C'est une technique puissante, mais elle exige de modifier le code de votre thème et de savoir quelles applications sont nécessaires sur quelles pages. Certaines applications injectent leurs scripts d'une manière qui rend cela difficile sans casser leur fonctionnement.
7. L'approche Thunder : l'optimisation automatisée des scripts
Tous les correctifs ci-dessus fonctionnent, mais ils partagent un problème : ils sont manuels, fragiles et difficiles à maintenir. Les applications mettent à jour leurs scripts. De nouvelles applications s'installent. Les mises à jour de thème peuvent écraser vos modifications. Il vous faudrait un développeur pour surveiller et ajuster en permanence.
C'est pour cela que nous avons construit Thunder. Au lieu de modifier manuellement les balises de script en espérant qu'elles ne cassent rien, Thunder automatiquement :
- ✓ Analyse toutes les applications installées et génère un rapport d'impact sur la vitesse par application
- ✓ Diffère intelligemment les scripts non critiques pour qu'ils se chargent une fois le contenu de votre page visible
- ✓ Préserve les dépendances entre scripts — comprend quels scripts doivent se charger avant les autres
- ✓ Surveille les Core Web Vitals pour que vous voyiez l'impact réel dans votre tableau de bord Shopify
- ✓ S'adapte automatiquement quand les applications mettent à jour leurs scripts ou que vous en installez de nouvelles
Résultat : les boutiques voient typiquement une amélioration de 20-60 % du temps de chargement, avec les plus gros gains sur les boutiques comptant le plus d'applications tierces. Si votre score PageSpeed est actuellement de 25-35, vous pouvez raisonnablement atteindre 50-70+ avec la seule optimisation des scripts. Vous voulez voir ce qui est inclus ? Consultez les plans Thunder — il y a un palier gratuit pour commencer.
Vous hésitez encore sur Thunder ? Nous avons rédigé des comparaisons honnêtes face à chaque concurrent majeur : Thunder vs Booster, Thunder vs Hyperspeed, Thunder vs Avada et Thunder vs Tapita. Ou consultez notre panorama complet des meilleures applications d'optimisation de vitesse Shopify pour 2026.
Questions fréquentes
Que sont les scripts tiers sur Shopify ?
Les scripts tiers sont des fichiers JavaScript chargés par les applications que vous avez installées sur votre boutique Shopify. Quand vous installez un widget d'avis, une application de chat, un popup d'email ou un outil d'analytics, chacun injecte son propre JavaScript dans votre vitrine. Ces scripts s'exécutent dans le navigateur de vos visiteurs aux côtés du code de votre thème, en concurrence pour le temps de calcul et la bande passante réseau.
Comment trouver quelles applications ralentissent ma boutique Shopify ?
Ouvrez Chrome DevTools (F12), allez dans l'onglet Network, rechargez votre page et filtrez par « JS ». Cherchez les scripts provenant de domaines externes — ce sont les scripts d'applications tierces. Triez par taille ou par temps pour trouver les pires coupables. Pour une approche plus simple, utilisez l'outil Coverage (Ctrl+Shift+P → « Coverage ») pour voir quelle part de chaque script est réellement utilisée. Le scanner d'applications de Thunder automatise tout ce processus et vous donne un rapport d'impact par application.
Les applications Shopify désinstallées ralentissent-elles encore ma boutique ?
Oui, souvent. Beaucoup d'applications Shopify injectent des extraits de code dans vos fichiers de thème (surtout theme.liquid) lors de l'installation. Quand vous désinstallez l'application, ces extraits de code restent. Vous devez vérifier manuellement le code de votre thème et supprimer les balises de script restantes. Cherchez le nom de l'application ou son domaine de script dans vos fichiers de thème pour trouver le code orphelin.
Combien d'applications Shopify est-ce trop ?
Il n'y a pas de chiffre magique — cela dépend du poids de chaque application. Une boutique avec 30 applications légères peut être plus rapide qu'une boutique avec 5 applications lourdes. La boutique Shopify moyenne a 15-25 applications installées. Concentrez-vous sur la mesure de l'impact réel de chaque application sur le temps de chargement plutôt que sur le comptage. En règle générale, si votre score PageSpeed chute de plus de 5 points après l'installation d'une application, cette application a besoin d'optimisation.
Puis-je différer les scripts tiers sans casser mes applications ?
Oui, mais cela demande de la prudence. Un report de scripts naïf peut casser le fonctionnement des applications — par exemple, différer le script d'un widget d'avis peut faire apparaître les avis brusquement après le chargement de la page, ou différer un script d'analytics peut faire manquer le suivi des pages vues. Les outils de report intelligents comme Thunder comprennent les dépendances entre scripts et les diffèrent dans le bon ordre, en préservant le fonctionnement tout en améliorant le temps de chargement.
Comment réduire le temps d'exécution JavaScript sur Shopify ?
Pour réduire le temps d'exécution JavaScript, commencez par supprimer les applications inutilisées et leur code restant dans theme.liquid. Différez ensuite les scripts tiers non critiques pour qu'ils se chargent après votre contenu principal. Utilisez le panneau Performance de Chrome DevTools pour trouver les scripts les plus lourds — tout ce qui dépasse 100 ms de travail sur le thread principal est un candidat au report. Les conteneurs Google Tag Manager représentent souvent 300-800 ms à eux seuls, car ils chargent plusieurs scripts de suivi. Un optimiseur de vitesse comme Thunder automatise le report des scripts tout en préservant le fonctionnement, économisant typiquement 1-3 secondes de temps d'exécution.
Quelle est la différence entre async et defer pour les scripts ?
async et defer permettent tous deux au navigateur de continuer à analyser le HTML pendant le téléchargement du script. La différence : les scripts « async » s'exécutent dès qu'ils sont téléchargés (potentiellement dans le désordre), tandis que les scripts « defer » s'exécutent après l'analyse complète du HTML, dans l'ordre où ils apparaissent. Pour les scripts d'applications tierces, « defer » est généralement plus sûr, car il préserve l'ordre d'exécution. Cependant, la meilleure approche est de retarder complètement les scripts jusqu'à ce que la page soit interactive — c'est ce que font les applications d'optimisation de vitesse.