Pourquoi une app pop-up peut ralentir votre boutique Shopify ?
Parce que le script de l’app s’exécute sur le fil principal du navigateur, souvent à chaque chargement de page, même si aucune fenêtre n’apparaît. L’acheteur clique sur « Ajouter au panier », ouvre un filtre ou tape dans la recherche : si le navigateur est encore occupé par ce script, le prochain affichage attend. C’est exactement ce que mesure l’INP (Interaction to Next Paint).
Le 21 août 2026, Performance @ Shopify (Estela Franco) a publié l’étude de cas Poptin, une plateforme d’automatisation e-mail et d’optimisation de conversion utilisée pour créer des pop-ups et formulaires de capture. L’équipe Web Performance de Shopify a constaté que le script storefront de Poptin était associé à des interactions lentes sur plusieurs types de pages. Après correctif, l’INP au 75e percentile a baissé de 57 % sur des milliers de boutiques.
Qu’est-ce que l’INP, en termes simples ?
Selon web.dev, l’INP (Interaction to Next Paint) est une métrique Core Web Vital stable. Elle observe la latence de toutes les interactions clic, tap et clavier pendant la visite, puis rapporte une valeur sous laquelle se situent (presque) toutes ces interactions. Un INP bas signifie que la page a pu répondre vite à la grande majorité des gestes de l’acheteur.
Concrètement : l’acheteur agit, le navigateur exécute les gestionnaires d’événements, puis affiche la prochaine image. L’INP mesure le temps jusqu’à ce prochain affichage, pas toute la suite asynchrone (requêtes réseau ultérieures, mises à jour UI différées). Si cet affichage est retardé, la page paraît « figée ».
| Seuil | Interprétation |
|---|---|
| ≤ 200 ms | Bonne réactivité |
| > 200 ms et ≤ 500 ms | À améliorer |
| > 500 ms | Mauvaise réactivité |
Pourquoi l’INP compte pour la conversion mobile ?
Parce que l’INP fait partie des Core Web Vitals : Google s’en sert comme signal d’expérience de page. Au-delà du SEO, le ressenti est immédiat sur mobile : un bouton qui ne réagit pas pousse au double-clic, à l’abandon du filtre, ou à quitter la fiche produit.
web.dev rappelle aussi que, d’après les données d’usage Chrome, 90 % du temps passé sur une page survient après le chargement. Optimiser seulement le premier affichage (LCP, FCP) ne suffit pas : la réactivité pendant le parcours (panier, menu, options, recherche) pèse sur la conversion.
Dans le cas Poptin, les plus gros gains apparaissent dans la queue de distribution (p90 : −63 %), là où les acheteurs sur appareils ou réseaux plus lents ressentent le plus le délai. C’est aussi là que le risque de « la page ne répond pas » est le plus élevé.
Que s’est-il passé avec Poptin (août 2026) ?
Le suivi utilisateur réel (RUM) de Shopify a isolé une longue tâche d’environ 900 ms sur le fil principal pendant l’initialisation du script Poptin. Les tests montraient des appels XMLHttpRequest synchrones depuis le gestionnaire de chargement du script. Une requête synchrone bloque le fil principal jusqu’à la réponse réseau : le navigateur ne peut pas traiter les entrées utilisateur pendant cette chaîne.
Les appels récupéraient un client ID, le panier et des règles de prix, plus une requête panier synchrone dans une autre fonction. Ils partaient à chaque chargement. Sur connexions et appareils lents, les allers-retours réseau amplifiaient l’impact. Un profil Chrome DevTools montrait cette tâche d’environ 900 ms au chargement.
Ce n’était pas un cas isolé. Sur un échantillon initial de sept jours de boutiques où Poptin était le script le plus lent pendant les interactions, Shopify associe le script à un INP p75 de 984 ms, sur des centaines de milliers d’interactions et des milliers de marchands.
Shopify a partagé traces, cause probable et pistes d’implémentation avec l’équipe Poptin. Deux changements ont structuré la collaboration :
Correctifs retenus
- 01
Requêtes réseau asynchrones
Retirer les options de requêtes synchrones et laisser les fonctions de rappel (callbacks) asynchrones gérer les réponses. Client ID, panier et règles de prix sont passés en chaîne de fonctions de rappel ; la fonction qui renvoyait le panier de façon synchrone accepte désormais une fonction de rappel. Le comportement de l’app est conservé, sans bloquer le fil principal sur la latence réseau.
- 02
Initialisation différée
Planifier l’initialisation dans une nouvelle tâche, au lieu de l’exécuter directement dans le gestionnaire de chargement du script. Le navigateur peut traiter les entrées déjà en file avant que l’app ne démarre son travail.
Après déploiement, la plus longue tâche Poptin tombe à environ 75 ms (réduction de 91 %). Sur l’ensemble des appareils et navigateurs, les INP mesurés par Shopify évoluent ainsi :
| Percentile | Avant | Après | Variation |
|---|---|---|---|
| P50 | 88 ms | 64 ms | −27 % |
| P75 | 280 ms | 120 ms | −57 % |
| P90 | 736 ms | 272 ms | −63 % |
Au p75, l’INP passe de 280 ms à 120 ms (−160 ms) et entre dans la zone « Good » de web.dev. Côté attribution (navigateurs supportant l’API Long Animation Frames) : interactions quotidiennes où Poptin était le script le plus lent −98,6 % ; boutiques touchées par jour −89,7 % ; durée de script attribuée au p75 −46 % ; INP attribué au p75 −39 %. Même sur le petit volume d’interactions où Poptin restait le plus lent, l’INP p75 de ces interactions s’améliore de 39 %.
Comment repérer une app qui ralentit les interactions ?
En partant des données utilisateurs réels de votre boutique, puis en confirmant la cause dans un profil de performance. Dans « Web Performance Tools for 2026 » (Dan Gayle, 13 janvier 2026), Shopify recommande une règle simple : utiliser d’abord les tableaux de bord Web performance de l’admin pour localiser le problème, puis valider avec le panneau Performance de Chrome DevTools.
Démarche marchand ou technique
- 01
Ouvrir les tableaux de bord Web performance
Dans l’admin Shopify, ouvrez les rapports Web performance (même fond de données RUM que celui utilisé en interne par Shopify). Choisissez une métrique (ici l’INP), un type de template (accueil, produit, collection), notez l’élément cible s’il est indiqué, et vérifiez si le pic coïncide avec l’installation d’une app ou une mise à jour de thème.
- 02
Reproduire une page lente
Sur le thème publié, ouvrez la page concernée dans Chrome, démarrez un enregistrement Performance, reproduisez le clic ou le tap qui « rame », puis cherchez les longues tâches et le script responsable (nom de domaine de l’app, fichier .js injecté).
- 03
Croiser Sidekick si besoin
Shopify indique que Sidekick peut interroger les données des rapports Web performance (pages les plus lentes par LCP/INP, mobile vs desktop). Sidekick n’a pas accès au code du thème ni des apps : il oriente, DevTools confirme.
- 04
Tester hors labo seul
Lighthouse ou un test synthétique aident au débogage local. Shopify insiste sur le RUM : appareils, réseaux et navigateurs réels (y compris Safari, qui expose désormais LCP et INP) ne sont pas capturés par un seul audit lab.
Quoi demander à l’éditeur d’une app ?
Shopify adresse aux développeurs d’apps un appel clair : mesurer l’impact réel, inspecter le travail sur le fil principal et les requêtes bloquantes, tester sur appareils et connexions lents. En tant que marchand, vous pouvez formaliser la même exigence dans un ticket support ou un renouvellement d’abonnement.
Questions concrètes à poser
- 01
Requêtes synchrones
Le script storefront utilise-t-il encore du XHR synchrone (ou tout appel réseau bloquant) pendant l’initialisation ? Si oui, quel est le plan de migration vers de l’asynchrone ?
- 02
Charge même sans widget visible
Le script s’exécute-t-il sur toutes les pages alors qu’aucun pop-up, chat ou badge n’est affiché ? Peut-on le limiter aux templates où la fonctionnalité est active ?
- 03
Découpage des tâches
L’initialisation est-elle planifiée dans une tâche séparée (pour laisser le navigateur traiter les clics en file), ou collée au gestionnaire de chargement du script ?
- 04
Preuves RUM
L’éditeur suit-il l’INP et les longues tâches sur un panel de boutiques Shopify ? Peut-il partager un avant-après (comme Poptin avec Shopify) après une release ?
- 05
Attribution script
Sur les navigateurs qui exposent l’API Long Animation Frames, l’app apparaît-elle encore comme script le plus lent sur des interactions ? À quelle fréquence ?
Si l’éditeur ne peut pas répondre, ou si l’INP de votre boutique ne remonte pas après une mise à jour annoncée, testez une désactivation temporaire de l’embed (ou un thème de prévisualisation sans l’app) et comparez le tableau de bord Web performance. Le levier est souvent côté app, pas côté Liquid : les gains plateforme récents (Early Hints, streaming HTML, lazy loading vidéo) n’annulent pas un script qui bloque le fil principal.
En résumé : apps marketing et INP Shopify
Une app pop-up, chat ou avis peut dégrader la réactivité sans rien afficher. L’INP mesure ce délai entre le geste de l’acheteur et le prochain affichage ; sous 200 ms au p75, web.dev parle de bonne réactivité. Le cas Poptin (Performance @ Shopify, 21 août 2026) montre qu’un correctif ciblé (requêtes asynchrones et initialisation différée) peut faire chuter l’INP de 57 % au p75 (de 280 ms à 120 ms) sur des milliers de boutiques, avec une tâche d’initialisation qui passe d’environ 900 ms à environ 75 ms.
Pour votre boutique : lisez d’abord les tableaux de bord Web performance de l’admin, validez dans Chrome DevTools, puis exigez de l’éditeur des preuves RUM et l’absence de blocage synchrone. Si vous devez prioriser thème et apps ensemble, croisez aussi Early Hints Shopify, streaming Liquid et lazy loading vidéo.
