Temps de lecture estimé : 8 minutes
Points clés à retenir
- L’INP se décompose en 3 phases distinctes (Input Delay, Processing Time, Presentation Delay) qu’il faut diagnostiquer séparément dans Chrome DevTools avant d’optimiser
- Les leviers 1 et 3 (scheduler.yield et Web Worker) représentent à eux seuls environ 80 % des gains constatés en audit
- Sur mobile, un script de 200 ms peut dépasser 600 ms à cause du CPU plus lent : tester systématiquement avec throttling x4
- Le seuil « Bon » reste sous 200 ms et la propagation des nouvelles mesures dans Search Console prend 28 jours
- Supprimer 2-3 scripts tiers suffit souvent à repasser sous les 200 ms sans toucher au code
Sommaire
Réduire l’INP : le guide complet pour restaurer l’interactivité de votre site
Réduire l’INP pour améliorer l’interactivité d’un site, c’est aujourd’hui l’un des chantiers techniques les plus rentables en SEO. Sur un site client e-commerce le mois dernier, on est passé de 480 ms à 170 ms sur mobile : +22 % de conversions sur les pages produit en six semaines. Pas de magie, juste un diagnostic précis et deux correctifs bien placés.
L’INP (Interaction to Next Paint), c’est la métrique qui mesure le délai entre le moment où vous cliquez et le moment où la page réagit visuellement. Elle a remplacé le FID en mars 2024 dans les Core Web Vitals. Depuis, des sites qui « passaient » tranquillement se retrouvent avec des alertes rouges dans Search Console. Et les guides qu’on lit se contredisent joyeusement.
Ici, pas de recette miracle. On va découper l’INP en trois phases, identifier la vôtre, appliquer six leviers concrets, puis vérifier les gains. Ça dépend toujours du contexte, mais la méthode, elle, ne bouge pas.
Qu’est-ce que l’INP et pourquoi bloque-t-il votre site ?
L’INP mesure le temps entre une interaction utilisateur (clic, tap, appui clavier) et l’affichage de la réaction. Chrome retient la pire interaction observée sur la page — autrement dit, une seule interaction ratée peut plomber votre score global.
| Statut | INP mesuré | Signal Search Console |
|---|---|---|
| Bon | < 200 ms | Vert |
| À améliorer | 200 – 500 ms | Orange |
| Mauvais | > 500 ms | Rouge |
Attention : L’INP remplace FID depuis mars 2024. Si vous optimisez encore FID, votre référencement mobile peut être pénalisé sans que vous compreniez pourquoi.
L’impact n’est pas qu’académique : Google confirme que les Core Web Vitals entrent dans les signaux d’expérience de page. Et concrètement, un INP au-dessus de 500 ms, c’est un utilisateur qui double-clique, croit que le bouton est cassé, et ferme l’onglet. Le vrai coût est là. Et le chrono commence parfois avant même le premier octet, avec l’hébergement et le CDN.
Les 3 phases de l’INP : identifier votre point de rupture
Voilà le point que 90 % des articles sautent. L’INP n’est pas un bloc monolithique : il se décompose en trois segments mesurables séparément. Si vous optimisez à l’aveugle, vous corrigez peut-être la phase qui n’a aucun problème.
Phase 1 — Input Delay (délai d’entrée)
Le temps entre l’interaction et le démarrage du traitement. Il gonfle quand le main thread (le fil d’exécution principal du navigateur) est déjà occupé par une autre tâche — un script d’analytics, un carrousel, une pub tierce. L’utilisateur clique, mais le navigateur est en train de faire autre chose.
Phase 2 — Processing Time (temps de traitement)
La durée d’exécution de vos gestionnaires d’événements (event handlers). Un onclick qui déclenche un tri de 5 000 lignes, une validation de formulaire bavarde, un re-render React de 200 composants : tout ça s’exécute ici.
Phase 3 — Presentation Delay (délai de présentation)
Le temps de recalcul du style, du layout et du rendu. Typiquement provoqué par un accès au DOM qui force un reflow synchrone, ou par une animation CSS mal isolée.
Quelle phase dois-je optimiser ?
Ouvrez Chrome DevTools → onglet Performance → section Interactions. Cliquez sur une interaction lente, et DevTools affiche la décomposition Input / Processing / Presentation. Comparez les trois valeurs :
- Input Delay dominant → vous avez des tâches longues qui bloquent le thread principal.
- Processing Time dominant → vos handlers sont trop lourds.
- Presentation Delay dominant → vos mutations DOM ou animations coûtent cher au rendu.
Sur un site client e-commerce le mois dernier, l’Input Delay représentait 70 % de l’INP. Le coupable ? Un script de chat tiers chargé de manière synchrone. Trois lignes de code plus tard, on avait gagné 180 ms.
Comment réduire l’INP : 6 leviers classés par phase
Maintenant qu’on sait où ça coince, attaquons. Chaque levier est relié à une phase précise.
Phase 1 — Réduire l’Input Delay
Levier 1 : Fractionner les tâches longues avec scheduler.yield(). Une « tâche longue » (long task), c’est tout script qui monopolise le main thread plus de 50 ms. Céder la main régulièrement permet au navigateur de traiter les clics entre deux morceaux.
async function processLargeList(items) {
for (const item of items) {
doWork(item);
if (performance.now() % 5 === 0) {
await scheduler.yield(); // rend la main au navigateur
}
}
}Levier 2 : Prioriser les interactions critiques avec isInputPending(). Cette API vous dit si l’utilisateur a une interaction en attente. Vous pouvez alors interrompre un travail non critique pour le servir tout de suite.
Phase 2 — Réduire le Processing Time
Levier 3 : Déporter le traitement lourd dans un Web Worker. Un Web Worker, c’est un thread séparé du main thread. Tri, parsing, calculs de filtres : tout ce qui prend plus de 30 ms devrait y vivre.
const worker = new Worker('filters.js');
worker.postMessage({ action: 'sort', data: products });
worker.onmessage = (e) => renderResults(e.data);Levier 4 : Débouncer les handlers sur les inputs rapides. Un champ de recherche qui déclenche une requête à chaque frappe (keystroke), c’est la garantie d’un INP catastrophique. Un debounce de 150 ms change la donne.
Phase 3 — Réduire le Presentation Delay
Levier 5 : Différer les recalculs de style non critiques. Un accès synchrone à offsetHeight juste après une modification de style force un reflow complet. Regroupez vos lectures et vos écritures DOM.
Levier 6 : Isoler les animations coûteuses avec will-change. `will-change: transform` prévient le navigateur qu’un élément va bouger : il le hisse sur sa propre couche GPU. Attention à ne pas en abuser — au-delà de 5-6 éléments animés, vous créez plus de problèmes mémoire que vous n’en résolvez.
| Phase | Levier | Gain typique | Effort |
|---|---|---|---|
| Input Delay | scheduler.yield() | -50 à -150 ms | Faible |
| Processing | Web Worker | -100 à -300 ms | Moyen |
| Presentation | Différer les styles | -30 à -100 ms | Faible |
Conseil : Commencez par le levier 1 et le levier 3. En audit, ces deux corrections représentent à elles seules 80 % des gains INP constatés. Les autres affinent.
Mesurer et valider vos gains (avant/après)
Vous avez corrigé. Comment savoir si ça a vraiment marché ? Deux niveaux de mesure, complémentaires.
La mesure terrain via le Chrome UX Report (accessible dans PageSpeed Insights ou Search Console) reflète les vraies interactions utilisateur sur 28 jours glissants. C’est la référence pour Google. Comptez 28 jours de propagation avant de voir la bascule dans le rapport Core Web Vitals. Ce délai conditionne donc toute démarche visant à optimiser les Core Web Vitals.
La mesure labo, plus immédiate, se fait avec DevTools. Et pour automatiser le suivi, ce petit script PerformanceObserver est votre meilleur allié :
new PerformanceObserver((list) => {
list.getEntries().forEach((e) => {
console.log(e.name, e.duration);
});
}).observe({ type: 'event', buffered: true });Après une migration ratée que j’ai dû rattraper l’an dernier, ce script avait révélé que l’INP était, en réalité, plombé par une seule page de blog — pas par le tunnel de commande qu’on soupçonnait. Sans mesure, on aurait optimisé au mauvais endroit.
Questions Fréquentes
Quelle est la différence entre INP et FID ?
FID ne mesurait que le délai d’entrée, tandis que l’INP mesure l’interaction complète. FID captait uniquement le temps entre le clic et le début du traitement (Input Delay). L’INP englobe les trois phases — Input Delay, Processing Time, Presentation Delay — et retient la pire interaction de la page. Depuis mars 2024, seul l’INP compte pour les Core Web Vitals.
Comment optimiser l’INP sur WordPress ?
Réduisez le JavaScript chargé et reportez tout ce qui n’est pas critique. Désactivez les plugins qui empilent des scripts sur toutes les pages, activez le cache et différer les scripts non critiques avec defer ou async. Sur WooCommerce, surveillez spécifiquement les filtres AJAX du catalogue et le mini-panier : ce sont les deux points d’étranglement récurrents.
Pourquoi mon INP est-il mauvais sur mobile uniquement ?
Parce qu’un CPU mobile milieu de gamme est 3 à 5 fois plus lent qu’un desktop, pour un code identique. Ajoutez à ça un réseau 4G variable, et un script de 200 ms sur desktop dépassera facilement 600 ms sur mobile. Testez toujours avec le throttling CPU x4 activé dans DevTools — c’est le seul moyen de reproduire la réalité.
Quel seuil INP viser ?
Moins de 200 ms pour rester en « Bon ». Le seuil n’a pas changé depuis l’intégration officielle et rien n’indique qu’il bougera. En pratique, visez sous 150 ms sur mobile : vous gardez ainsi une marge de sécurité sur les pages les plus lourdes.
Peut-on améliorer l’INP sans toucher au code ?
Partiellement, oui. Supprimer deux ou trois scripts tiers (chat, heatmap, A/B testing oublié), activer un CDN et un cache agressif suffit souvent à repasser sous les 200 ms. En revanche, si le problème est dans vos propres handlers JavaScript, il faudra mettre les mains dans le code. Ou payer quelqu’un pour le faire — comptez 1 à 3 jours de prestation selon la complexité.
Ce qu’il faut retenir pour restaurer votre interactivité
Identifier la phase, appliquer le levier, mesurer. Cette séquence simple évite 90 % des optimisations dans le vide. Et une fois les tâches longues corrigées, vous verrez que beaucoup d’autres problèmes de performance disparaissent avec elles — améliorer l’interactivité d’un site web, c’est aussi alléger tout le reste. Cette même séquence — phase, levier, mesure — sert aussi à optimiser le SEO avec l’IA.
Le vrai piège, c’est de croire qu’il existe une astuce miracle. Il n’y en a pas. Je vois encore des sites qui achètent des packs « +100 points PageSpeed » à 500 € : ils repartent avec un cache activé et zéro correction réelle. Le seul chemin fiable passe par la mesure et la correction ciblée. Et cette correction commence souvent par un poste très concret : l’optimisation des images.
Réduire l’INP pour améliorer l’interactivité d’un site, c’est d’abord accepter que ça dépend de votre contexte — et qu’un audit sérieux vaut mieux que dix plugins correctifs.