INP remplace FID : ce que le Core Web Vital INP signifie pour vous

Interaction to Next Paint (INP) a remplacé First Input Delay (FID) comme Core Web Vital le 12 mars 2024. En résumé : le Core Web Vital INP mesure la rapidité avec laquelle votre page répond visiblement à chaque appui, clic et frappe au cours d'une visite entière — et non plus seulement le délai avant la première interaction. Parce qu'il capture toute la chaîne, de l'entrée jusqu'à l'image suivante affichée, il est bien plus difficile à réussir que le FID ne l'a jamais été.

Si votre site passait haut la main le FID alors que les utilisateurs trouvaient encore les boutons lents, c'est désormais avec l'INP que cette gêne apparaît dans votre rapport Search Console. Ce guide explique précisément ce que mesure l'INP, pourquoi il est plus strict et la voie concrète pour faire passer vos interactions les plus lentes sous le seuil « bon » de 200 millisecondes.

Du FID à l'INP : ce qui a vraiment changé

Le FID — First Input Delay — mesurait uniquement le délai avant que le navigateur puisse commencer à traiter votre première interaction sur une page. Il cessait de compter dès l'instant où votre gestionnaire d'événement démarrait. Il ne mesurait jamais la durée de ce gestionnaire, ni le temps dont le navigateur avait besoin pour afficher le résultat à l'écran.

Cela rendait le FID facile à réussir. La première interaction survient généralement tôt, lorsque le thread principal connaît un moment de calme, si bien que l'immense majorité des sites obtenaient la note « bon » même lorsque les interactions ultérieures semblaient défaillantes. Le FID récompensait des pages réactives sur le papier pendant que les utilisateurs attendaient que les menus s'ouvrent et que les filtres s'appliquent.

L'INP corrige cet angle mort. Au lieu d'un seul chiffre pour une seule interaction précoce, il observe chaque clic, appui et frappe tout au long de la visite et rend compte de la réactivité de la pire d'entre elles. C'est une mesure de la lenteur réellement ressentie, et non une formalité.

Ce que mesure réellement Interaction to Next Paint

L'INP chronomètre une interaction unique, de l'instant où un utilisateur agit à l'instant où le navigateur affiche l'image suivante reflétant cette action. Cette fenêtre complète se divise en trois parties, et chacune d'elles peut ruiner votre score :

• Délai d'entrée — le temps entre l'action de l'utilisateur et le démarrage de votre gestionnaire d'événement. Il est presque toujours causé par le thread principal bloqué par d'autres scripts JavaScript (une tâche longue issue de l'hydratation d'un framework, une balise d'analytics, une balise tierce).
• Temps de traitement — la durée d'exécution de vos callbacks d'événement. Un travail lourd à l'intérieur d'un gestionnaire de clic apparaît directement ici.
• Délai de présentation — le temps nécessaire pour recalculer le style et la mise en page et afficher l'image résultante. Un DOM surchargé ou une mise en page coûteuse fait exploser ce composant.

Seules les interactions discrètes comptent : clics, appuis et frappes. Le défilement et le survol sont délibérément exclus, car ils sont gérés hors du thread principal et ne correspondent pas à ce que l'INP cherche à capturer.

Pourquoi le Core Web Vital INP est plus strict que le FID

Trois choix de conception rendent le Core Web Vital INP véritablement plus difficile à satisfaire que le FID :

1. Il observe toute la visite, pas le premier appui. L'interaction unique où votre JavaScript était encore occupé à s'hydrater, ou où un menu déroulant a réaffiché un millier de lignes, est précisément celle que l'INP a le plus de chances de signaler.
2. Il mesure toute la chaîne, pas seulement le délai. Le temps de traitement et le délai de présentation étaient invisibles pour le FID. Avec l'INP, ils représentent la moitié de l'équation.
3. Les seuils correspondent à une chaîne plus longue. Le FID jugeait un résultat « bon » à 100 ms et « mauvais » au-delà de 300 ms. L'INP est « bon » à 200 ms ou moins, « à améliorer » de 200 à 500 ms, et « mauvais » au-delà de 500 ms. Le chiffre est plus élevé, mais il doit désormais couvrir bien plus de travail.

