Le INP (Interaction to Next Paint) mesure la réactivité globale d'une page face aux actions utilisateur sur toute la durée de la session, succédant au FID en mars 2024. Seuil Google : 200 ms pour une fluidité perçue comme instantanée.
Le INP (Interaction to Next Paint) constitue la troisième métrique des Core Web Vitals, inaugurée officiellement en mars 2024 pour remplacer le FID (First Input Delay) jugé trop restrictif. Alors que le FID mesurait uniquement le premier clic, l'INP observe toutes les interactions (clics, taps, touches clavier) pendant l'intégralité de la session et retient le 90e percentile le plus lent. Il capture le temps écoulé entre l'action utilisateur et le rendu visuel suivant (next paint). Google considère un INP inférieur à 200 ms comme bon, entre 200 et 500 ms comme à améliorer, et au-delà de 500 ms comme mauvais.
L'INP se décompose en trois phases : le delay d'entrée (temps avant que le thread principal ne traite l'événement), le temps de traitement (exécution des event handlers) et le delay de présentation (temps avant que le navigateur n'affiche le résultat). Sur mobile, le INP moyen des sites e-commerce est de 380 ms (HTTP Archive, 2024), bien au-delà du seuil recommandé.
Le INP, c'est comme le temps de réponse d'un serveur dans un restaurant. Un FID mesurait seulement le premier « bonjour ». L'INP mesure chaque fois que vous levez la main pour demander quelque chose et combien de temps il faut attendre avant que le serveur ne bouge. Si vous attendez plus de 500 ms à chaque demande, vous quittez le restaurant.
Le thread principal du navigateur exécute JavaScript, calcule les styles et effectue le rendu. S'il est occupé par un script lourd (analytiques, A/B testing, chat widget), l'interaction utilisateur est mise en file d'attente. Solutions : découper les scripts longs en tâches de < 50 ms (yielding), utiliser les Web Workers pour les calculs intensifs, et charger les scripts tiers en asynchrone différé. Un site appliquant le yielding a réduit son INP de 580 ms à 120 ms.
Une fois l'événement traité, le navigateur doit recalculer les styles, la mise en page (layout) et peindre les pixels (paint). Les propriétés CSS lentes (width, height, top, left) déclenchent un reflow complet. Privilégier transform et opacity qui sont optimisées par le GPU. Le content-visibility: auto sur les sections hors viewport réduit le travail de rendu initial de +60 %.
Les tags marketing (Google Tag Manager, Facebook Pixel, Hotjar) et widgets (chat, avis) injectent du JavaScript synchrone qui monopolise le thread. Chaque script tiers ajoute en moyenne +42 ms au INP. Containment : charger les scripts non critiques via defer ou async, utiliser les Partytown pour déporter les trackers dans un Web Worker, et restreindre GTM aux tags essentiels. Un audit Ubickë 2024 a montré que 67 % des sites audités ont 5+ scripts tiers bloquants le thread principal.
Une plateforme e-commerce de mode (380 000 visites/mois) souffrait d'un INP moyen de 520 ms (mauvais). Diagnostic Chrome DevTools : le script de recommandation produit exécutait un calcul de similarité côté client (350 ms) sur chaque clic « ajouter au panier ». Actions : (1) déport du calcul vers une API REST avec cache Redis, (2) suppression du chat widget visuellement lourd remplacé par un bouton flottant différé, (3) application de content-visibility: auto sur les 12 sections de la page produit. Résultat en 6 semaines : INP passe à 98 ms (bon). Conversion mobile +22 %, taux d'abandon panier -18 %, revenu mobile +€47 000/mois.
| Métrique | Seuil Google | Impact |
|---|---|---|
| Bon | ≤ 200 ms | Fluidité native ; conversion optimale |
| À améliorer | 200 – 500 ms | Friction perceptible ; rebond +15-25 % |
| Mauvais | > 500 ms | Frustration intense ; abandon panier +30 % |
| INP 75e percentile | Mesure CrUX sur les vrais utilisateurs | Métrique de référence pour le ranking |
| Temps Long Tasks | < 50 ms par tâche | Garantie que le thread reste disponible |