Core Web Vitals 2026 : pourquoi la quasi-totalité des sites Shopify Plus échouent à INP

Depuis le 12 mars 2024, l’indicateur Interaction to Next Paint a officiellement remplacé First Input Delay au sein des Core Web Vitals de Google¹. Cette substitution n’est pas anodine : alors que FID mesurait uniquement le délai de la première interaction, INP mesure le pire délai d’interaction sur l’ensemble du parcours utilisateur, à l’échelle du 75e centile. C’est-à-dire que la métrique reflète désormais l’expérience réellement vécue par les utilisateurs réels, et non plus une fenêtre arbitraire en début de session.

Le seuil considéré comme bon par Google s’établit à 200 millisecondes ; au-delà de 500 millisecondes, l’expérience est jugée mauvaise. Or, à l’examen des données publiques que je tire de l’audit annuel du Web Almanac et des distributions du Chrome User Experience Report², une observation s’impose : la quasi-totalité des sites Shopify Plus du segment mid-market que j’audite échouent à passer ce seuil sur mobile. Le chiffre exact varie selon la définition de l’échantillon, mais l’ordre de grandeur converge autour de 90 à 95 % de sites en zone rouge ou jaune.

Cette défaillance généralisée n’est pas accidentelle. Elle résulte de quatre patterns architecturaux récurrents, qui se cumulent et se renforcent mutuellement sur les sites Shopify Plus contemporains. Le présent essai identifie chacun d’entre eux, chiffre leur impact en latence d’interaction, et expose la méthode de remédiation que j’applique en mandat de Diagnostic Stack.

INP, ce que la métrique mesure réellement

Avant d’entrer dans la pathologie, il faut comprendre la mesure. INP capture, sur la durée d’une session de visite, le délai maximum entre une interaction utilisateur — clic, frappe clavier, tap tactile — et la prochaine repeinte du navigateur, c’est-à-dire le moment où l’écran reflète visuellement le résultat de cette interaction. La métrique n’est ni un temps de chargement initial ni une simple latence de réponse : elle agrège la chaîne complète, depuis le déclenchement de l’événement, son traitement par le moteur JavaScript, le calcul de mise en page, et la repeinte effective.

Dans une architecture commerciale, les interactions critiques sont identifiables : ouverture du tiroir panier, ouverture du sélecteur de variante produit, ouverture de la barre de recherche, déploiement du mega-menu de navigation, application d’un filtre sur une page de collection. Si l’une seulement de ces interactions dépasse régulièrement les 500 millisecondes au 75e centile, la note INP du site bascule en zone rouge. Et Google utilise cette note comme signal de classement direct.

1. Le tiroir panier hydraté côté client

Le pattern le plus fréquemment responsable d’un INP dégradé sur Shopify Plus est l’architecture du cart drawer — le tiroir panier qui s’ouvre par-dessus la page lorsque l’utilisateur clique sur l’icône panier ou ajoute un produit.

Dans une majorité d’implémentations contemporaines, ce tiroir charge un volume substantiel de JavaScript au moment de la première interaction : composant de rendu, gestion d’état, scripts d’upsell, intégration du système de fidélité, bannière promotionnelle dynamique, recommandations de produits complémentaires. L’hydratation initiale, qui devrait s’exécuter en moins de 50 ms pour respecter INP, dépasse couramment 400 ms sur du mobile mid-range.

L’origine technique est connue : la long task qui bloque le thread principal pendant l’évaluation des scripts impose que la repeinte attende. L’utilisateur clique, ne voit rien pendant 300 à 600 ms, puis voit s’animer le drawer. La perception est celle d’une lenteur, mais la cause technique est précise et mesurable.

Remédiation typique. Préchargement minimal du composant tiroir au moment du page load, avec une stratégie de bundle splitting qui découple la logique de fidélité, les recommandations et les bannières promotionnelles. Ces éléments secondaires sont chargés en post-interaction, après la repeinte initiale du tiroir. Gain mesuré sur les audits récents : entre 250 et 400 ms sur l’INP des interactions panier.

