INP : Le Core Web Vital Qui a Remplacé le FID (et Comment le Corriger)

Qu'est-ce que l'INP ?

L'INP (Interaction to Next Paint) mesure le délai entre le moment où un visiteur interagit avec votre page — un clic, un appui tactile, une frappe au clavier — et le moment où l'écran affiche visuellement le résultat de cette action. Il a remplacé le FID (First Input Delay) parmi les Core Web Vitals officiels le 12 mars 2024.

Le seuil à retenir : un INP inférieur ou égal à 200 millisecondes est bon, entre 200 et 500 millisecondes perfectible, au-delà de 500 millisecondes mauvais. Comme les autres Core Web Vitals, il s'évalue au 75e centile des visites réelles.

Pourquoi ce changement a fait mal à tant de sites

Le FID ne mesurait qu'une seule chose : le délai avant que le navigateur commence à traiter la première interaction. Un site pouvait donc afficher un excellent FID tout en étant pénible à utiliser. La première interaction partait vite, les suivantes traînaient.

L'INP corrige ce biais. Il observe l'ensemble des interactions de la visite et retient la plus lente — en écartant les valeurs aberrantes sur les pages qui en comptent beaucoup. Conséquence directe : de nombreux sites classés « bons » sous FID sont passés en « perfectible » du jour au lendemain, sans qu'une ligne de code ait changé.

Les trois phases d'une interaction

Un INP dégradé se décompose toujours en trois segments :

1. Le délai d'entrée : le fil d'exécution principal est occupé et ne peut pas prendre l'événement en compte.
2. Le temps de traitement : l'exécution de vos gestionnaires d'événements.
3. Le délai de présentation : le calcul des styles, la mise en page et le rendu de la nouvelle image.

Identifier lequel des trois domine détermine entièrement le correctif à appliquer. Optimiser le mauvais segment ne produit aucun gain mesurable.

Pourquoi un site Next.js échoue à l'INP

Trop de JavaScript côté client

Dans l'App Router, les composants sont des Server Components par défaut. Une directive "use client" posée trop haut dans l'arbre bascule tout le sous-arbre côté navigateur : le bundle grossit, l'hydratation s'allonge et le fil principal reste occupé plus longtemps. C'est de loin la cause la plus fréquente d'un délai d'entrée élevé.

La règle tient en une phrase : descendez "use client" au plus près du composant réellement interactif. Un bouton n'a pas besoin que toute sa page devienne cliente.

Les scripts tiers

Gestionnaire de balises, widget de chat, outil de test A/B, bandeau de consentement : chacun exécute du JavaScript sur le même fil principal que votre interface. Un seul script mal chargé suffit à générer des tâches longues — celles qui dépassent 50 millisecondes — pendant lesquelles aucune interaction ne peut être traitée.

Sur Next.js, le composant next/script permet de contrôler ce moment précis. Tout ce qui n'est pas nécessaire à l'affichage initial doit être différé.

Diagnostiquer sur le terrain, jamais en laboratoire

C'est le point où la plupart des audits se trompent. Un rapport Lighthouse n'affiche pas d'INP, et pour une bonne raison : il n'y a personne pour cliquer. La métrique n'existe que sur des interactions réelles.

Votre source de vérité est donc la donnée terrain : le rapport d'expérience utilisateur Chrome, visible dans PageSpeed Insights et dans la Search Console, ou une mesure directe en production via la bibliothèque officielle web-vitals. Cette seconde approche a un avantage décisif : elle remonte l'élément exact et le segment responsable, là où le rapport agrégé ne donne qu'un score.

Les correctifs qui fonctionnent réellement

• Découpez les tâches longues. Un traitement de 300 millisecondes bloque toute interaction pendant 300 millisecondes. Fractionné en segments courts avec des points de reprise, il laisse le navigateur répondre entre deux.
• Affichez d'abord, calculez ensuite. Mettez à jour l'interface immédiatement, puis lancez le travail secondaire — journalisation, analytics, préchargement. L'utilisateur juge ce qu'il voit, pas ce qui s'exécute en arrière-plan.
• Hiérarchisez vos mises à jour React. startTransition marque une mise à jour comme non urgente : React garde alors la priorité aux interactions, au lieu de figer l'interface pendant un rendu lourd.
• Allégez le rendu. Un DOM démesuré rallonge mécaniquement le délai de présentation. Sur les listes longues, la virtualisation reste le levier le plus rentable.

Passez à l'action

L'INP est la métrique qui traduit le mieux ce qu'un visiteur ressent réellement : une interface qui répond, ou une interface qui hésite. Contrairement au LCP, il ne se corrige pas en optimisant une image — il exige de regarder ce que votre JavaScript fait au fil principal.

Securium Agency audite les Core Web Vitals sur données terrain, identifie les interactions responsables de votre INP et corrige la cause plutôt que le symptôme. Demandez un audit de performance gratuit : nous vous remettons vos scores réels, les segments fautifs et un plan de correction priorisé par gain attendu.