Améliorer l’INP : traquer les tâches longues JavaScript

Q: Quel est le bon seuil pour l’INP ?

Un INP inférieur ou égal à 200 millisecondes au 75e centile des visites, mesuré séparément sur mobile et sur ordinateur. Au moins trois visites sur quatre doivent donc passer sous ce seuil : les appareils modestes et les réseaux chargés pèsent dans le résultat.

Le rapport Core Web Vitals de la Search Console affiche « problème INP », alors que le score de laboratoire paraît correct. Rien d’anormal : l’Interaction to Next Paint ne se révèle qu’au contact des visiteurs, quand ils cliquent et tapent sur des appareils qui ne ressemblent pas toujours au vôtre.

Comment améliorer l’INP de son site sans réécrire tout le front ? En menant une enquête plutôt qu’en empilant des recettes : trouver les interactions lentes, comprendre où part le temps, corriger la cause, vérifier le gain. Ce décryptage suit cet ordre, secteur par secteur.

L’INP en clair : ce que ressent l’utilisateur

L’INP mesure le délai entre un geste et la réponse visible qui le suit. Le geste : un clic, un appui sur l’écran, une touche du clavier. La réponse : la prochaine image affichée, qu’il s’agisse du menu qui se déploie, de la case qui se coche ou du compteur du panier qui change.

L’indicateur observe les interactions de toute la visite et retient l’une des plus lentes ; le défilement et le survol ne comptent pas. Une page est jugée « bonne » avec un INP inférieur ou égal à 200 millisecondes au 75^e centile des visites. Au-delà, elle passe en zone « à améliorer », puis « médiocre ». Pour le visiteur, c’est simple : il tape, rien ne se passe, il tape de nouveau, et le double appui ajoute deux articles au panier.

Pourquoi l’INP a remplacé le FID en mars 2024

Le First Input Delay ne mesurait que l’attente avant le traitement de la première interaction, sans le traitement lui-même ni l’affichage de la réponse. Beaucoup de sites réussissaient l’examen alors que leurs boutons peinaient au troisième clic. En mars 2024, l’INP l’a remplacé parmi les Core Web Vitals : il couvre toute la visite et toute la chaîne, du geste à l’image suivante. D’où l’apparition d’alertes sur des sites qui n’en avaient jamais reçu.

Trouver les interactions lentes avec les données de terrain

Le laboratoire ne sait pas où vos visiteurs cliquent : le point de départ est le terrain, à trois niveaux de précision.

La Search Console désigne les groupes d’URL en échec, sur mobile ou sur ordinateur. Elle dit où chercher, pas quoi corriger.
Les données CrUX, dans PageSpeed Insights ou via leur API, donnent l’INP au 75^e centile d’une URL ou de l’origine entière, avec son historique.
Une mesure chez vos visiteurs (RUM), par exemple avec la bibliothèque open source web-vitals dans sa version d’attribution, révèle l’élément touché, le moment de la visite et la décomposition du temps.

Ce troisième niveau fait gagner des semaines. Un INP médiocre sur un gabarit de catégorie ne dit rien de sa cause ; savoir que l’interaction la plus lente est l’ouverture du filtre « Taille », dans les premières secondes de la visite et sur des téléphones d’entrée de gamme, dit presque tout. Envoyez ces données vers l’outil d’analyse que vous possédez déjà : inutile d’ajouter un script tiers pour mesurer le coût des scripts tiers.

Reproduire en laboratoire et décomposer le temps

Profiler une interaction

On rejoue l’interaction suspecte dans le panneau Performance des outils de développement de Chrome : processeur ralenti pour approcher un téléphone modeste, fenêtre sans extensions, bannière de consentement dans son état réel. Enregistrez, faites le geste, arrêtez. La piste du fil principal montre les tâches qui l’occupent et les scripts d’où elles viennent ; les tâches longues, au-delà de 50 millisecondes selon la définition de l’API Long Tasks, y sont marquées en rouge.

Délai d’entrée, traitement, rendu : les trois phases

