INP : le Core Web Vital de la réactivité

Quand un visiteur clique sur un bouton, ouvre un menu ou remplit un champ, il attend une réponse visible en une fraction de seconde. L'INP (Interaction to Next Paint) mesure exactement ce délai : le temps entre l'action de l'utilisateur et le moment où le navigateur affiche effectivement un changement à l'écran. Contrairement à un simple temps de chargement, l'INP capture la réactivité réelle d'une page une fois qu'elle est utilisée, pas seulement au moment où elle apparaît. C'est aujourd'hui l'un des trois Core Web Vitals de Google, aux côtés du LCP (vitesse de chargement) et du CLS (stabilité visuelle), et il a remplacé le FID (First Input Delay) en 2024 parce que ce dernier donnait une image beaucoup trop favorable de la plupart des sites.

Pour un site avec des menus déroulants, des filtres, des formulaires ou des composants interactifs, l'INP est souvent l'indicateur le plus révélateur de l'expérience réelle vécue par les visiteurs, bien plus que le temps de chargement initial. Comprendre ce qu'il mesure, ce qui le dégrade et comment le corriger permet de traiter un problème que les audits de vitesse classiques passent souvent sous silence.

Que mesure l'INP, précisément ?

L'INP observe toutes les interactions qui se produisent pendant la visite d'un utilisateur : clics, appuis sur mobile, frappes clavier qui déclenchent une réaction visible. Pour chacune, le navigateur calcule le temps écoulé entre l'action et la mise à jour visuelle suivante, le prochain paint. Contrairement à ce que mesurait son prédécesseur, l'INP ne s'arrête pas à la première interaction de la session : il suit l'ensemble des interactions, du premier clic jusqu'au dernier, sur toute la durée de la visite.

Le score retenu n'est pas la moyenne de ces mesures : pour chaque visite, c'est l'interaction la plus lente qui compte (en écartant une valeur extrême toutes les 50 interactions sur les sessions très interactives), puis la page est évaluée au 75e percentile de ces valeurs sur l'ensemble des visites. Ce choix est délibéré : une moyenne lisserait les ratés et masquerait les moments où un utilisateur a réellement attendu, agacé, qu'un menu daigne s'ouvrir. En se calant sur les interactions les plus lentes plutôt que sur la médiane, l'INP reflète ce qu'une partie significative des visiteurs a réellement ressenti, pas la performance dans le meilleur des cas.

Pourquoi l'INP a remplacé le FID

Le FID (First Input Delay) ne mesurait que la première interaction d'une session, et seulement une partie de cette interaction : le délai avant que le navigateur commence à traiter l'événement, sans compter le temps nécessaire pour exécuter le code correspondant ni celui pour rafraîchir l'affichage. Un site pouvait donc afficher un excellent score FID tout en restant capable de figer complètement l'interface dès le deuxième clic, un cas fréquent sur les pages chargées de scripts tiers qui ne se déclenchent qu'après les premières secondes.

Cette limite explique en grande partie pourquoi le FID donnait de bons résultats à la quasi-totalité des sites analysés : il flattait la mesure en ignorant le traitement effectif de l'action et tout ce qui se passait après le premier geste. L'INP corrige les deux angles morts à la fois : il couvre l'intégralité de l'interaction, pas seulement le délai d'entrée, et l'intégralité de la visite, pas seulement le premier clic.

Les trois temps d'une interaction

Chaque interaction mesurée par l'INP se décompose en trois phases, et un ralentissement peut venir de n'importe laquelle des trois. En pratique, la majorité des mauvais scores INP viennent d'un thread principal saturé, donc du délai d'entrée ou du temps de traitement, plutôt que d'un problème de rendu pur, mais les trois valent la peine d'être comprises séparément.

• Le délai d'entrée (input delay) : le temps entre l'action de l'utilisateur et le moment où le navigateur commence à exécuter le gestionnaire d'événement correspondant. Il est généralement provoqué par un thread principal déjà occupé par une autre tâche, souvent un script tiers ou une opération de rendu en cours.
• Le temps de traitement (processing time) : la durée d'exécution du code déclenché par l'interaction elle-même, la fonction JavaScript qui gère le clic, met à jour un état, effectue un calcul ou lance un rendu.
• Le délai de présentation (presentation delay) : le temps entre la fin du traitement et l'affichage effectif du changement à l'écran, ce qui inclut le rendu, le recalcul de la mise en page et l'affichage du prochain frame par le navigateur.

Les causes les plus fréquentes d'un mauvais INP

Dans l'immense majorité des cas, un mauvais INP a la même origine : trop de JavaScript qui s'exécute au mauvais moment sur le thread principal. Ces causes se cumulent souvent entre elles, un gestionnaire de tags charge un script tiers qui, une fois exécuté, attache un gestionnaire d'événement lourd qui, à son tour, déclenche une mise à jour massive du DOM au moment précis où l'utilisateur clique. Les coupables reviennent régulièrement d'un site à l'autre :

