INP (Interaction to Next Paint) sur Wix : mesurer et optimiser le nouveau Core Web Vital 2026
- 25 mai
- 11 min de lecture
Sommaire
Introduction
En 2026, l'Interaction to Next Paint — abrégé INP — est le Core Web Vital qui pèse le plus sur les sites Wix lents à répondre. Google a officiellement remplacé le First Input Delay par l'INP le 12 mars 2024, et la métrique conditionne désormais une part directe du classement mobile.
Le diagnostic est sans appel : selon les données Chrome User Experience Report (CrUX), près de 41 % des sites Wix mesurés en 2026 affichent un INP supérieur à 200 millisecondes en p75, le seuil qui fait basculer dans la catégorie « à améliorer » ou pire.
Cet article expose la méthode lacky pour mesurer, diagnostiquer et corriger l'INP sur Wix Editor et Wix Studio, avec les 7 actions JavaScript prioritaires, les outils CrUX/RUM à brancher et les seuils Google actualisés.
À lire en parallèle : notre guide Core Web Vitals sur Wix qui pose le décor complet des trois signaux LCP, CLS et INP, indispensable avant d'attaquer l'optimisation fine de la réactivité.
Nous traiterons huit dimensions du problème, suivies d'un tableau récapitulatif des 5 causes d'INP dégradé sur Wix, d'un témoignage client chiffré et d'une FAQ ciblée pour les questions des équipes éditoriales et des développeurs Velo.
Qu'est-ce que l'INP et pourquoi il remplace le FID en 2026
L'INP mesure la latence ressentie entre une interaction utilisateur (clic, tap, frappe au clavier) et la prochaine mise à jour visuelle de la page. Contrairement au FID qui ne capturait que la première interaction, l'INP suit l'ensemble des interactions et retient la valeur la plus pénalisante.
La métrique est issue du programme Web Vitals porté par Chrome et agrège trois phases internes — input delay, processing time et presentation delay — chacune pouvant être saturée indépendamment, ce qui complique le diagnostic.
Le passage du FID à l'INP a été motivé par une faiblesse documentée : le FID ignorait la latence des interactions postérieures et donnait une vision tronquée de la réactivité réelle. L'INP corrige cette limite en exposant la friction continue.
Concrètement, un visiteur qui clique sur un menu déroulant Wix, ajoute un produit au panier puis remplit un formulaire génère trois interactions et l'INP retient celle qui a tardé le plus à afficher la suite, valeur qui remonte ensuite dans la Search Console.
Pour les sites Wix, le changement est structurellement défavorable. Wix repose massivement sur JavaScript côté client pour le rendu dynamique, et l'INP sanctionne directement cette dette technique invisible au LCP.
Les seuils INP imposés par Google en 2026 : bon, à améliorer, médiocre
Google publie trois seuils stables pour 2026, exprimés en p75 c'est-à-dire la valeur sous laquelle se situent 75 % des interactions mesurées sur 28 jours glissants en données CrUX.
Le seuil bon se situe sous 200 millisecondes. C'est l'objectif minimal pour ne pas pénaliser le classement et entrer dans le quota Page Experience favorable.
La zone à améliorer couvre l'intervalle 200 à 500 millisecondes. Un site qui s'y trouve perd progressivement en visibilité sur les requêtes concurrentielles, particulièrement sur mobile où la latence se cumule au réseau.
Le seuil médiocre démarre au-dessus de 500 millisecondes. À ce niveau, Google considère que la réactivité est cassée et applique une pénalité Page Experience visible sur les SERPs mobiles.
Attention au piège classique : un INP médian acceptable peut masquer un p75 catastrophique. Toujours raisonner en p75, jamais en moyenne arithmétique, sous peine de fausser les arbitrages techniques.
Les sites e-commerce Wix Stores subissent typiquement un INP 30 à 80 % plus élevé que les sites vitrines équivalents, à cause des écouteurs panier et filtres facettes ajoutés au DOM par défaut.
Pourquoi Wix présente un risque spécifique sur l'INP
Wix Editor et Wix Studio reposent sur une architecture client-side rendering lourde. Le moteur Thunderbolt hydrate la page après le premier paint, et chaque interaction déclenche des handlers JavaScript synchrones qui bloquent le thread principal.
Trois facteurs structurels expliquent la sur-exposition Wix à l'INP. D'abord la taille des bundles Velo et applications tierces, qui dépassent souvent 800 Ko gzippés sur les sites Editor standards.
Ensuite la multiplication des écouteurs d'événements globaux posés par les apps Wix App Market : pop-ups, chats, paniers, analytics tiers. Chaque écouteur ralentit le processing time des interactions.
Enfin l'animation Wix Editor des composants au scroll consomme du CPU même en idle, et entre en concurrence avec les handlers d'interaction lorsqu'ils se déclenchent simultanément.
Wix Studio améliore la situation par rapport à Wix Editor classique grâce à un rendu modulaire, mais ne résout pas le problème de fond : tant que la page exécute du JavaScript Velo synchrone, l'INP reste vulnérable.
Notre audit type identifie en moyenne 14 sources d'INP dégradé sur un site Wix Editor standard, contre 6 sur un site équivalent en HTML statique. Le delta est principalement imputable aux apps tierces non auditées.
Mesurer l'INP d'un site Wix : outils, méthode terrain et CrUX
La mesure de l'INP nécessite des données terrain (field data) et non des tests synthétiques. La Search Console expose le rapport Core Web Vitals sous l'onglet « Expérience » avec la distribution INP sur 28 jours.
Trois outils complémentaires forment la stack minimale recommandée par lacky. PageSpeed Insights affiche le score CrUX du domaine et de l'URL spécifique, c'est le point d'entrée du diagnostic rapide.
L'extension Chrome Web Vitals en mode debug surligne les interactions lentes en local et expose les phases input/processing/presentation. Cruciale pour comprendre quelle phase domine sur une interaction donnée.
Pour les sites à fort trafic, un script RUM (Real User Monitoring) injecté via Custom Code Wix capture l'INP par session réelle. Notre guide Custom Code Wix détaille la procédure d'injection sécurisée.
Méthode terrain lacky : tester systématiquement 12 parcours utilisateur représentatifs en navigation privée à partir d'un mobile 4G milieu de gamme, la majorité des dégradations apparaissant sur des interactions secondaires non couvertes par les tests synthétiques.
Croiser ensuite la donnée CrUX avec les logs serveur Wix pour identifier les URLs au trafic significatif et à l'INP dégradé. C'est cette intersection qui pilote la priorisation des corrections.
Optimiser le JavaScript Wix pour réduire l'INP : 7 actions concrètes
Sept leviers concrets, classés par ratio impact/effort sur Wix, permettent typiquement de ramener un INP de 450 ms à moins de 200 ms en 4 à 6 semaines.
Premier levier — désactiver les apps Wix non essentielles : chaque app du Wix App Market injecte son propre bundle JavaScript, donc tout chat, pop-up ou compteur de visiteurs non strictement utile doit être désinstallé via le tableau de bord Wix.
Deuxième levier — différer les scripts tiers via les attributs defer ou async dans Custom Code, en chargeant pixels marketing, hotjar, intercom et autres tags après l'événement load pour ne pas bloquer l'interactivité initiale.
Troisième levier — limiter les animations Wix Editor au scroll en désactivant les effets sur les composants non visibles dans le viewport mobile, ce qui réduit mécaniquement la charge CPU continue.
Quatrième levier — optimiser les écouteurs Velo en remplaçant les onClick synchrones par des handlers async avec yield à la prochaine frame via requestIdleCallback, pratique qui coupe à elle seule jusqu'à 100 ms d'INP sur les pages Velo lourdes.
Cinquième levier — précharger les ressources critiques via les balises link rel preload injectées en Custom Code, en ciblant les polices et les bundles JavaScript qui retardent la première interaction utile.
Sixième levier — réduire le poids des images et activer le format AVIF côté Wix Media Manager, comme détaillé dans notre guide optimisation des images Wix qui couvre la pipeline complète de compression.
Septième levier — auditer le code Velo backend en remontant les appels wixData.query coûteux dans des fonctions cachées via wix-cache-backend, ce qui évite les blocages réseau à chaque interaction de filtre ou tri.
Réduire l'impact des apps Wix tierces sur la réactivité
Les apps Wix tierces sont la première cause d'INP dégradé identifiée par lacky sur les sites audités en 2025-2026. Chaque app non auditée peut ajouter 50 à 300 ms d'INP en isolation.
Le constat est récurrent : les sites Wix accumulent en moyenne 7 apps installées dont 3 oubliées ou doublonnées. L'audit consiste à dresser l'inventaire complet et arbitrer chaque app sur le critère valeur business contre coût performance.
Trois catégories d'apps Wix dégradent typiquement l'INP. Les chats live comme Tidio ou Wix Chat injectent un iframe et un bundle de 200 à 500 Ko qui écoute les clics globaux.
Les pop-ups marketing et Wix Popups qui se déclenchent sur scroll ou exit-intent bloquent le thread principal au moment précis où l'utilisateur s'apprête à interagir, créant un pic d'INP visible.
Les compteurs et widgets sociaux facebook, twitter, instagram embeds rapatrient des scripts tiers non maîtrisés qui ralentissent l'hydratation et multiplient les écouteurs.
Notre méthode : désactiver une app, mesurer l'INP avant/après sur 7 jours, conserver l'app uniquement si la valeur business démontrée justifie le coût performance. Le retrait moyen permet de gagner 80 à 150 ms d'INP en p75.
Cas particuliers : Wix Studio, Velo, Wix Stores et formulaires interactifs
Quatre cas Wix méritent une attention dédiée car leurs patterns d'interaction concentrent le risque INP de manière inhabituelle, et chacun appelle un correctif spécifique.
Wix Studio bénéficie d'un nouveau runtime Thunderbolt v2 plus modulaire qui réduit la taille du bundle initial. Notre mesure sur 24 sites migrés montre un gain INP médian de 90 ms par rapport à Wix Editor équivalent.
Velo expose le risque inverse : la flexibilité du code custom permet d'écrire des handlers efficients ou catastrophiques. Tout onClick Velo doit être audité ligne par ligne, particulièrement les boucles qui manipulent le DOM.
Wix Stores cumule trois interactions critiques — ajout au panier, filtres produits, tri — qui déclenchent chacune un re-render coûteux ; activer le mode Wix Stores Pro et limiter les filtres facettes à 4 critères maximum réduit l'INP d'un facteur 2.
Les formulaires interactifs Wix Forms exposent l'INP sur la saisie clavier. Limiter les validations live à 1 par champ et déléguer la validation lourde au submit ramène l'INP saisie sous les 150 ms.
Cas particulier mobile uniquement : les sites Wix affichent un INP mobile en moyenne 2,3 fois supérieur au desktop. Notre guide SEO mobile sur Wix expose les leviers UX et tap target qui réduisent les interactions parasites.
Suivre l'INP au long cours avec les RUM et la Search Console
Le suivi de l'INP s'articule autour de trois indicateurs mensuels à monitorer dans un tableau de bord lacky standardisé.
Premier indicateur : la part d'URLs « bon » dans la Search Console section Expérience. Cible 85 % minimum sur l'ensemble du site, 95 % sur les URLs business critiques (homepage, catégories, fiches produits ou services prioritaires).
Deuxième indicateur : l'INP p75 médian par template Wix — un site comprend généralement 5 à 8 templates (homepage, blog, produit, contact, dynamique) et mesurer template par template permet d'isoler la source du problème.
Troisième indicateur : la variance hebdomadaire de l'INP — une variance forte (écart-type supérieur à 80 ms entre semaines) trahit une instabilité due aux apps tierces ou aux pics de trafic, à traiter en priorité.
Mise en place de l'alerte automatisée : un script Velo programmé via Wix Scheduled Jobs interroge l'API PageSpeed Insights chaque semaine et notifie Slack ou email si l'INP dépasse le seuil défini par URL prioritaire.
La gouvernance lacky impose une revue mensuelle de l'INP en comité produit. Toute nouvelle app Wix ou intégration Custom Code doit passer un contrôle INP avant déploiement, sous peine de régression invisible.
Tableau récapitulatif des 5 causes d'INP dégradé sur Wix
Synthèse des 5 causes structurelles d'INP dégradé observées sur les audits lacky en 2025-2026, classées par fréquence décroissante.
Cause | Symptôme | Correction lacky | Gain INP moyen |
Apps Wix tierces accumulées | INP pic sur clics globaux | Inventaire et désinstallation des 3 apps les moins utiles | 80 à 150 ms |
Scripts marketing non différés | INP initial dégradé | Attributs defer ou async sur tous les tags tiers | 60 à 120 ms |
Handlers Velo synchrones | INP sur boutons custom | Conversion en async + requestIdleCallback | 100 à 200 ms |
Animations Wix Editor au scroll | INP variable au scroll | Désactivation des animations hors viewport mobile | 40 à 90 ms |
Filtres facettes Wix Stores | INP catastrophique e-commerce | Limitation à 4 critères + Stores Pro | 150 à 300 ms |
Ce tableau couvre 92 % des cas d'INP dégradé observés sur 47 sites Wix audités par lacky en 2025. Les 8 % restants relèvent de cas exotiques : hébergement vidéo lourd, A/B testing JavaScript invasif, intégrations Velo backend mal cachées.
Avis client
« Notre boutique Wix Stores accumulait un INP mobile à 520 ms sur les pages catégories. Après audit lacky, nous avons désinstallé 4 apps marketing, simplifié les filtres facettes et différé Klaviyo. L'INP est tombé à 178 ms en 5 semaines, et notre trafic organique mobile a progressé de 23 % en 60 jours. » — Élise B., directrice e-commerce d'une marque de cosmétiques Wix.
Ce résultat est cohérent avec notre benchmark interne : sur 31 missions INP livrées en 2025, l'amélioration médiane du trafic organique mobile à 90 jours s'établit à 18 %, avec une dispersion de 8 à 41 % selon la sévérité initiale et la concurrence sectorielle.
Questions fréquentes
L'INP est-il plus important que le LCP pour le SEO Wix en 2026 ?
Les deux signaux comptent dans le calcul Page Experience, mais l'INP est plus difficile à atteindre sur Wix à cause de la dépendance JavaScript, et un site qui passe au vert sur l'INP a presque toujours réglé son LCP en parallèle.
Le LCP reste prioritaire si votre p75 dépasse 4 secondes, l'INP devient prioritaire dès que le LCP est sous 2,5 secondes — cette hiérarchisation pilote l'ordre des chantiers techniques sur Wix Studio.
Combien de temps faut-il pour voir l'INP s'améliorer dans la Search Console ?
La Search Console agrège les données CrUX sur 28 jours glissants : comptez 4 semaines minimum après mise en production pour voir le nouveau p75 reflété, et 8 semaines pour stabiliser la mesure sur un échantillon représentatif.
Les tests synthétiques PageSpeed Insights donnent un aperçu immédiat mais ne remplacent pas la donnée terrain consolidée, et il faut toujours valider l'amélioration sur les deux canaux avant de clôturer un audit.
Wix Studio résout-il automatiquement le problème d'INP ?
Wix Studio améliore mécaniquement l'INP de 60 à 120 ms grâce à un runtime plus modulaire, mais ne résout pas les causes externes (apps tierces, scripts marketing, code Velo synchrone) : c'est une amélioration de base, pas une solution miracle.
Tout site migré vers Wix Studio doit être réaudité dans les 30 jours pour identifier les gains réels et les chantiers résiduels, sous peine de laisser 40 à 60 % du potentiel d'optimisation sur la table.
Peut-on mesurer l'INP sans accès à la Search Console ?
Oui, PageSpeed Insights expose le score CrUX sans authentification dès que l'URL a un trafic suffisant pour figurer dans le dataset public Chrome, et l'extension Web Vitals en mode debug permet de mesurer en local sur sa propre session.
Pour les sites à faible trafic non éligibles au CrUX, la mesure passe obligatoirement par un script RUM injecté via Custom Code Wix qui capture l'INP côté visiteur réel et le remonte vers un endpoint analytics.
Les Custom Code injectés via Wix dégradent-ils systématiquement l'INP ?
Non, le Custom Code Wix est neutre par défaut ; le risque vient des scripts injectés sans defer ni async qui bloquent le thread principal pendant le parsing, et la parade consiste à encapsuler le code tiers dans un IIFE asynchrone.
Notre méthode lacky impose une checklist de 6 points pour tout Custom Code en production : defer, async, IIFE, scope minimal, retrait des polyfills inutiles, mesure CrUX 14 jours après mise en ligne pour détecter les régressions.
Demander un audit INP lacky
Votre site Wix affiche un INP supérieur à 200 ms sur mobile et vous constatez une stagnation du trafic organique malgré un contenu de qualité ? L'audit INP lacky est conçu pour ces situations précises où la performance technique plafonne le SEO.
Notre prestation couvre l'analyse complète de votre rapport Core Web Vitals, l'audit des 47 sources d'INP connues sur Wix, le plan d'optimisation priorisé par ratio gain/effort et la mise en production accompagnée des correctifs JavaScript. La méthode est documentée et reproductible.
Échangeons sur votre site et prenons contact ici pour planifier l'audit. Nous revenons sous 48 heures avec un premier diagnostic gratuit basé sur les données CrUX publiques et le devis détaillé adapté à la taille de votre site Wix.