2. La barre de recherche Shopify Search & Discovery

La fonctionnalité Shopify Search & Discovery, déployée par défaut sur les boutiques Plus, charge un module de recherche full-text avec autocomplétion qui pèse entre 80 et 150 ko de JavaScript supplémentaires. Sur une boutique au catalogue conséquent, l’index est volumineux et son chargement à la première interaction sur la barre de recherche provoque un blocage du thread principal sur des durées comparables au tiroir panier.

S’y ajoute une particularité défavorable : la barre de recherche est souvent placée dans le header sticky, et son module se charge fréquemment au premier scroll plutôt qu’à la première interaction. Cela transforme le scroll lui-même en interaction lente, ce qui dégrade encore l’INP global.

Remédiation typique. Découpage du module de recherche en deux étapes — un noyau minimal pour l’ouverture du champ de saisie, et un module d’autocomplétion chargé sur la première frappe. Si le volume du catalogue le justifie, externalisation de l’index vers un service tiers léger comme Algolia ou Typesense, dont les SDK clients pèsent typiquement moins de 30 ko gzippés. Gain mesuré : 150 à 250 ms.

3. La cascade d’App Blocks

Shopify Plus s’appuie sur une architecture d’App Blocks — composants tiers injectés via le thème — qui, dans la pratique, se cumulent jusqu’à représenter 10 à 20 blocs distincts par page de produit ou de collection. Chaque App Block charge ses propres dépendances et exécute son propre script d’initialisation.

L’effet macro est mesurable : sur les pages produits que j’audite régulièrement, la phase d’hydratation des App Blocks bloque le thread principal pendant des fenêtres cumulées de 500 à 1 200 ms après le DOMContentLoaded. Toute interaction utilisateur arrivant dans cette fenêtre se trouve mécaniquement retardée. Or les utilisateurs cliquent vite, souvent avant que le navigateur ait fini d’hydrater l’arbre complet.

Remédiation typique. Inventaire systématique des App Blocks installés, qualification de leur valeur ajoutée réelle — mesurée en lift de conversion ou en revenu attribuable —, et désinstallation des blocs dont la valeur ne justifie pas leur empreinte performance. La majorité des audits que je conduis identifient entre quatre et sept blocs supprimables sans impact business mesurable. Pour les blocs conservés, négociation avec le fournisseur pour activer un mode defer ou async — la plupart des éditeurs sérieux proposent désormais cette option, mais ne l’activent pas par défaut. Gain mesuré : 200 à 500 ms selon la sévérité initiale.

4. Les third-party tags et leur effet domino

Les pixels marketing — Klaviyo, Yotpo, Recharge, Meta Pixel, TikTok Pixel, Google Tag Manager, et la liste s’allonge — partagent une caractéristique commune : ils s’instancient le plus tôt possible, souvent dans le <head> même de la page, afin de collecter les événements utilisateur dès le début de la session.

Or chaque pixel introduit un bloc de scripts tiers chargés depuis un domaine externe, soumis à la latence réseau et aux contraintes de connexion TLS. Sur mobile en réseau dégradé — situation récurrente dans la zone urbaine canadienne moyenne — la cascade de scripts tiers consomme à elle seule entre 800 et 1 500 ms de thread principal sur la fenêtre des cinq premières secondes de visite.

L’effet sur INP est indirect mais réel : les interactions utilisateur qui surviennent durant cette fenêtre de blocage tiers héritent d’une latence dégradée qui leur est partiellement attribuée par la métrique. La page paraît lente précisément parce qu’elle est lente, et la responsabilité technique est identifiable.

