Guides

Les 200 millisecondes qui poussent les utilisateurs hors du SaaS

Une interface SaaS semble lente bien avant que cela ne soit mesurable. L'Interaction to Next Paint mesure cette hésitation et influence le classement et…

Par Benedikt Langer 17 juillet 2026 5 min de lecture

Les 200 millisecondes qui poussent les utilisateurs hors du SaaS

Une interface SaaS semble lente bien avant qu’elle ne le soit de manière mesurable. L’utilisateur clique. Pendant un battement de cils, rien ne se passe. C’est précisément cette hésitation que mesure l’Interaction to Next Paint. Cette valeur influence le classement Google et, plus encore, détermine si une application donne une impression de fluidité ou de lourdeur.

Les points clés en bref

INP a remplacé FID. Depuis mars 2024, l’Interaction to Next Paint est un Core Web Vital. Elle mesure le délai sur l’ensemble des interactions d’une session, et pas seulement le premier clic. Objectif : rester sous les 200 millisecondes.
Le main thread est le goulot d’étranglement. De mauvais scores INP proviennent presque toujours d’un blocage du Main Thread par JavaScript. L’interface ne peut se rafraîchir qu’une fois le travail terminé.
Les SaaS sont plus touchées que les sites de contenu. Les applications interactives vivent de clics, d’entrées et de changements d’état. Chacune de ces interactions entre dans le calcul de l’INP.

En lien :Le Model Context Protocol sous l’égide de la Linux Foundation / Grok 4.5 dans Cursor : bloqué dans l’UE pour l’instant

Pourquoi FID ne suffisait plus

Le First Input Delay ne mesurait que le délai de la première interaction sur une page. Pour les sites web classiques, c’était un indicateur utile. Mais pour une application SaaS, où les utilisateurs cliquent, filtrent et saisissent pendant des minutes, cela restait insuffisant. Le premier clic ne dit rien de la sensation après dix minutes d’utilisation.

L’Interaction to Next Paint comble cette lacune. Elle prend en compte pratiquement toutes les interactions d’une session et rapporte la valeur représentative la plus mauvaise. Ainsi, l’INP mesure ce que les utilisateurs vivent réellement : la réactivité sur toute la durée d’utilisation. Pour les interfaces interactives, c’est un critère plus honnête.

Où les millisecondes s’envolent

Dans la quasi-totalité des cas, la cause réside dans le Main Thread. Le navigateur traite les interactions, le rendu et JavaScript sur le même fil d’exécution. Si une tâche longue s’y exécute, la réaction au clic doit attendre. L’utilisateur perçoit cela comme un à-coup ou un délai avant qu’un élément ne bouge à l’écran.

En pratique, trois schémas reviennent. Des bundles JavaScript trop volumineux, qui génèrent du travail au chargement et à chaque interaction. Des re-rendus coûteux, où un clic recalcule toute une hiérarchie de composants. Et des handlers synchrones qui effectuent des opérations réseau ou de calcul avant de libérer l’interface. Pour améliorer l’INP, c’est là qu’il faut chercher.

Les leviers les plus efficaces

Le premier levier est la division. Les longues tâches peuvent être découpées en morceaux plus petits, permettant au navigateur de réagir aux entrées entre chaque segment. Les approches modernes repoussent le travail non critique après la réaction proprement dite, par exemple en cédant explicitement la main au scheduler. L’utilisateur voit immédiatement un retour, le reste du travail s’exécute ensuite.

Le deuxième levier consiste à charger moins de code au bon moment. Le code-splitting ne charge que ce dont l’écran actuel a besoin. Le troisième est la discipline de rendu : éviter les re-rendus inutiles, mémoïser les calculs coûteux, virtualiser les grandes listes. Aucune astuce seule ne fait la différence. C’est la somme des décisions qui détermine si une interaction reste sous les 200 millisecondes.

Mesurer en conditions réelles

Un test en laboratoire dans le navigateur du développeur est trompeur. Il s’exécute sur du matériel rapide avec une bonne connexion et capture rarement les interactions qui posent problème au quotidien. Les données de terrain issues d’utilisateurs réels sont bien plus significatives. Le Chrome UX Report les fournit de manière agrégée, tandis qu’une collecte personnalisée via la bibliothèque Web Vitals révèle quelles interactions génèrent concrètement les mauvais résultats.

La voie pragmatique : recueillir des données de terrain, identifier les interactions les plus problématiques et optimiser précisément ces points. Qui bidouille aveuglément des zones supposément lentes gaspille son temps sur des symptômes que personne ne ressent. INP n’est pas une simple case à cocher pour le SEO. C’est l’indicateur qui détermine si le logiciel offre une bonne expérience.

Foire aux questions

Qu’est-ce que l’Interaction to Next Paint (INP) ?

L’INP est un Core Web Vital de Google. Il mesure la rapidité avec laquelle un site web ou une application réagit visiblement aux interactions des utilisateurs, comme les clics, les taps et les saisies au clavier. L’évaluation porte sur le délai durant toute la session, et non uniquement sur la première interaction. Une bonne valeur se situe sous 200 millisecondes.

Quand l’INP a-t-il remplacé le FID ?

En mars 2024, l’Interaction to Next Paint est officiellement devenu un Core Web Vital et a remplacé le First Input Delay. Le FID ne mesurait que la première interaction, tandis que l’INP évalue la réactivité sur l’ensemble de la session.

Quel est le seuil d’INP considéré comme bon ?

Google considère un INP inférieur à 200 millisecondes comme bon, entre 200 et 500 millisecondes comme nécessitant des améliorations, et supérieur à 500 millisecondes comme mauvais. Cette valeur se réfère au 75e percentile des pages vues.

Pourquoi les applications SaaS sont-elles particulièrement concernées ?

Parce qu’elles sont interactives. Chaque clic, chaque saisie et chaque changement d’état est pris en compte dans la valeur INP. Les pages de contenu comportent peu d’interactions, tandis qu’une application en compte des centaines par session. Un main thread bloqué a donc un impact bien plus sévère.

Comment mesurer l’INP de manière fiable ?

Via des données de terrain issues d’utilisateurs réels, et non via des tests en laboratoire. Le Chrome UX Report fournit des valeurs agrégées, tandis qu’une collecte personnalisée avec la bibliothèque web-vitals révèle quelles interactions spécifiques causent les mauvais résultats.