Le changement que beaucoup de sites n'ont pas vu passer
En mars 2024, Google a retiré le FID (First Input Delay) de ses Core Web Vitals pour le remplacer par l'INP, Interaction to Next Paint. Sur le papier, un simple changement de sigle. En pratique, des milliers de sites qui affichaient un score « bon » sont passés à « à améliorer » du jour au lendemain, sans qu'une seule ligne de code ait changé.
La raison est simple : le FID était une métrique laxiste. Il ne mesurait que le délai avant traitement de la première interaction. L'INP mesure la réactivité de toutes les interactions d'une session (clics, taps, saisies clavier) et retient à peu près la pire. Un site pouvait avoir un FID excellent et des menus qui ramaient à chaque clic. Avec l'INP, ça se voit.
Les seuils à connaître
Google classe l'INP en trois zones : bon en dessous de 200 millisecondes, à améliorer entre 200 et 500 ms, mauvais au-delà de 500 ms. La mesure retenue est celle du 75e percentile des utilisateurs réels, collectée via le rapport CrUX. Autrement dit : ce que vivent vos visiteurs sur leurs vrais téléphones, pas ce que mesure votre machine de bureau sur la fibre.
C'est là que beaucoup se font surprendre. Un test Lighthouse sur un poste récent ne dit presque rien de l'INP réel. Le même site testé sur un Android milieu de gamme à 200 euros, qui représente une énorme part du trafic français, peut afficher trois fois pire.
Ce qui plombe un INP, dans la vraie vie
Sur les audits que nous réalisons, les mêmes causes reviennent presque toujours :
- Le JavaScript tiers. Tag managers chargés de dizaines de balises, widgets de chat, players vidéo, pixels publicitaires. Chaque script se dispute le thread principal, et c'est l'utilisateur qui attend.
- Les longues tâches au clic. Un bouton « Ajouter au panier » qui déclenche 400 ms de calculs JavaScript avant le moindre retour visuel. L'utilisateur clique, rien ne bouge, il reclique.
- Les frameworks mal hydratés. Une page React ou Vue qui semble affichée mais dont le JavaScript n'a pas fini de s'initialiser. Les premières secondes, chaque interaction tombe dans le vide.
- Les animations qui bloquent. Des transitions déclenchées en JavaScript sur des propriétés qui forcent le navigateur à tout recalculer, au lieu d'animations CSS composées sur le GPU.
Comment nous diagnostiquons un mauvais INP
Première étape : les données terrain. Le rapport CrUX (via PageSpeed Insights) donne l'INP réel par page ou par origine. La Search Console signale les groupes de pages problématiques. Ça dit où chercher, pas quoi corriger.
Deuxième étape : reproduire. DevTools de Chrome, onglet Performance, CPU bridé à 4x ou 6x pour simuler un mobile moyen, et on enregistre une session en interagissant avec la page. Les longues tâches apparaissent en rouge, avec la pile d'appels qui dit exactement quel script consomme le temps. En général, le coupable est identifié en moins d'une heure. La correction, elle, peut prendre une journée comme une semaine, selon qu'il s'agit de retirer un script tiers ou de découper une application entière.
Les corrections qui rapportent le plus
Par ordre de rentabilité constatée chez nos clients : supprimer ou différer les scripts tiers non essentiels (souvent 100 à 200 ms gagnées d'un coup), donner un retour visuel immédiat à chaque interaction puis traiter le gros du travail ensuite, découper les longues tâches JavaScript, et passer les animations en CSS. Sur un site e-commerce que nous avons repris cet hiver, ces quatre chantiers ont fait passer l'INP de 460 ms à 140 ms. Le taux de conversion mobile a suivi.
Un point souvent négligé : le choix technique de départ conditionne tout. Un site construit en rendu statique ou serveur, avec un JavaScript minimal côté client, part avec un INP quasi parfait. C'est l'approche que nous défendons sur nos prestations performance et lors des refontes : la métrique se gagne à l'architecture, pas au patch.
INP et SEO : ce qu'il faut en attendre
Soyons honnêtes : les Core Web Vitals sont un critère de classement parmi des centaines, et un bon INP ne fera pas grimper un contenu médiocre. L'enjeu est ailleurs. Un INP à 500 ms, c'est un site qui paraît cassé sur mobile. Les gens repartent, et ce comportement-là, Google le voit très bien. La performance est d'abord une question de chiffre d'affaires ; le SEO en est la conséquence.
Si votre Search Console affiche de l'orange ou du rouge sur les Core Web Vitals, un audit de performance dira en quelques jours ce qui coince et ce que ça coûte de le corriger.
Cas concret : un e-commerce toulousain de 460 à 140 ms
Pour donner de la chair aux principes, voici le déroulé réel d'une mission de cet hiver. Boutique sous WooCommerce, 8 000 visites par jour, INP mesuré à 460 ms au 75e percentile. Les alertes Search Console avaient déclenché la demande.
Le diagnostic a pris une matinée. Enregistrement de sessions avec CPU bridé, et trois coupables sont sortis du lot : un tag manager qui chargeait 23 balises dont 9 mortes (comptes fermés, outils abandonnés), un script de recommandation produits qui recalculait tout le carrousel à chaque interaction, et le thème qui déclenchait une animation JavaScript sur chaque survol de la grille produits.
Les corrections, dans l'ordre : ménage dans le tag manager (un après-midi, 110 ms gagnées à elle seule), report du script de recommandation après la première interaction (une journée), remplacement des animations de survol par du CSS pur (une demi-journée). Résultat consolidé sur les données terrain quatre semaines plus tard : INP à 140 ms, et un taux d'ajout au panier mobile en hausse de 11 %. Aucune refonte, aucun changement visible pour l'utilisateur, uniquement du nettoyage rigoureux.
Les outils, du gratuit au pointu
Pour surveiller : PageSpeed Insights donne l'INP terrain par URL, la Search Console regroupe les pages à problème, et le rapport CrUX historise l'évolution mois par mois. Pour diagnostiquer : l'onglet Performance de Chrome DevTools reste l'outil roi, avec sa timeline des longues tâches. L'extension Web Vitals affiche les métriques en direct pendant que vous naviguez sur votre propre site, interaction par interaction : c'est le moyen le plus rapide de sentir où ça accroche.
Pour les équipes qui veulent industrialiser, un monitoring RUM (Real User Monitoring) remonte l'INP de chaque session réelle avec le détail de l'élément touché. C'est ce que nous installons sur les sites à fort trafic : quand une régression apparaît après une mise en production, on le sait le jour même, pas au prochain rapport CrUX six semaines plus tard.
Et si votre site est sous WordPress ?
Les sites WordPress cumulent souvent les handicaps : constructeurs de pages lourds, extensions qui chargent leur JavaScript partout, thèmes généralistes. Trois gestes rapportent presque toujours : désactiver les extensions inutilisées (vraiment les désinstaller, pas juste les désactiver), limiter le constructeur de pages aux pages qui en ont besoin, et charger les scripts d'extensions uniquement sur les pages concernées via un plugin de gestion d'assets. Si après ça l'INP reste au-dessus de 300 ms, la question du changement de socle technique mérite d'être posée sérieusement, chiffres en main.
Dernier conseil de terrain : mesurez avant de payer. Beaucoup de prestations « optimisation vitesse » vendues au forfait appliquent les mêmes recettes génériques sans diagnostic. Exigez un avant/après sur les données CrUX réelles, pas sur un score Lighthouse de laboratoire : c est la seule mesure qui compte pour Google, et la seule que vivent vos visiteurs.