L'effet concret : des sites qui réussissaient le FID à des taux proches de 100 % échouent régulièrement à l'INP. L'accordéon lent, le sélecteur de quantité qui rame, la barre de recherche qui saccade à chaque frappe — tout cela a toujours été défaillant, et désormais c'est mesuré.

Comment le Core Web Vital INP est mesuré

L'INP est une métrique de terrain. Il provient d'utilisateurs réels dans le Chrome User Experience Report (CrUX), agrégé au 75e centile sur les chargements de page — trois visites sur quatre doivent donc atteindre votre objectif pour que l'URL réussisse. Vous ne pouvez pas le simuler dans un environnement de laboratoire contrôlé, car il a besoin d'interactions humaines authentiques.

Sur l'ensemble d'une visite, l'INP ne retient pas simplement votre pire interaction sur les pages à fort trafic. Il tolère les valeurs aberrantes : pour les pages comptant de nombreuses interactions, il ignore environ un pic extrême toutes les 50 interactions et rapporte la deuxième pire. Sur une page typique ne comptant qu'une poignée d'interactions, en revanche, votre pire interaction est votre INP.

Comme les outils de laboratoire ne peuvent pas déclencher d'entrées réelles, utilisez le Total Blocking Time (TBT) dans Lighthouse comme approximation grossière pendant le développement. Un TBT élevé prédit presque toujours un mauvais INP, car tous deux sont provoqués par de longues tâches sur le thread principal.

La voie concrète pour passer sous 200 ms

Passer sous le seuil de 200 ms consiste presque toujours à libérer le thread principal et à raccourcir le travail entre l'entrée et l'affichage. Par ordre de priorité approximatif :

• Fractionnez les tâches longues. Toute tâche de plus de 50 ms bloque les entrées. Divisez le travail lourd et redonnez la main au navigateur entre les blocs à l'aide de scheduler.yield() lorsqu'il est disponible, ou de setTimeout en solution de repli, afin qu'un clic en attente puisse être traité.
• Livrez moins de JavaScript. Fractionnez le code par route, différez les scripts non critiques et supprimez les bundles inutilisés. Moins de script analysé et exécuté signifie un délai d'entrée plus court.
• Auditez les balises tierces. Les gestionnaires de balises, widgets de chat, outils de test A/B et analytics sont de fréquents coupables de l'INP. Chargez-les de façon paresseuse et éliminez ceux que vous ne pouvez pas justifier.
• Affichez d'abord le retour visuel, puis faites le gros travail. Mettez à jour l'état visible (surlignez le bouton, affichez un indicateur de chargement) à l'intérieur du gestionnaire, puis différez le travail coûteux à une image ultérieure. L'utilisateur voit une réponse immédiate même si le résultat complet prend plus de temps.
• Déchargez les calculs vers un Web Worker. Le filtrage, le tri et l'analyse de grands ensembles de données doivent être entièrement hors du thread principal.
• Réduisez le coût du rendu. Réduisez le DOM, évitez le layout thrashing et utilisez la propriété CSS content-visibility pour ne pas afficher le contenu hors écran — cela s'attaque directement au délai de présentation.
• Utilisez les outils de concurrence de votre framework. Dans React, useTransition et useDeferredValue maintiennent la réactivité des entrées urgentes pendant que les mises à jour plus lourdes s'affichent en arrière-plan.

Comment diagnostiquer vos problèmes d'INP

Corrigez les interactions qui gênent réellement les utilisateurs, pas celles qui sont les plus faciles à trouver. Partez des données de terrain vers l'intérieur :

