Depuis mars 2024, l'INP (Interaction to Next Paint) a remplacé le FID dans les Core Web Vitals officiels de Google. En 2026, cette métrique est devenue le principal facteur de réactivité dans le signal d'expérience de page, et un point de friction technique majeur pour les sites lourds en JavaScript. Ce guide détaille la définition de l'INP, son seuil, les méthodes de mesure et les optimisations concrètes recommandées par web.dev.

Toutes les données présentées sont issues de la documentation officielle de web.dev, du Google Search Central et du Chrome User Experience Report.

Tableau résumé : ce qu'il faut retenir sur l'INP

Indicateur	Valeur officielle	Source	Action
Remplacement du FID	12 mars 2024	web.dev/inp	Mettre à jour les outils de mesure
Seuil bon	Inférieur ou égal à 200 ms	web.dev	Cible 75e centile
Seuil à améliorer	200 à 500 ms	web.dev	Identifier les longues tâches
Mauvais INP	Plus de 500 ms	web.dev	Audit complet et priorisation
Fenêtre de mesure CrUX	28 jours glissants	CrUX docs	Suivre l'évolution mensuelle

Votre INP est dans le rouge ?

Audit de performance complet, plan d'action priorisé et optimisations livrées. Devis fixe sous 24h.

Devis gratuit 24h 07 87 19 00 11 WhatsApp

29 AVIS 5/5 · +200 PROJETS LIVRÉS · RÉPONSE SOUS 2H

Comprendre l'INP : définition officielle

L'Interaction to Next Paint est défini par web.dev comme la latence entre une interaction utilisateur et le prochain rendu visuel. Une interaction inclut un clic, un tap sur écran tactile ou une frappe au clavier. Le hover et le scroll seul ne déclenchent pas d'INP.

Concrètement, l'INP capture trois phases :

Input delay : temps entre l'événement utilisateur et le début du traitement
Processing time : exécution du gestionnaire d'événement et du JavaScript associé
Presentation delay : temps entre la fin du traitement et le prochain frame peint

Pour une page donnée, le navigateur enregistre toutes les interactions. La valeur reportée correspond au 75e centile, ou pour les pages à fort volume d'interactions, à la pire interaction observée selon une heuristique documentée par web.dev.

Pourquoi INP plutôt que FID ?

Le FID (First Input Delay) ne mesurait que la latence avant le traitement de la première interaction. Il ignorait la durée du traitement et toutes les interactions suivantes. En pratique, un site pouvait afficher un excellent FID tout en étant désagréable à l'usage. Google a confirmé sur le blog web.dev que l'INP représente mieux l'expérience réelle d'un utilisateur tout au long de sa session.

Comment mesurer l'INP en 2026

Il existe deux familles de mesure : terrain (field data) et laboratoire (lab data). Les données terrain sont la référence pour le ranking, comme indiqué par Google Search Central.

Données terrain (référence Google)

Chrome User Experience Report (CrUX) : agrégat des utilisateurs Chrome opt-in, fenêtre 28 jours
Google Search Console : rapport Core Web Vitals dérivé de CrUX
PageSpeed Insights : combine CrUX et Lighthouse
web-vitals.js : librairie officielle pour mesurer chez vos vrais utilisateurs

Données laboratoire

Lighthouse : estimation basée sur le Total Blocking Time
Chrome DevTools Performance : enregistrement détaillé des interactions
Long Tasks API : identification des tâches supérieures à 50 ms

La librairie web-vitals.js est aujourd'hui la voie de référence pour collecter l'INP en production et l'envoyer vers votre outil d'analytics. Elle expose une API stable depuis la version 4 publiée en 2024.

Mesure réelle

Installons web-vitals.js sur votre site et identifions les interactions problématiques.

Mise en place du tracking, dashboard CrUX et plan d'optimisation priorisé par impact.

Devis gratuit sous 24h 07 87 19 00 11

Les causes principales d'un mauvais INP

