Core Web Vitals INP : pourquoi une landing page rapide au chargement peut quand même perdre des clients

Le chargement rapide d'une landing page — image hero optimisée, police qui ne saute pas, premier rendu sous la seconde — est devenu un réflexe pour la plupart des équipes marketing, souvent couvert par le seuil de 3 secondes à ne pas dépasser. Mais un chargement rapide ne garantit pas une page réactive. Un visiteur peut arriver sur une page qui s'affiche en 800 ms, cliquer sur le CTA « Voir l'offre », et attendre 400, 600, parfois 900 millisecondes avant que quoi que ce soit ne bouge à l'écran — le temps qu'un pixel tiers se déclenche, qu'un script d'analytics se charge ou qu'un re-rendu React trop lourd s'exécute. Ce décalage, invisible dans la plupart des audits de vitesse classiques, a désormais son propre indicateur officiel : l'INP.

Qu'est-ce que l'INP et pourquoi il a remplacé le FID en mars 2024

L'Interaction to Next Paint (INP) est devenu un Core Web Vital officiel de Google le 12 mars 2024, en remplacement du First Input Delay (FID). La différence est fondamentale pour une landing page transactionnelle : le FID ne mesurait que le délai avant que le tout premier clic de la visite commence à être traité — un indicateur partiel, souvent flatteur, qui ignorait tout ce qui se passait ensuite. L'INP, lui, observe chaque interaction pendant toute la durée de la visite (clic sur le CTA, ouverture d'un champ de formulaire, changement d'onglet dans une FAQ) et retient la latence la plus représentative de l'ensemble — du moment où le visiteur agit jusqu'au moment où l'écran affiche visuellement le résultat de son action. Une page peut avoir un excellent FID (le premier clic répond vite) et un mauvais INP (le troisième ou quatrième clic, une fois les scripts tiers chargés et le thread principal encombré, traîne nettement).

Le seuil qui compte : 200 millisecondes

Google évalue l'INP au 75ᵉ percentile des visites réelles d'une page, avec trois paliers : sous 200 ms, l'interactivité est jugée bonne ; entre 200 et 500 ms, elle « nécessite une amélioration » ; au-delà de 500 ms, elle est considérée comme mauvaise. Contrairement à un score de laboratoire (Lighthouse), l'INP officiel se calcule sur des données de terrain réelles — celles remontées par les visiteurs via Chrome (le Chrome User Experience Report, ou CrUX) — ce qui veut dire qu'un audit lancé sur une page vide, sans clic simulé, ne montrera jamais de problème d'INP même s'il existe bel et bien en conditions réelles d'usage.

Pourquoi l'interactivité pèse sur la conversion, pas seulement sur le SEO

L'INP est un facteur de classement Google, mais son impact le plus direct reste comportemental. Une étude d'Ioannis Arapakis, Souneil Park et Martin Pielot présentée à la conférence CHIIR 2021 (voir sur Google Scholar) montre que des délais de réponse dépassant 7 à 10 secondes sur mobile déclenchent une hausse mesurable de la frustration et de la fatigue perçue chez l'utilisateur — et que la tolérance chute encore plus vite dès que l'interaction se répète sans réponse fluide. Une autre étude plus ancienne mais toujours citée, celle de John Hoxmeier et Chris DiCesare présentée à l'AMCIS 2000 (voir sur Google Scholar), établit qu'un temps de réponse système qui s'allonge fait baisser la satisfaction perçue de façon quasi linéaire, bien avant tout seuil d'abandon complet. Ces deux travaux ne portent pas spécifiquement sur des landing pages de vente, mais le mécanisme qu'ils documentent — la frustration monte à mesure que l'écart entre l'action et la réponse visuelle se creuse — est exactement ce que l'INP cherche à quantifier sur le web actuel.

Ce qui plombe l'INP sur une landing page, concrètement

