Tu cliques sur « ajouter au panier ». Rien ne se passe. Tu recliques. Le bouton finit par réagir une demi-seconde plus tard. Ce micro-blocage, Google le mesure désormais sur chaque interaction de ta boutique, et il a un nom : INP.
Depuis mars 2024, INP fait partie des Core Web Vitals, les trois indicateurs que Google utilise pour juger l’expérience réelle de tes visiteurs (web.dev). Et c’est précisément là que les boutiques Shopify trébuchent. La métrique ne regarde plus une seule interaction comme avant. Elle regarde toutes celles que ton visiteur déclenche pendant sa visite, puis retient la pire (ou presque).
Le souci, c’est qu’une boutique Shopify moyenne empile des dizaines de scripts tiers : reviews, popups, chat, fidélité, upsells. Chacun veut sa part du fil d’exécution JavaScript. Résultat, le navigateur met du temps à répondre quand on clique, et ton INP plonge dans le rouge.
Dans les lignes qui suivent, tu vas savoir mesurer ton INP, comprendre pourquoi Shopify a un problème structurel avec cette métrique, et identifier les 5 sources principales de mauvais score. Pas de théorie abstraite. Des outils concrets, des seuils chiffrés et sourcés, et une méthode pour repérer le coupable dans ton propre navigateur.
INP en clair : la métrique qui mesure si ton site répond quand on clique
INP veut dire Interaction to Next Paint. En français : le délai entre le moment où ton visiteur agit (clic, tap, touche du clavier) et le moment où l’écran se met à jour pour lui répondre.
Concrètement, quand quelqu’un clique sur un bouton, trois choses prennent du temps. D’abord le navigateur attend que le fil JavaScript principal se libère pour traiter l’événement : c’est le délai d’entrée. Ensuite il exécute ton code et celui de tes apps : c’est le temps de traitement. Enfin il redessine l’écran : c’est le délai de présentation. INP additionne ces trois phases et te donne un chiffre en millisecondes.
Cette décomposition compte, parce qu’elle te dit où chercher. Un temps de traitement long pointe vers un gestionnaire d’événement trop lourd, typiquement une app qui calcule en direct. Un délai de présentation long trahit un rendu coûteux, comme une animation ou un recalcul de mise en page massif. Quand tu sauras lire ces trois phases dans DevTools, tu sauras quoi corriger.
Les seuils fixés par Google sont clairs (web.dev) :
| Score INP | Verdict | |-----------|---------| | moins de 200 ms | Bon | | 200 à 500 ms | À améliorer | | plus de 500 ms | Mauvais |
La grosse différence avec l’ancienne métrique, FID (First Input Delay), tient en un mot : toutes. FID ne mesurait que la première interaction de la visite, souvent la plus rapide parce que les scripts n’avaient pas encore fini de se charger. Tu pouvais avoir un FID excellent et un site qui ramait à chaque clic ensuite.
INP ne te laisse plus ce confort. Il observe chaque interaction du début à la fin de la session, puis retient la plus lente (en lissant les valeurs extrêmes sur les pages très actives). Autrement dit, un seul clic lent sur ton menu, ton filtre de collection ou ton bouton panier suffit à ruiner ton score.
Pour une boutique, c’est brutal. Les interactions critiques (ouvrir le panier, appliquer un filtre, agrandir une photo produit) sont justement celles qui déclenchent le plus de JavaScript. Ce sont elles que tes visiteurs touchent le plus, et elles que INP scrute le plus. Un visiteur qui prépare un achat enchaîne facilement plusieurs interactions par page, et il suffit qu’une seule traîne pour que ta page hérite d’un mauvais score sur l’ensemble de la session.
Pourquoi Google met le paquet sur INP depuis 2024
Mars 2024, Google rend la décision officielle : INP remplace FID dans les Core Web Vitals (web.dev). Ce n’est pas un détail technique réservé aux développeurs. Les Core Web Vitals nourrissent le signal « page experience » que Google utilise dans son classement.
En 2026, ce signal reste un facteur de référencement. Il ne fait pas tout : un bon contenu sur un site lent peut encore se classer. Mais à contenu équivalent, la boutique qui répond vite passe devant celle qui rame. Sur un marché concurrentiel, ce delta se paie en trafic organique.
Au delà du SEO, il y a la conversion. La vitesse de réponse n’est pas une coquetterie d’ingénieur, c’est de l’argent. Une étude Deloitte montre qu’une amélioration de seulement 0,1 seconde sur le temps de chargement mobile augmentait les conversions de 8,4 % dans le retail (Deloitte 2020).
Côté retard, Akamai avait déjà chiffré la chute : un délai de 100 ms suffisait à faire baisser les taux de conversion de 7 % (Akamai 2017). Ces chiffres portent sur le chargement, pas directement sur l’INP, mais le mécanisme est le même : chaque milliseconde d’attente entre l’action et la réaction grignote ta marge.
Il y a aussi un effet psychologique que les chiffres résument mal. Quand un bouton ne réagit pas tout de suite, le visiteur doute. Il se demande si son clic a été pris en compte, recommence, parfois abandonne. Cette friction invisible casse l’élan d’achat au pire moment, juste quand la personne était décidée.
Google a donc une logique simple. Récompenser les sites qui répondent vite, parce que ce sont ceux qui retiennent les visiteurs et qui vendent. INP est l’outil qui mesure cette réactivité de façon réaliste, sur de vraies interactions de vrais utilisateurs.
Le problème structurel des boutiques Shopify
Shopify n’est pas une plateforme lente par nature. Le souci, c’est ce qu’on empile dessus. Trois raisons techniques expliquent pourquoi les boutiques Shopify galèrent particulièrement sur INP.
1. La stack d’apps tierces
C’est la cause numéro un. Chaque app que tu installes (reviews, popup, chat, fidélité) injecte son propre JavaScript dans tes pages. Chacune écoute des événements, charge ses ressources, exécute ses scripts sur le fil principal du navigateur.
Selon les marchands que j’audite, beaucoup tournent avec dix à vingt apps actives sans s’en rendre compte. La plupart ont été installées « pour tester », jamais désinstallées proprement, et continuent de charger du code à chaque visite. Quand un visiteur clique, le navigateur doit attendre que tous ces scripts libèrent le fil. C’est là que l’INP explose.
Le piège, c’est que le fil principal du navigateur est unique. Il ne fait qu’une chose à la fois. Pendant qu’une app de reviews reconstruit son carrousel, le clic de ton visiteur attend son tour dans la file. Multiplie ça par le nombre d’apps actives et tu obtiens un fil saturé, incapable de répondre à temps.
2. Les thèmes lourds
Beaucoup de thèmes premium misent sur l’effet visuel : carrousels animés, effets de survol partout, sliders produits, parallaxes. Joli en démo, coûteux à l’exécution. Chaque animation déclenchée par une interaction consomme du temps de calcul juste au moment où le visiteur attend une réponse.
Un thème mal optimisé peut transformer un simple clic sur une vignette en une cascade de recalculs de mise en page. Le navigateur peine à redessiner l’écran à temps, et INP en prend note. Le problème s’aggrave quand le thème ajoute ses propres scripts par-dessus ceux des apps : un menu mega-déroulant qui réorganise sa structure à chaque ouverture, un quick-view produit qui reconstruit son contenu à la volée.
3. Le script Shopify natif
Une partie du JavaScript vient de Shopify lui-même : gestion du panier en ajax, analytics, scripts de checkout. Tu ne peux pas y toucher en tant que marchand. C’est le prix de la plateforme hébergée. Shopify documente d’ailleurs ses propres recommandations de performance et les leviers que tu contrôles vraiment (aide Shopify).
Ce socle natif est généralement raisonnable. Le vrai problème survient quand il s’additionne à tes apps et à ton thème. Chaque couche prend quelques millisecondes. Empilées, elles font passer ton INP de « bon » à « mauvais » sans qu’aucun élément ne soit, seul, catastrophique.
La bonne nouvelle : sur ces trois leviers, deux sont entièrement entre tes mains. Les apps et le thème, tu les contrôles. Encore faut-il savoir où regarder.
Comment mesurer ton INP en 2026
Avant de corriger, il faut mesurer. Trois outils gratuits suffisent, du plus simple au plus précis. Le bon réflexe : commencer par les données de terrain pour savoir si tu as un problème, puis descendre vers le diagnostic en labo pour savoir d’où il vient.
PageSpeed Insights
C’est le point de départ. Tu te rends sur l’outil PageSpeed Insights, tu colles l’URL d’une page de ta boutique, et l’outil te renvoie tes scores Core Web Vitals, INP compris.
Le détail important : PageSpeed Insights affiche deux types de données. En haut, les « données de terrain » (field data), issues des vrais visiteurs Chrome de ta boutique sur les 28 derniers jours. C’est cette section qui compte pour Google, parce qu’elle reflète l’expérience réelle. En dessous, un test « en labo » sur une page chargée à la demande, utile pour diagnostiquer mais pas pour juger ton classement.
Concrètement, lance d’abord le test en mobile, puis bascule sur desktop avec le sélecteur en haut. Note ton INP de terrain pour chaque appareil. Si la barre INP est orange ou rouge en mobile alors qu’elle est verte en desktop, tu tiens déjà ton diagnostic de départ : le problème vient de scripts trop lourds pour les processeurs de téléphone.
Teste plusieurs pages, pas seulement l’accueil. Une fiche produit, une page de collection, le panier. Les interactions diffèrent, donc l’INP aussi. La fiche produit est souvent la plus révélatrice, parce qu’elle concentre reviews, upsells et galerie d’images sur une même page.
Chrome User Experience Report (CrUX)
Les données de terrain de PageSpeed viennent de là. Le Chrome User Experience Report agrège les mesures de performance réelles des utilisateurs de Chrome ayant accepté le partage, sur des millions de sites (CrUX).
Pour aller plus loin que PageSpeed, tu peux explorer CrUX via le tableau de bord dédié ou via l’API. Tu y vois l’évolution de ton INP mois après mois, et tu peux comparer mobile et desktop. C’est précieux : l’INP mobile est presque toujours pire que le desktop, parce que les processeurs de téléphone encaissent moins bien le JavaScript des apps.
L’intérêt du suivi mensuel, c’est qu’il révèle les causes. Une chute d’INP qui coïncide avec l’installation d’une app, ou avec un changement de thème, te donne le coupable sans même ouvrir DevTools.
Si ta boutique est récente ou a peu de trafic, CrUX peut manquer de données. Dans ce cas, passe directement aux mesures en labo.
Chrome DevTools Performance
C’est l’outil de diagnostic chirurgical. Ouvre ta boutique dans Chrome, lance DevTools (F12), va dans l’onglet Performance.
La méthode pas à pas. D’abord, active la limitation du processeur (CPU throttling) dans les réglages de l’onglet Performance, en mode « 4x slowdown » par exemple, pour simuler un téléphone d’entrée de gamme. C’est important : sur ta machine de bureau, tout paraît rapide, et tu rates les ralentissements que vivent tes vrais visiteurs mobiles.
Ensuite, clique sur enregistrer, puis reproduis l’interaction qui te semble lente (ouvrir le panier, appliquer un filtre, agrandir une image). Arrête l’enregistrement. DevTools te montre une chronologie détaillée. Cherche les « long tasks », ces tâches JavaScript qui bloquent le fil principal plus de 50 ms. Elles apparaissent souvent en rouge ou avec un triangle d’alerte dans le coin.
Repère ensuite la piste « Interactions », juste au-dessus de la timeline principale, qui matérialise chaque interaction et sa durée. Clique sur la barre la plus longue : DevTools t’indique le moment du clic, la phase de traitement et le moment du rendu. C’est ta décomposition INP en direct.
En survolant chaque tâche, tu vois quel script l’a déclenchée. C’est ainsi que tu remontes jusqu’à l’app coupable. Souvent, le nom du fichier (loox.js, privy.js, tidio) trahit directement l’application responsable. Tu peux aussi ouvrir l’onglet « Bottom-Up » en bas de DevTools pour voir quels scripts ont consommé le plus de temps. À partir de là, tu sais quoi corriger.
Les 5 sources principales de mauvais INP sur Shopify
Voici les cinq familles d’apps que je retrouve le plus souvent en cause lors de mes audits. Pour chacune : le problème, comment l’identifier dans DevTools, comment corriger.
1. Les apps de reviews (Loox, Judge.me, Yotpo)
Le problème : les apps d’avis chargent des galeries de photos, des étoiles, des sliders de témoignages. Beaucoup injectent leur widget sur toutes les pages, même celles sans avis affichés. Quand le visiteur interagit, le script de l’app entre en concurrence avec le reste. Le carrousel de photos clients, en particulier, recalcule sa disposition à chaque défilement et chaque clic sur une vignette.
Comment l’identifier : dans DevTools Performance, lance un enregistrement pendant que tu scrolles une fiche produit ou que tu cliques sur une vignette d’avis. Repère les long tasks rattachées à un fichier du type loox, judgeme ou yotpo. Si l’interaction « clic sur une photo d’avis » dépasse 200 ms dans la piste Interactions, tu tiens un coupable clair.
Comment corriger : limite le widget aux pages produit (pas la home ni les collections). Active le chargement différé (lazy load) du carrousel d’avis s’il existe dans les réglages de l’app, pour qu’il ne se construise qu’au moment où le visiteur arrive à sa hauteur. Et fais le ménage : si tu as testé deux apps de reviews et n’en utilises qu’une, désinstalle l’autre proprement, code résiduel compris.
Pour approfondir le sujet des apps qui plombent ton site, lis aussi Combien tes apps Shopify te coûtent vraiment.
2. Les popups marketing (Privy, OptiMonk)
Le problème : les popups d’inscription newsletter ou de réduction se déclenchent sur un événement (sortie de page, scroll, délai). Pour cela, ils écoutent en permanence l’activité du visiteur. Cette écoute mobilise le fil principal, et l’apparition du popup elle-même est une grosse interaction qui peut peser lourd sur ton INP. Le pire cas, c’est le popup qui surgit pile au moment où le visiteur s’apprêtait à cliquer ailleurs.
Comment l’identifier : enregistre dans DevTools le moment précis où le popup apparaît. Tu verras souvent une longue tâche au déclenchement, juste avant l’affichage. Cherche les fichiers privy, optimonk ou similaires dans le détail de la tâche.
Comment corriger : réduis le nombre de popups actifs à un seul, bien ciblé. Vérifie dans les réglages que l’animation d’entrée reste simple, sans flou ni effet coûteux à animer. Désactive les popups sur mobile si l’INP mobile est ton point faible, ou décale leur déclenchement après le premier rendu utile de la page, pour qu’ils ne rivalisent pas avec l’affichage initial.
3. Les chat widgets (Tidio, Crisp, Intercom)
Le problème : un widget de chat charge une iframe, des polices, des scripts de connexion temps réel. La petite bulle en bas à droite cache un gros morceau de code. Et il se charge souvent dès l’arrivée sur la page, qu’on l’ouvre ou non. Ce chargement initial occupe le fil principal au pire moment, pendant que le visiteur découvre ta page et commence à interagir.
Comment l’identifier : dans DevTools, regarde l’activité au chargement initial et au clic sur la bulle. Les fichiers tidio, crisp ou intercom apparaîtront dans les tâches longues. Si une grosse tâche tierce s’exécute dès les premières secondes alors que tu n’as encore rien fait, c’est souvent le chat.
Comment corriger : configure le widget pour qu’il se charge en différé, après l’interaction utilisateur plutôt qu’au démarrage. La plupart de ces outils proposent un mode de chargement « à la demande » dans leurs réglages, où la bulle n’apparaît qu’après le premier défilement ou un court délai. Si tu réponds rarement en chat, demande-toi honnêtement si l’app justifie son coût en performance.
4. Les programmes de fidélité (Smile.io, LoyaltyLion)
Le problème : ces apps affichent un widget de points, un panneau de récompenses, parfois un onglet flottant. Elles vérifient le statut du client, calculent des soldes, synchronisent avec ton back-office. Tout ça génère du JavaScript actif sur le fil principal, parfois dès le chargement, alors que la majorité des visiteurs ne sont même pas connectés.
Comment l’identifier : enregistre l’ouverture du panneau de fidélité dans DevTools. Une tâche longue au clic sur le widget pointe directement vers l’app. Cherche smile, loyaltylion ou le nom de ton programme. Regarde aussi s’il y a une requête réseau au chargement de chaque page, signe que l’app interroge ton statut client à chaque visite.
Comment corriger : limite l’affichage du widget aux pages où il a du sens (compte client, panier). Évite de le charger sur chaque page produit, où il n’apporte rien à l’acte d’achat. Vérifie que le panneau se charge à l’ouverture et non en arrière-plan dès l’arrivée du visiteur.
5. Les carrousels d’upsell (ReConvert, Honeycomb)
Le problème : les apps d’upsell et de cross-sell affichent des carrousels de produits recommandés, souvent dans le panier ou après l’ajout. Elles calculent des recommandations en direct, chargent des images et animent un slider. Au moment précis où le visiteur ajoute au panier (interaction critique), elles déclenchent leur logique. C’est le pire timing possible : l’app travaille pile quand le visiteur attend que son article entre dans le panier.
Comment l’identifier : enregistre dans DevTools l’ajout au panier puis l’ouverture du tiroir de panier. Les long tasks rattachées à reconvert, honeycomb ou ton app d’upsell sortiront clairement. Surveille la durée de l’interaction « ajout au panier » dans la piste Interactions : si elle s’envole, l’upsell est rarement étranger au problème.
Comment corriger : limite le nombre de produits affichés dans le carrousel (moins d’images, moins de calcul). Active le chargement différé du slider, pour qu’il se construise après que le panier a répondu, pas avant. Et teste sans l’app pendant quelques jours : si ton chiffre d’upsell ne bouge pas mais que ton INP s’améliore, la réponse est faite.
INP, LCP, CLS : ne pas confondre
Les Core Web Vitals comptent trois métriques. On les mélange souvent. Voici la distinction nette.
-
LCP (Largest Contentful Paint) mesure la vitesse de chargement. Plus exactement, le temps que met le plus gros élément visible (souvent ton image hero ou ton titre) à s’afficher. C’est une question de « combien de temps avant que la page paraisse prête ».
-
INP (Interaction to Next Paint) mesure la réactivité. Le délai entre l’action du visiteur et la réponse à l’écran. C’est une question de « est-ce que le site répond vite quand je clique ».
-
CLS (Cumulative Layout Shift) mesure la stabilité visuelle. À quel point les éléments bougent pendant le chargement (le bouton qui se décale au moment où tu allais cliquer). C’est une question de « est-ce que la page reste stable sous mes yeux ».
LCP, c’est avant le clic. INP, c’est pendant et après le clic. CLS, c’est le confort visuel pendant que tout se met en place. Une façon simple de retenir : LCP juge l’attente initiale, INP juge la conversation entre ton doigt et l’écran, CLS juge la nervosité de la page.
Cette distinction a une conséquence pratique. Les optimisations classiques pour aller vite au chargement (compresser les images, précharger la police) améliorent surtout LCP. Elles ne font presque rien pour INP, parce que le problème d’INP n’est pas le poids des fichiers mais le temps que le fil principal passe à exécuter du JavaScript. Tu peux donc avoir une boutique légère, qui charge vite, et qui répond mal aux clics.
Les trois doivent être au vert pour que ta page passe le seuil « page experience » de Google. Une boutique Shopify peut parfaitement réussir LCP et CLS tout en échouant sur INP, à cause des apps. C’est même le cas le plus fréquent que je rencontre : un site qui paraît rapide à l’ouverture, mais qui se traîne dès qu’on commence à cliquer.
INP en 2026 : action immédiate ou attente subie
INP n’est pas une mode passagère. Depuis mars 2024, c’est un Core Web Vital à part entière, et en 2026 il pèse sur ton référencement comme sur ta conversion. La différence avec FID est radicale : il suffit d’une interaction lente pour plomber ton score.
Récapitulons les cinq coupables habituels sur Shopify. Les apps de reviews qui chargent partout. Les popups marketing qui écoutent en continu. Les chat widgets qui s’invitent dès le démarrage. Les programmes de fidélité qui calculent en arrière-plan. Les carrousels d’upsell qui se déclenchent au pire moment, pendant l’ajout au panier.
Pour chacun, la démarche est la même : mesurer avec PageSpeed et CrUX, diagnostiquer dans DevTools Performance avec la limitation processeur activée, puis corriger en différant le chargement, en limitant la portée du widget ou en désinstallant ce qui ne sert plus. Rien d’inaccessible. Juste de la méthode, appliquée dans l’ordre.
Tu hésites entre faire l’audit toi-même ou le confier ? J’ai comparé DIY vs expert en détail. Et si tu veux d’abord chiffrer ce que tes apps coûtent vraiment à ta boutique, j’ai écrit un article complet là-dessus.
Le choix se résume à deux options. Tu traites ton INP maintenant, pendant qu’il est encore un avantage compétitif. Ou tu attends, et tu subis la lente érosion de ton trafic et de tes ventes pendant que tes concurrents prennent les devants.