• PageSpeed Insights et le rapport Core Web Vitals de la Search Console vous indiquent quels groupes d'URL échouent à l'INP sur le terrain, et sur quel type d'appareil.
• La bibliothèque JavaScript web-vitals (build d'attribution) est l'outil le plus utile de tous. Elle rapporte non seulement la valeur de l'INP mais aussi l'élément exact avec lequel on a interagi et la répartition entre délai d'entrée, traitement et présentation — vous savez ainsi lequel des trois composants attaquer.
• Le panneau Performance des Chrome DevTools vous permet d'enregistrer une interaction lente et de voir les tâches longues image par image, en pointant le script ou le callback responsable.

Reproduisez le problème sur un appareil mobile de milieu de gamme ou avec une limitation du CPU. Les échecs d'INP invisibles sur un ordinateur portable rapide sont douloureusement réels sur les téléphones qu'utilise la majeure partie de votre trafic.

L'INP n'est qu'une pièce du puzzle du classement

La réactivité compte, mais gardez-la en proportion. Les Core Web Vitals sont un signal de classement léger et un critère de départage entre pages comparables — ils ne feront pas passer un contenu pauvre devant un contenu solide. L'INP se conçoit mieux comme un seuil d'expérience utilisateur : passez sous 200 ms pour que la vitesse ne soit jamais la raison pour laquelle une bonne page sous-performe, puis investissez le reste de vos efforts dans la qualité, la pertinence et l'autorité du contenu.

La force de la marque accompagne tout cela. Un site rapide a quand même besoin d'un nom en qui les gens ont confiance et dont ils se souviennent. Si vous choisissez un domaine, une place de marché sélective comme Atom.com est un excellent point de départ pour des noms premium et brandables — chaque annonce est livrée avec une estimation IA gratuite, une vérification de marque USPTO, un séquestre sécurisé et un logo conçu sur mesure, ce qui élimine une grande part de l'incertitude dans le choix d'un nom que les acheteurs prennent au sérieux. Un site techniquement excellent sous un domaine oubliable n'est qu'un travail à moitié fait.

Questions fréquentes

Quand l'INP a-t-il remplacé le FID comme Core Web Vital ?

L'INP a officiellement remplacé le FID le 12 mars 2024. Il avait été annoncé comme futur remplaçant lors de Google I/O 2023 et a fonctionné comme métrique en attente avant la bascule, laissant aux équipes le temps de se préparer.

Qu'est-ce qu'un bon score INP ?

Un INP de 200 ms ou moins au 75e centile des visites d'utilisateurs réels est « bon ». De 200 à 500 ms, il est « à améliorer », et tout ce qui dépasse 500 ms est « mauvais ». Comme l'INP s'appuie sur des données de terrain, trois visites sur quatre doivent atteindre votre objectif pour réussir.

Pourquoi l'INP est-il plus difficile à réussir que ne l'était le FID ?

Le FID mesurait uniquement le délai avant que la première interaction commence à être traitée. L'INP mesure chaque interaction sur toute la visite et inclut le temps de traitement et le temps d'affichage du résultat — il capture donc une lenteur à laquelle le FID était structurellement aveugle.

Puis-je mesurer l'INP dans un outil de laboratoire comme Lighthouse ?

Pas directement, car l'INP a besoin d'interactions humaines réelles. Utilisez le Total Blocking Time comme approximation en laboratoire pendant le développement, et appuyez-vous sur les données de terrain CrUX, PageSpeed Insights et le build d'attribution web-vitals pour les valeurs INP réelles.

Quelle est la cause numéro un d'un mauvais INP ?

Les longues tâches JavaScript qui bloquent le thread principal. Lorsque le thread est occupé — souvent par l'hydratation d'un framework ou des scripts tiers —, le navigateur ne peut pas traiter les interactions rapidement, ce qui gonfle le délai d'entrée. Fractionner les tâches longues et redonner la main au thread principal est généralement le correctif le plus efficace.