Remonter à la ligne de code défaillante d'un INP dans Seven Branches

Un score INP rouge n'indique pas un problème de performance tant que l'on n'a pas identifié la phase qui consomme le plus de temps. La plupart des équipes négligent cette étape, achètent un plugin de cache ou reportent l'exécution d'un script, et constatent que le 75e percentile reste bloqué. Ce guide présente l'arbre de décision que nous utilisons à la place : sept branches qui vous mènent d'un score INP rouge (rapport Chrome UX) erroné au gestionnaire, script ou balise tierce responsable, avec un seuil défini à chaque bifurcation. Il est destiné aux responsables front-end et aux équipes de croissance qui gèrent un taux de conversion ainsi qu'un score Lighthouse.

L'écart est bien réel. Dans l'Almanach Web 2025, 77 % des origines mobiles avaient un bon INP contre 97 % sur ordinateur de bureau, et seulement 48 % des origines mobiles ont satisfait aux trois critères essentiels du Web. (Archive HTTPCe qui reste problématique sur mobile, c'est principalement la latence d'interaction, et c'est généralement facile à diagnostiquer.

Ce que l'INP mesure, et ce qu'elle ignore discrètement

Interaction to Next Paint signale une latence d'interaction par visite de page, au niveau de 75e centile à travers votre origine. C'est bien 200 ms ou moins, nécessite des améliorations si le temps de réponse est supérieur à 200 ms et inférieur ou égal à 500 ms, est médiocre si le temps de réponse est supérieur à 500 ms (web.devTrois éléments de cette définition modifient la façon dont vous la déboguez :

• Seuls les clics, les tapotements et les frappes au clavier sont comptabilisés. Le survol, le zoom et Les défilements ne sont pas mesurés, donc un défilement saccadé peut donner l'impression qu'une page est cassée alors que l'INP reste vert.
• Sur les pages comportant de nombreuses interactions, INP ignore une interaction maximale pour 50Ainsi, une interaction catastrophique rare peut se cacher sur une page à fort engagement et faire surface sur une page à faible engagement.
• Chaque interaction se divise en délai d'entrée (avant l'exécution de vos gestionnaires), durée de traitement (vos gestionnaires en cours d'exécution) et retard de présentation (après vos manipulateurs, avant les peintures du cadre). Ces trois éléments n'ont presque rien en commun en tant que problèmes d'ingénierie (web.dev).

Ce dernier point résume toute la méthode. Vous ne déboguez pas « INP », mais l'une des trois phases, et chacune a une solution différente.

Branche 0 : vérifiez que le numéro est réel avant de toucher au code.

Ouvrez PageSpeed ​​Insights et consultez la section relative aux champs, et non le score du laboratoire. Les outils de laboratoire ne peuvent pas mesurer l'INP, car celui-ci nécessite une interaction réelle de l'utilisateur. Si l'origine ne contient aucune donnée de champ, il s'agit d'un problème de trafic, et non de performance ; les points suivants ne s'appliquent donc pas encore. Ensuite, analysez les données mobiles et de bureau séparément : en 2025, l'écart était de 20 points de pourcentage à l'échelle mondiale. Si le score mobile est rouge et le score de bureau vert, arrêtez les tests sur votre ordinateur portable.

Branche 1 : l’interaction lente se produit-elle pendant ou après le chargement ?

Instrumenter le terrain avec le web-vitals Construction de l'attribution. Quatre lignes vous donnent les données :

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

Lire attribution.loadState tout d'abord. Si la plupart des mauvaises interactions entraînent un état de charge de chargement or dom-interactifLes utilisateurs cliquent alors que vos scripts sont encore en cours d'évaluation : il s'agit d'un problème de diffusion, résolu au niveau du bundle et du gestionnaire de balises, et non au niveau du gestionnaire. Si les interactions problématiques se produisent sur des pages entièrement chargées, passez à la branche 2.

Branche 2 : quelle sous-partie possède le temps ?

Historique inputDelay, processingDuration et presentationDelay pour chaque échantillon. Notre règle de travail : une sous-partie est responsable de l’interaction lorsqu’elle prend en compte plus de 50 % du total des INPSi aucun ne dépasse 50 %, traitez-le d'abord comme un cas de délai d'entrée — une congestion diffuse du thread principal est généralement ce qui aggrave les deux autres.

Branche 3 : nommer le script

La configuration d'attribution comporte des entrées Long Animation Frame pour chaque échantillon INP. attribution.longestScript vous donne l'invocateur, la fonction et le fichier source du pire script dans l'interaction ; totalScriptDuration Il regroupe tout ce qui dépasse 5 ms. C'est là qu'un vague « React est lent » se transforme en chemin de fichier. Vérifiez le type d'invocateur : classic-script or module-script points lors de l'évaluation du temps de chargement, tandis que user-callback or event-listener indique un élément s'exécutant après le chargement — un observateur, une minuterie, un écouteur d'analyse (web.dev).

Branche 4 : est-ce la vôtre ou celle d’un tiers ?

Triez l'attribution de vos scripts par origine. Les gestionnaires de balises, les plateformes de consentement, les outils d'enregistrement de session et les widgets de chat installent des écouteurs globaux qui s'exécutent avant les vôtres à chaque clic. Si une origine tierce apparaît dans plus d'un quart de vos pires exemples, la solution est d'ordre commercial avant d'être technique : réduisez la portée de la balise, chargez-la lors de l'interaction ou déplacez-la côté serveur. Ne modifiez pas votre gestionnaire pour récupérer 40 ms que le widget de chat consomme de toute façon.

Branche 5 : reproduire le problème en laboratoire, puis corriger le cadre.

Prenez le sélecteur de attribution.interactionTargetOuvrez les outils de développement Chrome avec la limitation de fréquence du processeur adaptée à votre configuration d'appareils de terrain et enregistrez l'interaction. Recherchez une tâche sur 50 ms, le seuil de tâche longue (web.dev), et la diviser en cédant.

Expédier scheduler.yield() avec une solution de repli. Chrome et Edge la prennent en charge depuis la version 129 et Firefox depuis la version 142, mais Safari ne le fait pas, ni sur ordinateur ni sur iOS., et MDN indique une disponibilité limitée plutôt que de base (mdn, puis-je utiliser). Pour un public turc ou du Golfe disposant d'une part importante d'utilisateurs iOS, un setTimeout Le plan de repli n'est pas optionnel.

Branche 6 : Mesurer le marché auquel vous vendez réellement.

Les moyennes globales de CrUX masquent le marché qui vous rémunère. L'ensemble de données CrUX BigQuery publie des tableaux par pays. chrome-ux-report.country_tr.YYYYMM Pour la Turquie, le même modèle s'applique à tous les codes pays à deux lettres : il est mis à jour mensuellement, avec le format de l'appareil et le type de connexion effectif comme dimensions (Chrome pour les développeursL'API publique de CrUX n'expose pas le pays ; cette donnée est donc réservée à BigQuery.

Vérifiez l'origine de votre système par rapport au tableau des pays pour chaque marché où vous vendez. Un détaillant présent en Turquie, en Allemagne et dans les pays du Golfe constate régulièrement trois distributions INP différentes à partir d'une même base de code, en raison des différences de parc d'appareils et de conditions réseau. Concentrez-vous sur le marché le plus rentable, et non sur celui où se trouve votre siège social.

Branche 7 : prouver qu’il a déplacé quelque chose

Considérez cette solution comme une expérience, et non comme un déploiement. TrendyolUne plateforme de marché turque a identifié une interruption de service mobile (INP) de 963 ms comme étant due à une tâche de 700 à 900 ms provoquée par un rappel IntersectionObserver dans un composant React, et a différé la mise à jour de l'état. scheduler.yield()et a réduit le 75e percentile de l'INP d'environ 1 400 ms à environ 650 ms en six mois. Son test A/B a montré un Augmentation de 1 % du taux de clics des annonces vers les détails des produits par session (web.dev). RedBus a réduit les interactions à chargement différé de 870–900 ms à 350–370 ms, amélioré l'interaction de saisie de texte de 72 % et a rapporté un augmentation de 7 % des ventes totales (web.dev).

Notez l'échelle réelle : 1 %, et non 40 %. Ce qui nous amène à un chiffre qu'il convient de corriger.

Le chiffre de 8.4 % mérite d'être nuancé.

Le chiffre le plus souvent cité dans ce domaine est qu'une amélioration de 0.1 s de la vitesse mobile augmente la conversion dans le commerce de détail de 8.4 % et dans les voyages de 10.1 %. Il provient d'une étude réelle — 55 et Deloitte, commandée par Google, portant sur 37 marques et plus de 30 millions de sessions (web.devMais il mesurait des indicateurs de charge tels que le temps de chargement des pages et la latence du serveur. pas INPLes données couvrent 30 jours à la fin de 2019 ; en l’absence de groupe témoin, il s’agit d’une corrélation observée et non d’un effet causal. Utilisez-les pour amorcer une discussion budgétaire, et non pour prévoir le retour sur investissement d’une correction du temps de latence d’interaction.

[DONNÉES INTERNES NÉCESSAIRES : Switas avant/après p75 INP et delta de conversion provenant d'une mission client, afin de remplacer les études de cas publiques par des preuves de première main.]

Où cet arbre de décision dysfonctionne

• Origines à faible trafic. Avec des données peu nombreuses, le 75e percentile représente du bruit. En dessous d'environ 1 000 interactions par modèle et par semaine, effectuez un profilage en laboratoire et acceptez l'impossibilité de vérifier le résultat dans CrUX.
• Les utilisateurs de Safari et Firefox sont invisibles. CrUX est exclusivement compatible avec Chrome. Si une part significative de vos revenus provient de Safari sur iOS, vos données INP décrivent une population que vous ne mesurez pas pleinement.
• Les saccades de défilement ne sont pas prises en compte. INP ignore le défilement, donc cet arbre ne trouvera jamais le problème dans une liste à défilement infini qui est désagréable à regarder mais dont les tests sont au vert.
• Il détecte la latence, pas la dette technique. Une interaction de 180 ms sur un panneau de filtres confus est un problème d'expérience utilisateur que cet arbre de décision ne peut pas détecter.

QFP

INP est-il la même chose que le délai de première entrée ?
Non. FID mesurait uniquement le délai avant l'exécution des gestionnaires de la première interaction. INP couvre la latence complète d'une interaction représentative tout au long de la visite, y compris l'exécution des gestionnaires et l'affichage qui suit.

Pourquoi mon score Lighthouse semble-t-il correct alors que mon score INP est rouge ?
Lighthouse est un outil de laboratoire et ne peut pas mesurer l'INP : aucun utilisateur réel n'interagit avec le contenu. Les indicateurs indirects, comme le temps de blocage total, présentent une corrélation approximative. Consultez plutôt la section relative aux champs dans PageSpeed ​​Insights.

Combien de temps faudra-t-il avant qu'un correctif apparaisse dans CrUX ?
CrUX effectue ses rapports sur une période glissante de 28 jours, tandis que les tables BigQuery sont mises à jour mensuellement. Attendez-vous à un signal partiel après environ quatre semaines et à une lecture complète après deux mises à jour mensuelles.

Puis-je réparer INP sans toucher au framework ?
Souvent oui. La solution de Trendyol consistait à utiliser `yield` dans une fonction de rappel sur React 16.9, sans mise à jour. Le report des balises tierces est également indépendant du framework.

Une bannière de consentement a-t-elle une incidence sur l'INP ?
Cela peut se produire de deux manières : le script de la bannière entre en conflit avec le thread principal lors du chargement, et la décision de consentement déclenche souvent un chargement massif de balises immédiatement après. Mesurez séparément la première interaction après le consentement.

Ai-je besoin d'un fournisseur RUM, ou la bibliothèque web-vitals est-elle suffisante ?
L'outil d'attribution et un point de terminaison de balise suffisent pour faire fonctionner cet arbre. Un fournisseur achète la fidélisation, la segmentation et les tableaux de bord, pas des données d'attribution plus précises.

Dois-je optimiser INP pour le référencement naturel ou pour la conversion ?
Optez pour la conversion. Les indicateurs Web essentiels sont un signal de classement, mais les cas concrets (1 % chez Trendyol, 7 % chez redBus) démontrent des effets sur la qualité de l'interaction qui justifient à eux seuls le travail accompli.

Intégrez ceci sur votre propre page d'annonces

Prenez votre modèle le plus utilisé, équipez-le avec le système d'attribution et parcourez les branches 0 à 7 dans l'ordre. Si vous préférez exécuter l'arbre de décision sur vos propres données de terrain, avec la segmentation par pays et le plan d'expérience inclus, notre équipe de performance web fait exactement cela.

Références

• Interaction avec Next Paint (INP) — web.dev
• Optimisation de l'interaction pour Next Paint — web.dev
• Trouver des interactions lentes sur le terrain — web.dev
• Optimisation des tâches longues — web.dev
• Performances — Web Almanac 2025, Archives HTTP
• Comment Trendyol a réduit l'INP de 50 % — web.dev
• Comment redBus a amélioré son INP et augmenté ses ventes de 7 % — web.dev
• Des millisecondes qui valent des millions — web.dev / 55 / Deloitte
• CrUX sur BigQuery — Chrome pour les développeurs
• Planificateur : yield() — MDN
• API du planificateur : rendement - caniuse
• Bibliothèque JavaScript web-vitals — GoogleChrome/web-vitals