• Les scripts tiers chargés en priorité — pixel Meta, tag Google Ads, chat en direct : quand ils s'exécutent au clic plutôt qu'en tâche de fond, ils bloquent le thread principal pile au moment où le visiteur interagit. Voir notre article sur le pixel Meta et l'API de conversions pour les faire tourner côté serveur plutôt que dans le navigateur.
• Les carrousels et sliders animés en JavaScript, dont les gestionnaires d'événements recalculent des positions à chaque interaction — souvent plus coûteux qu'ils n'y paraissent, comme détaillé dans notre article sur les carrousels sur une landing page.
• La validation de formulaire trop gourmande, quand chaque frappe clavier déclenche une re-validation complète du champ plutôt qu'un contrôle ciblé.
• Les widgets de chat et de pop-up tiers qui s'initialisent au chargement puis interceptent les clics suivants pendant qu'ils finissent de s'hydrater.
• Les longues tâches JavaScript (« long tasks ») de plus de 50 ms qui monopolisent le thread principal — souvent un bundle mal découpé plutôt qu'une seule fonction fautive identifiable.

Comment mesurer l'INP réel d'une page

1. Google Search Console → rapport Signaux Web essentiels : la seule source qui agrège les données de terrain (CrUX) réellement collectées auprès de vos visiteurs, par URL et par appareil.
2. PageSpeed Insights : affiche à la fois le score de terrain (si le trafic est suffisant) et un score de laboratoire — utile mais ce dernier ne simule pas d'interaction réelle et peut rester optimiste.
3. Le panneau Performance de Chrome DevTools, en enregistrant une session avec quelques interactions volontaires (clic CTA, ouverture FAQ), pour repérer visuellement la tâche qui bloque le rendu.
4. La librairie web-vitals de Google, à brancher sur votre outil d'analytics pour faire remonter l'INP réel de chaque visite, y compris sur un trafic encore trop faible pour apparaître dans CrUX.

Comment améliorer l'INP sur une landing page Next.js

• Charger les scripts tiers non critiques avec next/script et la stratégie strategy="lazyOnload" plutôt qu'en chargement bloquant — voir notre guide de déploiement Next.js sur Vercel.
• Différer l'initialisation des widgets de chat et de tracking tiers jusqu'à la première interaction réelle de l'utilisateur (scroll ou clic), plutôt que dès le montage de la page.
• Découper les gestionnaires de clic lourds en tâches plus courtes (via requestIdleCallback ou un simple setTimeout(0) pour la partie non visuelle) afin que le navigateur puisse peindre l'état du bouton avant de terminer le travail annexe.
• Éviter de recalculer tout l'état du formulaire à chaque frappe : ne valider un champ qu'à la sortie de focus (onBlur) plutôt qu'à chaque onChange.
• Garder le nombre de scripts tiers au strict nécessaire — chaque outil ajouté (heatmap, chat, A/B testing côté client) est une source potentielle de tâche longue au moment précis où le visiteur agit.

Le mobile, angle mort le plus fréquent

L'écart entre desktop et mobile se creuse particulièrement sur l'INP : un processeur de smartphone milieu de gamme met souvent trois à quatre fois plus de temps qu'un ordinateur de bureau à exécuter le même script. Une landing page qui affiche un bon INP mesuré sur un poste de développement peut se révéler nettement en dessous du seuil de 200 ms une fois testée sur l'appareil réellement utilisé par la majorité du trafic publicitaire — voir notre article dédié au mobile-first pour l'ensemble des leviers, au-delà du seul INP.

Partir d'une base déjà propre

Les 10 templates LanderKit sont construits en Next.js avec un JavaScript minimal par défaut — sans widget tiers imposé, sans script de tracking préinstallé — ce qui donne un point de départ déjà proche du seuil de 200 ms avant même la première optimisation. Charge ensuite à vous d'ajouter vos propres outils (pixel, chat, A/B testing) en gardant à l'esprit qu'ils s'exécutent au moment précis où un visiteur s'apprête à acheter. Vous pouvez tester le comportement réel d'un template avant d'ajouter quoi que ce soit sur la démo e-commerce ou la démo liste d'attente SaaS (89 € l'unité, 229 € le pack complet).