Remédiation typique. Audit du tag manager et qualification de chaque pixel sur la base de sa valeur business démontrable. Migration des pixels conservés vers une architecture server-side lorsque le fournisseur la supporte — typiquement Meta CAPI, Google Server-side GTM, Klaviyo Server-side. Le gain perf est substantiel parce que la charge se déplace du thread principal du client vers une infrastructure serveur qui n’affecte pas l’expérience utilisateur. Gain mesuré : 300 à 700 ms selon le volume initial de pixels.

INP ne mesure pas la performance d’un site. Il mesure l’écart entre la promesse interactive faite à l’utilisateur et la réalité technique livrée sur son appareil.

La méthode de Diagnostic Stack

L’identification de ces quatre patterns s’effectue, dans la pratique du Diagnostic Stack que j’opère, en trois temps successifs.

Premier temps : la collecte des données réelles. Extraction des champs CrUX historiques sur le domaine audité (lorsque le site dispose d’un volume de visite suffisant pour figurer dans la base), couplée à une session de mesure synthétique sur Lighthouse en mode mobile, en simulation 4G dégradée et CPU 4× ralenti. Ces deux mesures cadrent l’écart entre le terrain réel et le synthétique.

Deuxième temps : l’identification des bottlenecks. Profiling Chrome DevTools en mode performance, sur les interactions critiques cataloguées en amont (panier, recherche, filtre, navigation, formulaire). Chaque interaction lente est annotée avec la stack de scripts responsable et la durée précise du blocage thread principal.

Troisième temps : la priorisation par effet levier. Classement des bottlenecks identifiés par le rapport entre gain INP attendu et coût de remédiation. Les patterns qui produisent les plus grands gains pour le moindre coût d’intervention sont priorisés. La roadmap remise au client distingue les quick wins — actions sous deux semaines, ROI immédiat — des refactors plus structurants qui justifient une migration headless ou une refonte d’architecture.

L’objectif assumé du livrable est de permettre à la direction technique du client de décider, sur des bases chiffrées, entre une remédiation incrémentale sur Shopify Plus et un changement de paradigme architectural. Les deux options ont leur logique selon le profil de la marque, l’enveloppe disponible et les ambitions de croissance. Mais aucune ne se décide sans un examen rigoureux des données qui le justifient.

Pourquoi cette défaillance est générale

Une dernière observation sociologique. Si la quasi-totalité des sites Shopify Plus mid-market échouent à INP, c’est moins par négligence individuelle des marques que par une combinaison de facteurs structurels du marché : la facilité d’installation d’apps tierces masque leur coût performance cumulé, le thème Dawn et ses dérivés privilégient la flexibilité fonctionnelle sur la rigueur architecturale, et l’écosystème d’agences Shopify Plus est, dans sa majorité, plus optimisé pour la livraison rapide que pour l’audit de performance.

Cette défaillance générale crée, paradoxalement, une opportunité asymétrique : les marques qui investissent dans une remédiation INP sérieuse en 2026 gagnent un avantage compétitif mesurable sur la majorité de leur cohorte qui ne le fera pas. L’effet sur le classement organique Google, sur le taux de conversion mobile, et sur le coût d’acquisition payante est documenté et réplicable.

Le Diagnostic Stack opéré par NOKARIS fournit le cadre méthodologique de cette remédiation. Forfait fixe de 7 500 dollars CAD, livré en 10 jours ouvrés, garantie remboursée si l’audit ne révèle ni surprise stack ni quick win actionnable sous deux semaines.

---

Footnotes

1. Web.dev, Interaction to Next Paint (INP) : web.dev/articles/inp. Documentation officielle de Google sur la métrique, ses seuils et sa méthodologie de mesure. ↩

2. Web Almanac (HTTP Archive), chapitres annuels sur la performance et le commerce électronique : almanac.httparchive.org. Chrome UX Report : g.co/chrome-ux-report. Les distributions exactes varient annuellement ; les ordres de grandeur cités dans cet essai reflètent les données publiques disponibles au moment de la rédaction. ↩