Tu peux avoir un LCP parfait et une page qui semble figée. C'est tout le problème de l'INP. Le LCP se voit sur une capture d'écran. Le CLS se repère à l'oeil pendant le chargement. L'INP, lui, ne se manifeste qu'au moment précis où ton visiteur agit, où il clique, où il ouvre un menu, où il coche une case. C'est la métrique qui mesure si ton produit répond quand on le touche. Et c'est exactement pour ça que presque personne ne la corrige : elle ne se montre pas tant que tu n'interagis pas vraiment avec ta propre page.
Sur Copyboost, mon temps de blocage du fil principal est passé de 1740 ms à 950 ms en isolant l'hydratation. Voici pourquoi cette métrique compte plus que tu ne le crois, et comment la réparer.
Ce que l'INP mesure, et pourquoi tu ne le vois jamais
L'INP, pour Interaction to Next Paint, mesure le délai entre une action de ton utilisateur et la prochaine fois que l'écran se met à jour pour lui répondre. Tu cliques sur un bouton. Combien de temps avant que quelque chose change visuellement ? Ce délai, c'est l'INP. Il a remplacé l'ancien FID en mars 2024, et il est plus exigeant : il ne regarde plus seulement la première interaction, il prend la pire de toute ta session.
Le seuil que vise Google est de 200 millisecondes ou moins. Au delà de 500 ms, c'est classé mauvais. La nuance importante : ces 200 ms ne se mesurent pas dans un audit à froid. Quand tu lances Lighthouse, tu mesures un chargement, pas une interaction. Donc ton rapport peut être vert pendant que tes vrais utilisateurs vivent une page qui colle. L'INP terrain vient du comportement réel, sur de vrais appareils, et c'est la seule donnée qui compte.
Le mécanisme : la réponse que ton cerveau exige
Quand tu cliques, ton cerveau attend un retour. Pas dans une seconde, tout de suite. La recherche sur la perception du temps situe le seuil de l'immédiateté ressentie autour de 100 ms. En dessous, l'action et la réaction semblent ne faire qu'un, tu sens que tu contrôles. Au dessus, un doute s'installe : est-ce que ça a marché ? Est-ce que j'ai bien cliqué ? Faut-il que je reclique ?
Ce doute est toxique pour la conversion, parce qu'il frappe au pire moment. Le LCP punit ton visiteur avant qu'il s'engage. L'INP, lui, punit ton visiteur au moment où il vient de décider de s'engager. C'est ton prospect le plus motivé, celui qui a cliqué sur "Créer mon compte", qui se retrouve à fixer un bouton mort pendant 400 ms. Tu ne perds pas un curieux, tu perds quelqu'un qui était prêt.
Et le coût se cumule. Face à un bouton qui ne répond pas, l'utilisateur reclique. Ce second clic peut déclencher deux soumissions, deux requêtes, parfois deux comptes amorcés, et une interface qui semble encore plus cassée. Ce que les outils d'analyse appellent un rage click n'est pas un caprice, c'est la réaction logique de quelqu'un à qui ta page n'a pas accusé réception. Chaque reclic est la preuve qu'un doute s'est installé là où tu voulais une action fluide.
Une page qui ne répond pas envoie un signal corporel précis : ce produit ne m'écoute pas. Et un produit qui ne t'écoute pas, tu ne lui confies pas ta carte bancaire.
La prise de position : c'est la métrique qu'on ignore par confort
L'INP est la plus négligée des trois Core Web Vitals, et ce n'est pas un hasard. Le LCP est flatteur à optimiser : tu vois le chiffre baisser, la page apparaît plus vite, c'est gratifiant. Le CLS se règle souvent en posant deux dimensions d'image. L'INP, lui, t'oblige à regarder ton JavaScript en face, à admettre que tu en charges trop, et à faire un travail ingrat sur le fil principal du navigateur.
Alors on l'évite. On vise le score Lighthouse parce qu'il monte vite, on encadre le LCP parce qu'il se voit, et on laisse l'INP rouge dans le rapport CrUX que personne n'ouvre. C'est confortable, et c'est une erreur. La réactivité est la partie de la performance que ton utilisateur ressent dans son corps, pas celle qu'un outil affiche dans un graphique. C'est aussi pour ça que la performance est un premier levier CRO, pas un détail technique.
Teardown : Copyboost, le fil principal saturé
Voilà ce qui plombait ma propre réactivité.
L'application Copyboost repose sur plusieurs composants interactifs côté client : le sélecteur de mode, les barres d'axes, l'anneau de score, le filtre du blog, les cartes de suggestion. Tous utilisent une librairie d'animation. Le problème n'était pas l'animation elle même, c'était que cette charge JavaScript s'exécutait au chargement pour rendre toute la page interactive d'un coup. Pendant cette phase d'hydratation, le fil principal du navigateur était saturé, exactement le piège de l'hydratation Next.js. Chaque clic arrivait dans une file d'attente derrière du travail déjà en cours, et restait sans réponse.
Deux corrections. D'abord, isoler la librairie d'animation aux seuls composants de l'application, en la sortant de la chaîne marketing où elle n'avait rien à faire. Ensuite, alléger l'hydratation globale pour que moins de JavaScript s'exécute au démarrage. Résultat mesuré en laboratoire : le temps de blocage du fil principal est passé de 1740 ms à 950 ms. La valeur INP terrain correspondante reste à mesurer avec les données CrUX réelles, mais la direction est nette : moins de travail au démarrage, un fil principal qui se libère, des clics qui répondent.
L'artefact : les 3 causes de l'INP, et leur fix
Quand ton INP est rouge, le coupable est presque toujours dans cette liste. Pour chaque cause, le réflexe de correction.
- Trop de JavaScript à l'hydratation. Le navigateur passe ses premières secondes à rendre interactif du contenu qui pourrait rester statique. Une page de contenu n'a pas besoin que chaque section soit pilotée côté client. Fix : déplace ce qui peut l'être en composant serveur, réduis le JavaScript envoyé au client, et n'hydrate que les zones qui réagissent vraiment à un clic. Tout le reste peut arriver en HTML déjà rendu, sans coût sur le fil principal.
- Des tâches longues qui bloquent le fil principal. Une seule fonction qui tourne 300 ms, et tout clic pendant ce temps attend. Fix : découpe les tâches longues en morceaux, reporte le travail non urgent après le premier rendu, et code-splitte ce qui n'est pas nécessaire tout de suite.
- Des gestionnaires d'événements coûteux. Le clic déclenche un calcul lourd avant de mettre l'écran à jour. Fix : affiche d'abord un retour visuel immédiat, puis fais le calcul, et limite la fréquence des événements répétés comme la saisie ou le défilement.
Où tu mesures vraiment : le panneau Performance de Chrome pour reproduire et trouver la tâche longue en local, et la librairie web-vitals ou le rapport CrUX pour la valeur terrain, la seule que Google utilise. Le score Lighthouse ne te dira jamais si ton bouton répond, parce qu'il ne clique sur rien.
Ce qu'il faut retenir
L'INP est la seule des trois Core Web Vitals qui mesure ce que ton utilisateur ressent au moment où il agit. C'est aussi la seule qui frappe tes visiteurs les plus motivés, ceux qui ont déjà décidé de cliquer. La corriger, c'est arrêter de faire douter les gens qui étaient prêts à avancer. Commence par ouvrir le panneau Performance, clique sur ton propre produit, et regarde combien de temps il met à te répondre. Tu vas être surpris.