L'analyse des sites en échec sur la métrique INP, documentée par web.dev/optimize-inp, met en évidence cinq facteurs récurrents.

1. Longues tâches JavaScript

Toute tâche supérieure à 50 ms bloque le thread principal. Lorsqu'une interaction tombe pendant cette période, l'input delay explose. La Long Tasks API permet de les détecter en production.

2. Scripts tiers non maîtrisés

Tag managers, scripts publicitaires, widgets de chat, A/B testing. Tout ce qui s'exécute sans contrôle direct du développeur. La documentation web.dev sur les third-party scripts recommande l'isolation via web workers ou facades.

3. Re-renders React non optimisés

Un setState dans le composant racine déclenche un re-render de l'arbre entier. Sans React.memo et useMemo bien placés, le coût d'une simple interaction peut dépasser 200 ms sur du mobile mid-range. Documentation officielle sur React.memo.

4. Hydration coûteuse

Les frameworks SSR (Next.js, Nuxt, Astro avec islands actives) doivent hydrater le DOM côté client. Une hydration mal architecturée bloque le thread juste après le chargement, période où les premières interactions surviennent. web.dev référence ce problème comme cause majeure.

5. Listeners d'événements lourds

Un onClick qui déclenche un fetch synchrone, calcule un grand tableau ou redimensionne plusieurs images en JS bloque le navigateur jusqu'à la fin. Découper en tâches asynchrones est indispensable.

Les optimisations concrètes 2026

Voici les techniques recommandées par web.dev et observées comme efficaces sur le terrain.

scheduler.yield et yieldUnlessUrgent

L'API scheduler.yield() permet de céder le contrôle au navigateur entre deux unités de travail, sans perdre la priorité de la tâche. Disponible en Chrome stable depuis 2024, c'est l'outil de référence pour découper les longues tâches.

Code splitting et chargement différé

Réduire le bundle initial diminue le temps de blocking au load. Les frameworks modernes (Next.js, Astro, Remix) supportent le code splitting par route et par composant via les dynamic imports.

Web workers pour le calcul lourd

Tout traitement supérieur à 100 ms doit être déporté en web worker. La spec Web Workers est stable depuis longtemps et bien supportée. Des libs comme Comlink simplifient l'API.

Optimisation des re-renders React

React 19 et son nouveau compilateur réduisent automatiquement les re-renders inutiles. La documentation React Compiler détaille le mode opt-in. À défaut, useMemo et React.memo restent les bonnes pratiques.

Hydration partielle et islands

Les frameworks comme Astro, Qwik et Fresh proposent une hydration sélective qui réduit drastiquement le coût initial. Astro hydrate uniquement les composants marqués client, ce qui limite l'INP au strict nécessaire.

Estimez en 30 secondes

Combien va coûter votre projet ?

Cela ouvre Calendly avec votre contexte. Réponse précise sous 24h.

Tableau d'impact des optimisations

Optimisation	Gain INP typique	Difficulté	Source
scheduler.yield sur longues tâches	-100 à -300 ms	Moyenne	developer.chrome.com
Web worker calcul lourd	-200 à -500 ms	Moyenne	web.dev
Code splitting	-50 à -150 ms	Faible	web.dev
React.memo et useMemo	-50 à -200 ms	Faible	react.dev
Isolation scripts tiers	-100 à -400 ms	Moyenne	web.dev

Comment CZSyn applique ces trends

CZSyn intègre le suivi de l'INP en production via web-vitals.js dans chaque projet, déploie scheduler.yield et l'isolation en web workers sur les calculs lourds, audite l'hydration des sites SSR pour réduire le coût initial, et restructure les bundles avec code splitting agressif. Chaque livraison inclut un rapport CrUX comparatif et un suivi mensuel des Core Web Vitals dans la Search Console du client.

Passez vos Core Web Vitals au vert.

Audit INP, LCP et CLS, plan d'action priorisé, optimisations livrées. Devis fixe sous 24h.