L’INP mesure la réactivité à chaque interaction (clic, tap, frappe), pas la vitesse de chargement. Une page peut s’afficher vite puis laguer à chaque saisie parce que du JavaScript monopolise le thread principal. Sur un formulaire, ce lag fait abandonner pile au moment de convertir. La correction est dans le code, pas dans les images.
L’erreur de raisonnement la plus courante sur l’INP : croire que si la page charge vite, elle est forcément réactive. Ce sont deux métriques distinctes, et les confondre laisse l’INP dégradé sans qu’on comprenne pourquoi.
Le LCP mesure la vitesse de chargement : à quelle vitesse le contenu principal s’affiche à l’écran. L’INP mesure la réactivité : une fois la page affichée, à quelle vitesse elle répond quand vous cliquez, tapez ou remplissez un champ.
Une page peut s’afficher en un éclair (bon LCP) puis laguer à chaque interaction (mauvais INP), le clic met une demi-seconde à réagir, la frappe dans un champ saccade.
Seuil « bon » selon les standards Core Web Vitals : sous 200 millisecondes par interaction.
L’INP a remplacé FID en 2024, en mesurant toutes les interactions et non plus seulement la première. C’est la métrique que la plupart des sites échouent en 2026, parce que sa cause est profonde, pas cosmétique. Situez-la d’abord parmi les Core Web Vitals qui pèsent sur vos Ads : vous saurez où elle vous fait mal avant de toucher au code.
L’INP est mauvais presque toujours pour la même raison : du JavaScript qui monopolise le thread principal du navigateur. Ce thread unique gère à la fois l’affichage et les interactions. Quand un script lourd s’exécute (un tag tiers, un framework mal optimisé, un handler d’événement coûteux), il occupe ce thread, et pendant ce temps, le navigateur ne peut pas répondre à votre clic ou votre frappe.
D’où le lag : l’interaction attend que le JavaScript libère le thread.
C’est pour ça que l’INP est dur à corriger. Contrairement au chargement (amélioré avec des images optimisées, du cache ou des CDN), l’INP se règle dans le code et les scripts. Allégez le JavaScript, découpez-le en tâches plus petites pour qu’il rende la main au navigateur entre deux, différez les scripts non critiques, et surtout maîtrisez les tags tiers.
Les tags tiers sont souvent les premiers coupables : ils s’accumulent, bloquent le thread, et peuvent faire grimper le rebond avant même que le visiteur atteigne le formulaire. Le server-side tagging déplace une partie de cette charge hors du navigateur, c’est l’une des corrections les plus efficaces sur les sites chargés en scripts.
Pour le chargement lui-même, c’est la mise en cache et une architecture headless qui font le travail, mais l’INP, lui, se règle dans le JS. Ce n’est pas un réglage cosmétique : c’est de l’architecture.
Sur le formulaire, l’INP coûte le plus cher. Le visiteur arrive, lit, se décide, puis interagit : il clique dans un champ, tape, passe au suivant, soumet. Toutes ces actions sont des interactions mesurées par l’INP.
Si la page lague à la saisie (chaque frappe saccade) ou à la soumission (le clic sur « Envoyer » met une seconde à réagir, le visiteur reclique, doute, abandonne), vous perdez le visiteur au moment exact de la conversion, au dernier mètre, après avoir tout fait pour l’amener là.
C’est la pire fuite possible : un visiteur motivé, décidé, en train d’agir, que la lenteur de réaction décourage pile au point de bascule. La réactivité n’est qu’une moitié du problème : découper le formulaire en étapes plutôt qu’en bloc unique change aussi le ressenti à la saisie.
L’INP du formulaire n’est donc pas un détail technique : c’est la réactivité de votre point de conversion.
La limite honnête : corriger l’INP demande souvent l’intervention d’un développeur, c’est de l’architecture JS, pas un réglage d’interface. Mais sur une landing page de conversion, le formulaire mérite une attention prioritaire, parce que c’est là que l’argent se transforme ou se perd.
Mesurez l’INP séparément du chargement : une page rapide à l’affichage peut être lente à répondre, ne supposez pas l’un depuis l’autre. Ciblez en priorité l’INP du formulaire : la saisie et la soumission doivent être instantanées, c’est le moment de la conversion.
Traitez la cause profonde : du JavaScript qui bloque le thread principal. Allégez et découpez le JS, déférez les scripts non critiques, maîtrisez les tags tiers (envisagez le server-side), optimisez les handlers d’événements.
C’est de l’architecture, souvent avec un développeur, mais c’est de la rentabilité : un formulaire qui lague perd des conversions au dernier mètre. Replacez ce réglage dans l’ensemble : c’est une pièce de tout ce qui fait une landing page qui convertit, pas une fin en soi.
L’erreur de raisonnement la plus courante sur l’INP : croire que si la page charge vite, elle est forcément réactive. Ce sont deux métriques distinctes, et les confondre laisse l’INP dégradé sans qu’on comprenne pourquoi.
Le LCP mesure la vitesse de chargement : à quelle vitesse le contenu principal s’affiche à l’écran. L’INP mesure la réactivité : une fois la page affichée, à quelle vitesse elle répond quand vous cliquez, tapez ou remplissez un champ.
Une page peut s’afficher en un éclair (bon LCP) puis laguer à chaque interaction (mauvais INP), le clic met une demi-seconde à réagir, la frappe dans un champ saccade.
Seuil « bon » selon les standards Core Web Vitals : sous 200 millisecondes par interaction.
L’INP a remplacé FID en 2024, en mesurant toutes les interactions et non plus seulement la première. C’est la métrique que la plupart des sites échouent en 2026, parce que sa cause est profonde, pas cosmétique. Situez-la d’abord parmi les Core Web Vitals qui pèsent sur vos Ads : vous saurez où elle vous fait mal avant de toucher au code.
L’INP est mauvais presque toujours pour la même raison : du JavaScript qui monopolise le thread principal du navigateur. Ce thread unique gère à la fois l’affichage et les interactions. Quand un script lourd s’exécute (un tag tiers, un framework mal optimisé, un handler d’événement coûteux), il occupe ce thread, et pendant ce temps, le navigateur ne peut pas répondre à votre clic ou votre frappe.
D’où le lag : l’interaction attend que le JavaScript libère le thread.
C’est pour ça que l’INP est dur à corriger. Contrairement au chargement (amélioré avec des images optimisées, du cache ou des CDN), l’INP se règle dans le code et les scripts. Allégez le JavaScript, découpez-le en tâches plus petites pour qu’il rende la main au navigateur entre deux, différez les scripts non critiques, et surtout maîtrisez les tags tiers.
Les tags tiers sont souvent les premiers coupables : ils s’accumulent, bloquent le thread, et peuvent faire grimper le rebond avant même que le visiteur atteigne le formulaire. Le server-side tagging déplace une partie de cette charge hors du navigateur, c’est l’une des corrections les plus efficaces sur les sites chargés en scripts.
Pour le chargement lui-même, c’est la mise en cache et une architecture headless qui font le travail, mais l’INP, lui, se règle dans le JS. Ce n’est pas un réglage cosmétique : c’est de l’architecture.
Sur le formulaire, l’INP coûte le plus cher. Le visiteur arrive, lit, se décide, puis interagit : il clique dans un champ, tape, passe au suivant, soumet. Toutes ces actions sont des interactions mesurées par l’INP.
Si la page lague à la saisie (chaque frappe saccade) ou à la soumission (le clic sur « Envoyer » met une seconde à réagir, le visiteur reclique, doute, abandonne), vous perdez le visiteur au moment exact de la conversion, au dernier mètre, après avoir tout fait pour l’amener là.
C’est la pire fuite possible : un visiteur motivé, décidé, en train d’agir, que la lenteur de réaction décourage pile au point de bascule. La réactivité n’est qu’une moitié du problème : découper le formulaire en étapes plutôt qu’en bloc unique change aussi le ressenti à la saisie.
L’INP du formulaire n’est donc pas un détail technique : c’est la réactivité de votre point de conversion.
La limite honnête : corriger l’INP demande souvent l’intervention d’un développeur, c’est de l’architecture JS, pas un réglage d’interface. Mais sur une landing page de conversion, le formulaire mérite une attention prioritaire, parce que c’est là que l’argent se transforme ou se perd.
Mesurez l’INP séparément du chargement : une page rapide à l’affichage peut être lente à répondre, ne supposez pas l’un depuis l’autre. Ciblez en priorité l’INP du formulaire : la saisie et la soumission doivent être instantanées, c’est le moment de la conversion.
Traitez la cause profonde : du JavaScript qui bloque le thread principal. Allégez et découpez le JS, déférez les scripts non critiques, maîtrisez les tags tiers (envisagez le server-side), optimisez les handlers d’événements.
C’est de l’architecture, souvent avec un développeur, mais c’est de la rentabilité : un formulaire qui lague perd des conversions au dernier mètre. Replacez ce réglage dans l’ensemble : c’est une pièce de tout ce qui fait une landing page qui convertit, pas une fin en soi.
L’INP est-il pris en compte dans le Quality Score Google Ads ? Pas directement, mais Google Ads note l'expérience sur votre page de destination. Un formulaire qui lague dégrade cette note et peut peser sur votre score de qualité, donc sur votre CPC réel.
Ma page a un bon LCP, mon INP peut quand même être mauvais ? Oui. LCP et INP mesurent deux choses différentes. Un LCP rapide signifie que votre page s’affiche vite, rien de plus : si du JavaScript tourne en arrière-plan, chaque interaction peut laguer indépendamment du temps d’affichage.
Par où commencer pour corriger l’INP d’un formulaire ? Par la mesure. Chrome DevTools, onglet Performance, en simulant la saisie dans le formulaire. Le rapport Long Tasks montre quel script bloque le thread à chaque interaction. Identifiez le coupable avant de toucher au code.
Le server-side tagging suffit à corriger l’INP ? Il soulage le thread principal en déplaçant la collecte côté serveur, ce qui peut suffire si les tags tiers sont la cause principale. Mais si le problème vient d’un framework JS lourd ou d’un handler mal optimisé, le server-side tagging ne réglera pas tout. Mesurez d’abord pour identifier la source réelle du blocage.
Un JavaScript bloque le thread et vous perdez des leads au dernier mètre. On regarde ce qui coince.
Réserver un appelParlons de vos objectifs