INP — la métrique Core Web Vitals devenue critique en 2026

INP (Interaction to Next Paint) a remplacé FID dans les Core Web Vitals officiels depuis mars 2024. Deux ans après, la métrique pèse de plus en plus dans le ranking Google. Sur 20 sites SiteNova, voici comment on a optimisé INP — et les pièges à éviter.

INP : la définition courte

INP mesure le délai entre l’interaction de l’utilisateur (clic, tap, keypress) et le moment où le navigateur affiche le résultat visuel de cette interaction. Concrètement : combien de temps le site reste « figé » après que vous cliquiez sur un bouton.

Les seuils officiels Google :

• Bon : ≤ 200 millisecondes
• À améliorer : 200-500 ms
• Mauvais : > 500 ms

INP est mesuré sur l’interaction la plus lente de la session utilisateur (au 98e centile), pas sur la moyenne. C’est ce qui rend la métrique exigeante : une seule interaction lente plombe tout le score.

Pourquoi INP est devenu plus critique en 2026

Depuis l’intégration officielle en mars 2024, Google a progressivement augmenté le poids de l’INP dans son algorithme. En mai 2026 :

1. INP est un signal direct dans le ranking organique (factor confirmé par John Mueller)
2. INP fait partie du score « Page Experience » qui peut désormais bloquer l’apparition dans les Top Stories
3. Les sites avec INP « mauvais » sur 50 % de leurs pages ne peuvent plus passer en Discover

Conséquence : un site avec FCP/LCP excellents mais INP médiocre peut perdre 15-30 % de visibilité organique sans toucher au contenu.

Les chiffres sur l’empire SiteNova

En analysant les 20 sites de l’empire via PageSpeed Insights API (mesures sur 75e centile field data, mai 2026) :

Le site « mauvais » est un site WooCommerce avec énormément de scripts tiers (analytics, retargeting, chat, popup). Il sert d’étude de cas dans la suite.

Les 5 causes principales d’INP dégradé

1. Scripts tiers non-asynchrones

Tag Manager, pixels Meta, Hotjar, popup providers, chat widgets — tous bloquent le main thread si chargés synchronement. Le coupable n°1 dans 80 % des cas SiteNova.

Fix : passer tous les scripts non-critiques en async ou defer. Pour Tag Manager, charger en async. Pour les pixels Meta, utiliser leur loader async officiel.

2. JavaScript long-tasks (>50ms)

Les long-tasks JS bloquent le main thread et empêchent le navigateur de répondre aux interactions. Visibles dans Chrome DevTools → Performance → Long Tasks.

Fix : découper les gros bundles JS, utiliser `requestIdleCallback`, déléguer le travail lourd à des Web Workers, minifier et tree-shake le code inutile.

3. Event handlers complexes

Listeners qui font des calculs lourds ou des requêtes DOM en cascade au moment du clic. Exemple typique : un menu déroulant qui recalcule les positions de 200 sous-éléments à chaque survol.

Fix : passer en CSS pur quand possible (transition, animation), utiliser `requestAnimationFrame`, debouncer/throttler les handlers, virtualiser les listes longues.

4. Layout thrashing

Quand un script alterne lecture/écriture du DOM rapidement, le navigateur recalcule le layout entre chaque opération. Très coûteux en performance.

Fix : grouper les lectures DOM puis les écritures DOM séparément. Utiliser `getBoundingClientRect` une fois, pas dix.

5. Hydration lourde (frameworks SPA)

Sur les sites Next.js, Nuxt, Astro avec hydration côté client, l’INP peut exploser pendant les premières secondes le temps que le framework prenne le contrôle.

Fix : utiliser le partial hydration (Astro Islands, React Server Components), précharger les chunks critiques, optimiser le bundle splitting.

Étude de cas : le site WooCommerce 640ms → 180ms

Un site e-commerce de l’empire (1 200 produits, ~30 000 visites/mois) avait un INP de 640ms sur mobile en mars 2026. Voici les optimisations appliquées sur 6 semaines :

Étape 1 : audit scripts tiers

15 scripts tiers identifiés. 8 supprimés (services non utilisés). 7 conservés mais migrés en async/defer.

Résultat : INP 640ms → 480ms (−25 %).

Étape 2 : nettoyage Tag Manager

Audit GTM révèle 23 tags actifs dont 11 inutilisés. Suppression des inutiles, regroupement des nécessaires.

Résultat : INP 480ms → 380ms (−21 %).

Étape 3 : suppression de la popup d’inscription newsletter

La popup utilisait un provider tiers lourd. Remplacement par une popup native en CSS/JS minimal.

Résultat : INP 380ms → 240ms (−37 %).

Étape 4 : optimisation menu mobile

Le menu hamburger recalculait la hauteur de 80 sous-items à chaque ouverture. Fix : caching de la hauteur en CSS variable + utilisation de CSS transitions au lieu de JS.

Résultat : INP 240ms → 195ms (−19 %).

Étape 5 : passage Cloudflare APO

Cache edge + minification automatique. Détail technique : APO offload une partie du rendu HTML au edge.

Résultat final : INP 195ms → 180ms (−8 %). Score « Bon » atteint.

Outils recommandés pour mesurer INP

• PageSpeed Insights — INP field data (utilisateurs réels) sur 28 derniers jours
• Search Console → Core Web Vitals — état INP de toutes vos pages
• Chrome DevTools → Performance — analyser interactions une par une en local
• web.dev/measure — tests automatisés avec recommandations
• Calibre / SpeedCurve — monitoring continu (payant)

Priorités d’action recommandées

Si votre INP est mauvais, voici l’ordre dans lequel attaquer (du plus impactant au moins impactant en moyenne) :

1. Supprimer scripts tiers inutiles (Tag Manager bloat, pixels, chat) — gains rapides 30-50 %
2. Passer tout en async/defer — gains 15-25 %
3. Audit GTM — gains 10-20 %
4. Optimiser menus et popups — gains 10-20 %
5. Refactoring event handlers — gains 5-15 %
6. Edge caching (Cloudflare APO, Fastly) — gains 5-10 %

Pour un audit Core Web Vitals complet incluant INP page par page avec plan d’action priorisé, SiteNova propose un diagnostic en 5 jours ouvrés. Les corrections sont ensuite chiffrées et planifiées par effort/impact.