Chaque interaction se découpe en trois phases successives, qui appellent des correctifs différents.

Décomposition d’une interaction lente

Délai d’entrée: Le geste attend : une tâche longue occupe déjà le fil principal.
Traitement: Les gestionnaires d’événements liés au geste s’exécutent.
Rendu: Styles, mise en page et peinture de l’image suivante.

Cas type, proportions d’exemple : ici, l’essentiel du temps se perd avant même l’exécution du code du bouton.

Les trois phases d’une interaction et leurs leviers
Phase	Ce qui se passe	Causes typiques	Leviers
Délai d’entrée	Le geste attend que le fil principal se libère	Tâches longues en cours : scripts au démarrage, tiers	Découper les tâches, différer le non critique
Traitement	Les gestionnaires d’événements s’exécutent	Code applicatif lourd, mises à jour en cascade	Retour visuel d’abord, le reste ensuite
Rendu	Styles, mise en page et peinture de la réponse	DOM volumineux, mises en page forcées	Alléger le DOM, `content-visibility`

Cette lecture évite un contresens fréquent : accuser le code du bouton alors que le temps se perd avant même son exécution, parce qu’un script d’analyse occupe le fil principal au même moment.

Découper les tâches longues et rendre la main au navigateur

Le fil principal exécute une tâche à la fois : tant qu’une tâche longue tourne, aucun geste n’est traité et aucune image n’est affichée. Le correctif tient en une phrase : faire tout de suite l’urgent, rendre la main, puis faire le reste. On sépare ce que l’utilisateur doit voir immédiatement (bouton enfoncé, panneau ouvert, indicateur de chargement) de ce qui peut attendre (événement d’analyse, recalcul d’une longue liste, sauvegarde d’une préférence).

Côté code

Un gestionnaire de clic qui rend la main entre l’urgent et le différable :

function rendreLaMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((ok) => setTimeout(ok, 0));
}

async function surClicFiltre(filtre) {
  marquerActif(filtre); // retour visuel
  await rendreLaMain(); // le navigateur peint
  for (const lot of enLots(filtrer(filtre), 24)) {
    afficher(lot);
    await rendreLaMain(); // un geste peut passer
  }
  envoyerMesure('filtre', filtre); // en dernier
}

scheduler.yield() est utilisé là où le navigateur le prend en charge, avec un repli sur setTimeout ailleurs.

D’autres leviers complètent ce découpage :

regrouper les saisies d’un champ de recherche au lieu de relancer un calcul à chaque frappe ;
éviter les mises en page forcées en groupant les lectures de dimensions, puis les écritures dans le DOM ;
alléger le DOM, et épargner le rendu des blocs hors écran avec content-visibility: auto ;
déporter les calculs lourds dans un Web Worker, hors du fil principal.

Scripts tiers : mesurer, différer ou retirer

Mesure d’audience, gestionnaire de balises, consentement, test A/B, publicité, discussion en ligne : chaque script tiers a été ajouté pour une bonne raison, et rarement réévalué depuis. Ensemble, ils occupent le fil principal dans les premières secondes, quand le visiteur commence justement à interagir.

Mesurer. Regroupez l’activité par domaine dans le panneau Performance, puis bloquez un script à la fois depuis l’onglet Réseau et rejouez la même interaction : l’écart donne son coût réel.
Différer. Ce qui ne sert pas au premier écran attend la fin de l’affichage. Widget de discussion, vidéo ou carte se remplacent par une façade qui charge le vrai composant au premier clic.
Retirer. Balises d’anciennes campagnes, outils dont personne ne lit plus les données, doublons de mesure : c’est souvent le gain le plus rapide, et le moins risqué.

La décision se prend avec les équipes concernées, car certains scripts portent des revenus ou des outils métier : un arbitrage mesuré, pas une purge aveugle.

Frameworks et hydratation : alléger le travail au démarrage