• Les tâches longues (long tasks) : tout bloc de JavaScript qui occupe le thread principal plus de 50 millisecondes empêche le navigateur de répondre aux interactions pendant toute sa durée. Un enchaînement de plusieurs tâches longues peut faire dépasser plusieurs centaines de millisecondes à une interaction pourtant simple.
• Les scripts tiers surdimensionnés et les gestionnaires de tags : outils d'analytics, chats en direct, widgets publicitaires, outils d'A/B testing, chacun ajoute son propre JavaScript, souvent chargé et exécuté sans coordination avec le reste de la page, et capable à lui seul de saturer le thread principal au moment précis où l'utilisateur interagit.
• Les gestionnaires d'événements trop lourds : un clic qui déclenche un recalcul complexe, un appel réseau bloquant ou une manipulation extensive du DOM avant de rendre la main au navigateur.
• Les mises à jour massives du DOM : remplacer ou réorganiser un grand nombre d'éléments d'un coup, un tableau entier, une liste longue, une grille de résultats, force le navigateur à recalculer le style et la mise en page de tout ce bloc avant de pouvoir peindre le prochain frame.

Diagnostiquer l'INP : les données de terrain avant les outils de laboratoire

L'INP doit se diagnostiquer d'abord avec des données de terrain, des mesures issues de visiteurs réels comme celles remontées par le Chrome User Experience Report (CrUX), le rapport Core Web Vitals de Google Search Console, ou un outil de RUM (Real User Monitoring) installé sur le site. Ces données reflètent des appareils, des connexions et des comportements réels, avec toute leur variété : un utilisateur sur un téléphone d'entrée de gamme en réseau mobile ne vivra jamais la même interaction qu'un testeur sur un poste de développement performant.

Les outils de laboratoire, Lighthouse, PageSpeed Insights en mode lab, ou les tests locaux dans les outils de développement du navigateur, ont une limite structurelle sur l'INP : ils ne peuvent simuler que des interactions scriptées, généralement simples, sur un environnement contrôlé. Ils passent à côté des cas réels les plus problématiques : un utilisateur qui clique deux fois de suite parce que rien ne semble se passer, qui interagit pendant qu'un script tiers finit de se charger, ou qui utilise un appareil bien plus lent que celui du test. Un score Lighthouse excellent peut donc coexister avec un INP de terrain médiocre, c'est même un scénario courant, pas une anomalie.

Le bon ordre est donc de partir des données de terrain pour confirmer qu'il y a un problème et identifier sur quels types de pages ou d'appareils il se concentre, puis d'utiliser les outils de laboratoire, notamment le panneau Performance des outils de développement du navigateur, pour reproduire une interaction lente, isoler la tâche longue responsable et remonter jusqu'au script en cause.

Corriger l'INP : ce qui fonctionne réellement

Une fois la ou les tâches longues identifiées, les correctifs efficaces relèvent presque tous de la même logique : rendre la main au navigateur plus souvent, et plus tôt. Aucun ne demande de réécrire l'application, la plupart consistent à réorganiser du code existant pour qu'il coopère avec le thread principal au lieu de le monopoliser.

• Découper les tâches longues : diviser une opération JavaScript coûteuse en plusieurs morceaux plus courts, exécutés successivement, plutôt qu'en un seul bloc ininterrompu. Chaque découpage donne au navigateur une occasion de traiter une interaction en attente.
• Céder la main au thread principal : utiliser des mécanismes comme scheduler.yield(), un setTimeout avec un délai nul ou requestIdleCallback pour interrompre volontairement un traitement long et laisser passer les événements utilisateur en attente avant de reprendre.
• Différer le travail non critique : retarder l'exécution de tout ce qui n'est pas nécessaire à l'interaction immédiate, initialisation de widgets secondaires, envoi d'événements de tracking, préchargement de contenu hors écran, jusqu'à ce que le thread principal soit inactif.
• Réduire la charge des scripts tiers : auditer régulièrement ce qui est réellement chargé, supprimer les outils redondants ou inutilisés, charger les scripts non essentiels de façon asynchrone ou différée, et envisager un chargement conditionnel, par exemple ne charger un chat en direct qu'au survol ou au clic sur son icône.
• Surveiller le coût de rendu des frameworks : les bibliothèques JavaScript modernes peuvent déclencher des re-rendus en cascade à chaque interaction si l'état est mal découpé ou si des composants se re-rendent sans nécessité. Mémoriser les calculs coûteux, limiter la portée des mises à jour d'état et éviter de recalculer des listes entières pour un seul élément modifié réduit directement le temps de traitement.

Quels objectifs viser, et comment prioriser l'INP

Un INP est considéré comme bon en dessous de 200 millisecondes, à améliorer entre 200 et 500 millisecondes, et médiocre au-delà de 500 millisecondes, mesuré au 75e percentile des visites. Ces seuils s'appliquent page par page : un site peut afficher un excellent INP sur ses pages de contenu statique et un score médiocre sur une page de recherche interne ou un configurateur de produit riche en interactions, ce sont précisément les pages où corriger l'INP a le plus d'impact perçu.

En termes de priorité face aux deux autres Core Web Vitals, l'INP mérite une attention particulière sur tout site où les visiteurs interagissent réellement avec la page après son chargement : e-commerce avec filtres et paniers, applications web, formulaires complexes, interfaces de recherche. Sur un site essentiellement éditorial où l'interaction se limite à faire défiler et cliquer un lien, le LCP et le CLS resteront souvent les leviers les plus rentables. Le bon réflexe est de croiser le rapport Core Web Vitals de Search Console avec le type de page concerné avant de décider où investir le temps de développement : corriger l'INP d'une page que personne n'utilise de façon interactive n'apporte rien, alors que le même effort sur une page de recherche à fort trafic peut changer la perception de vitesse pour une grande partie des visiteurs.