Avec React, Vue, Angular et leurs surcouches de rendu serveur, le HTML s’affiche vite, mais la page n’est interactive qu’une fois le JavaScript rattaché aux composants : c’est l’hydratation. Pendant cette longue tâche, les clics attendent. Cas type : sur une page de catégorie, le visiteur touche le bouton de tri et rien ne se passe pendant que toute la page s’hydrate, pied de page et carrousels compris. Trois leviers, du plus simple au plus structurant :

découper le code par route et par composant, pour ne livrer que ce que la page utilise ;
hydrater d’abord les composants interactifs du premier écran, et le reste à son apparition ou au premier geste ;
laisser statiques les blocs sans interactivité, grâce aux architectures en îlots ou aux composants serveur.

Sur WordPress ou un CMS e-commerce, l’équivalent se trouve dans les extensions, qui chargent souvent leurs scripts sur toutes les pages : retirer ces scripts des gabarits où ils ne servent pas constitue un premier tour rapide.

Contrôler le gain sur les mêmes pages et dans les mêmes conditions

Un correctif d’INP se valide deux fois : en laboratoire le jour de la mise en production, puis sur le terrain au fil des semaines. La check-list de contrôle :

même interaction, même page, même ralentissement du processeur qu’au relevé de départ ;
plusieurs enregistrements avant et après, pour lire une tendance plutôt qu’un essai isolé ;
tâche longue visée disparue ou fragmentée dans la piste du fil principal ;
INP au 75^e centile suivi par gabarit dans la mesure RUM, mobile et ordinateur séparés ;
date de mise en production notée, puis validation lancée dans la Search Console ;
alerte en cas de régression, par exemple après l’ajout d’un nouveau script tiers.

CrUX et la Search Console reposent sur une fenêtre glissante de 28 jours, selon la documentation de CrUX : le gain y apparaît progressivement. La mesure chez vos visiteurs, elle, le montre dès les premiers jours.

Questions fréquentes sur l’INP

Q01

Quel est le bon seuil pour l’INP ?

Un INP inférieur ou égal à 200 millisecondes au 75^e centile des visites, mesuré séparément sur mobile et sur ordinateur. Au moins trois visites sur quatre doivent donc passer sous ce seuil : les appareils modestes et les réseaux chargés pèsent dans le résultat.

Q02

Lighthouse peut-il mesurer l’INP ?

Pas lors d’un test de chargement classique, puisqu’aucune interaction n’a lieu : le Total Blocking Time n’en est qu’un indicateur indirect. Pour mesurer un INP en laboratoire, il faut rejouer de vrais gestes, avec le mode « période » de Lighthouse ou le panneau Performance de Chrome.

Q03

Faut-il supprimer tous les scripts tiers pour améliorer l’INP ?

Non, car certains portent des revenus ou des outils indispensables. On mesure le coût de chacun sur les interactions réelles, on diffère ceux qui ne servent pas immédiatement, on charge à la demande ceux que peu de visiteurs utilisent et l’on retire ceux qui ne servent plus.

Q04

Combien de temps faut-il pour voir l’INP corrigé dans la Search Console ?

Plusieurs semaines, car le rapport s’appuie sur les données CrUX agrégées sur 28 jours glissants. Une mesure chez vos visiteurs et des tests de laboratoire répétés confirment le gain bien avant que le statut du groupe d’URL ne change.

Améliorer l’INP de son site : la ligne d’arrivée

Améliorer l’INP, ce n’est pas chasser un score : c’est rendre à chaque geste une réponse immédiate. Partir du terrain pour savoir quelles interactions souffrent, rejouer en laboratoire pour voir où part le temps, traiter d’abord les tâches longues et les scripts qui monopolisent le fil principal, puis contrôler sur les mêmes pages, dans les mêmes conditions.

Les gains les plus nets viennent rarement d’une prouesse technique, mais d’un inventaire honnête de ce que la page exécute. Pour aller plus loin sur la mesure, le décryptage consacré à l’écart entre un score PageSpeed vert et une Search Console en rouge aide à lire ces deux sources sans se tromper de diagnostic.