Améliorer Interaction to Next Paint : diagnostiquer saisie, traitement et affichage

Pour améliorer Interaction to Next Paint, reproduisez une interaction lente et déterminez si le retard se situe avant ses gestionnaires, pendant leur exécution ou avant l’image suivante. Supprimez les traitements inutiles, découpez le travail restant lorsque sa correction le permet et réduisez le rendu coûteux. Confirmez le résultat avec des enregistrements interactifs et des mesures réelles, pas seulement un meilleur score de chargement.

INP est bon à 200 millisecondes ou moins au 75e centile. Il décrit la réactivité pendant une visite : l’action déterminante peut survenir longtemps après que la page semble prête. Un filtre produit ou une commande de navigation peut poser problème malgré un chargement rapide.

Comprenez ce que mesure INP et ce qu’il exclut

INP évalue les clics, appuis et interactions clavier admissibles. Il considère le délai jusqu’au prochain affichage après le traitement concerné. Ce n’est ni la simple durée du gestionnaire ni le chronométrage de tout le processus métier suivant le clic.

Une recherche peut par exemple afficher immédiatement un état de chargement pendant qu’une requête asynchrone récupère les résultats. Cette réaction rapide améliore la réactivité sans accélérer le réseau. Mesurez aussi l’achèvement de la tâche si l’objectif dépend du résultat ultérieur.

La métrique reflète généralement l’interaction la plus lente de la visite, avec traitement des valeurs extrêmes pour les visites riches en interactions. Sans interaction admissible, il n’y a pas de valeur INP. Ne remplacez pas l’absence par zéro et ne l’interprétez pas comme une réaction instantanée.

INP a remplacé First Input Delay parmi les Core Web Vitals en mars 2024. FID couvrait seulement l’attente initiale de la première interaction admissible, pas la réponse complète pendant la visite. Les anciens conseils centrés sur FID peuvent donc manquer une interaction lente ultérieure ou une présentation coûteuse.

Le guide Core Web Vitals pour débutants replace seuils et centiles dans leur contexte. Distinguez ces résultats de population d’une interaction volontairement reproduite en développement.

Décomposez la latence en trois phases

Chaque phase oriente une investigation différente. Le guide d’optimisation INP de Google relie ainsi la mesure aux traitements du thread principal.

Un gestionnaire court peut sembler lent si un autre script bloque son démarrage. Il peut aussi finir vite alors que la disposition qui suit demande beaucoup de travail. Mesurer seulement une fonction manque les deux situations.

Commencez par la phase la plus longue de la trace problématique. Après amélioration, examinez l’interaction entière. Déplacer du travail d’une phase à une autre ne réduit pas forcément la latence totale. Une mise à jour plus petite peut en revanche améliorer plusieurs phases à la fois.

Enregistrez un état représentatif de l’interaction

Utilisez Performance dans Chrome DevTools pour enregistrer l’action elle-même. Lancez l’enregistrement, reproduisez l’interaction, arrêtez, puis examinez la chronologie. Incluez l’état pertinent : menu ouvert, panier rempli, liste développée ou contenu ajouté après défilement.

Une page neuve et vide ne reproduit pas forcément un problème apparaissant après plusieurs mises à jour. À l’inverse, des extensions sans rapport peuvent ajouter des traitements absents chez les visiteurs. Contrôlez l’environnement tout en conservant les composantes du vrai parcours qui affectent le résultat.

Testez si possible sur un matériel représentatif. Le ralentissement simulé du processeur révèle des sensibilités, mais reste une simulation à documenter comme telle. Ne présentez pas une trace locale bridée comme une mesure sur un téléphone précis si vous n’avez pas testé cet appareil.

Conservez cible, conditions et pile d’appels concernée. Un rapport utile indique quelle commande répond lentement et ce qui occupe l’intervalle. Une capture d’un score rouge agrégé oblige la personne suivante à recommencer l’investigation.

Ajoutez l’attribution au-delà des rapports agrégés

CrUX et Search Console peuvent détecter un problème de population sans identifier le composant ou le déploiement responsable. Votre instrumentation peut associer les interactions lentes au contexte applicatif, sous réserve de confidentialité et de prise en charge du navigateur.

Ce module utilise le paquet compatible installé de web-vitals dans sa version d’attribution. Il journalise les durées des phases sans envoyer de détails d’interaction à un serveur.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.table({
    inp: value,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay
  });
});

Vérifiez l’API avec votre version installée. Un collecteur de production exige agrégation, déduplication et politique sur le contexte enregistré. Ne collectez pas texte saisi, identifiants de compte ou URL complètes contenant des paramètres privés simplement parce que leur ajout est commode.

Traitez l’attribution comme une piste à reproduire. Sa couverture peut différer de CrUX et un agrégat peut masquer plusieurs types d’interactions lentes. Regroupez par modèle ou composant pertinent plutôt que d’attribuer une cause unique à tous les échantillons lents.

Supprimez le travail qui bloque le démarrage

Le thread principal ne peut pas exécuter un gestionnaire d’entrée lorsqu’une autre tâche l’occupe. Une tâche de plus de 50 millisecondes est dite longue, mais des tâches plus courtes peuvent aussi contribuer lorsque planification et rendu s’accumulent.

Examinez l’intervalle précédant immédiatement les gestionnaires. Recherchez code de démarrage, minuteries répétées, analyse, hydratation et widgets externes. La commande peut être innocente : un menu léger est lent parce qu’un travail indépendant monopolise déjà le thread.

Supprimez fonctions inutilisées et initialisations doubles avant une planification élaborée. Le découpage du code évite de charger et d’évaluer des fonctions inutiles à une route. Différer un script change son moment d’exécution, mais pas son coût.

Pour le code coûteux indispensable, examinez une exécution en tâches plus petites ou hors du thread principal. Le guide du temps d’exécution JavaScript détaille ces choix. L’objectif est de réduire la concurrence autour des vraies interactions, pas uniquement autour du chargement initial.

Cédez la main entre des morceaux indépendants

Découper une fonction en plusieurs petites fonctions ne découpe pas automatiquement la tâche navigateur. Les appeler à la suite dans le même gestionnaire conserve le thread occupé jusqu’à la fin.

scheduler.yield() reprend le traitement dans une tâche ultérieure. Comme la prise en charge varie, détectez la fonctionnalité et prévoyez une solution de repli. Une minuterie crée aussi une nouvelle tâche, mais sans la même priorité de continuation.

Cet exemple navigateur complet traite une collection locale par fragments illustratifs. Leur taille démontre la technique ; ce n’est pas un budget de performance universel.

<button id="process" type="button">Process example data</button>
<p id="progress" role="status">Ready</p>
<script type="module">
  const button = document.querySelector('#process');
  const progress = document.querySelector('#progress');
  const values = Array.from({ length: 10000 }, (_, index) => index);

  async function yieldToBrowser() {
    if (globalThis.scheduler?.yield) {
      await globalThis.scheduler.yield();
    } else {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }

  button.addEventListener('click', async () => {
    button.disabled = true;
    progress.textContent = 'Processing';
    try {
      let total = 0;
      for (let start = 0; start < values.length; start += 250) {
        await yieldToBrowser();
        const end = Math.min(start + 250, values.length);
        for (let index = start; index < end; index++) {
          total += values[index];
        }
      }
      progress.textContent = `Total: ${total}`;
    } finally {
      button.disabled = false;
    }
  });
</script>

Céder la main donne au navigateur l’occasion d’autres traitements. Cela ne garantit pas l’affichage d’une image précise à un instant choisi. Mesurez l’opération réelle sur des appareils représentatifs et ajustez le travail par fragment.

Ne cédez pas au milieu d’une modification d’état qui doit rester atomique. Un autre code peut intervenir et modifier l’état partagé avant la reprise. Préservez la correction, gérez l’annulation si nécessaire et rendez les activations répétées sûres. Une interface rapide qui applique deux fois l’action n’est pas une amélioration.

Réservez requestIdleCallback au véritable travail facultatif d’arrière-plan, avec détection et repli approprié. Son rappel peut attendre si le navigateur est occupé. Il ne remplace ni le retour immédiat ni un traitement nécessaire à l’achèvement. Un délai maximal limite l’attente, mais l’exécution n’est alors plus réservée aux périodes inactives.

Gardez la réponse immédiate petite et utile

Cherchez les traitements qui ne doivent pas précéder le retour visuel. Modifier une sélection peut être essentiel. Recalculer un rapport indépendant, charger un widget masqué ou envoyer une analyse secondaire peut ne pas l’être.

Ne remplacez pas un vrai retour par un succès trompeur. Si l’opération peut échouer, affichez son déroulement plutôt que son achèvement. Préservez les erreurs et annonces d’accessibilité pour offrir une information équivalente au clavier et aux technologies d’assistance.

Les workers aident pour des calculs adaptés, comme l’analyse ou la transformation de grandes collections. Ils ne manipulent pas directement le DOM et leur communication a un coût. Déplacer une opération minuscule ajoute parfois seulement de la complexité ; déplacer le bon calcul coûteux libère le thread pour entrée et rendu.

Examinez aussi la fréquence des gestionnaires. Écouteurs dupliqués, effets répétés et propagation inutile de l’état multiplient un travail modeste. Supprimez la duplication au lieu de la cacher derrière un délai.

Pour les saisies répétées, notamment les suggestions de recherche, le debounce peut éviter chaque valeur intermédiaire. Gardez la saisie réactive, choisissez le délai selon la tâche et annulez ou ignorez les résultats asynchrones périmés. Ne temporisez pas toutes les commandes sans distinction et ne retardez pas l’accusé visuel par un minuteur arbitraire.

Réduisez le rendu après le gestionnaire

La présentation peut dominer lorsqu’une interaction modifie une grande partie de la page. Examinez recalcul des styles, disposition et peinture après le retour du gestionnaire. Une courte fonction insérant des milliers de nœuds peut déclencher beaucoup de travail navigateur.

Actualisez la plus petite région pertinente. Envisagez pagination ou virtualisation soigneuse des grandes collections, en conservant navigation, focus et contenu accessible. Un DOM initial plus petit aide seulement si une interaction ultérieure ne recrée pas tout le problème d’un coup.

Évitez d’alterner constamment lectures de géométrie et écritures dans une boucle. Lire une géométrie à jour après une modification de style peut forcer une disposition synchrone. Regroupez les mesures puis appliquez les changements lorsque possible, et vérifiez dans la trace la diminution de ces calculs forcés.

N’utilisez pas un nombre particulier de nœuds DOM comme seuil universel. Complexité, dépendances de styles et région actualisée affectent le coût. La preuve doit être le rendu causé par l’interaction, pas seulement un compteur inférieur à une valeur mémorisée.

Auditez les tiers pendant la même action

Gestionnaires de balises, chat, expérimentation et publicité peuvent s’exécuter autour d’interactions alors que leurs requêtes réseau sont terminées. Un audit uniquement réseau manque ce coût d’exécution.

Dans un test contrôlé, bloquez temporairement la ressource suspecte ou désactivez une intégration précise, puis répétez l’action. Vérifiez le fonctionnement et l’isolement de la cause. Une dépendance manquante qui casse la fonction peut produire une trace faussement rapide.

Attribuez à chaque intégration un responsable et une raison de fonctionner à cet endroit du parcours. Chargez un élément facultatif à la demande si cela sert l’utilisateur, mais souvenez-vous que sa première interaction peut alors inclure l’initialisation. Une façade ne doit pas simplement reporter tout le coût sur le clic d’activation.

Validez au-delà d’une trace favorable

Une navigation Lighthouse standard mesure le chargement et fournit TBT comme indicateur de blocage. Elle ne produit pas les interactions des visiteurs nécessaires à l’INP de terrain. Ne convertissez pas TBT en INP et ne prenez pas un meilleur score pour la preuve que le filtre lent est réparé.

Répétez la vraie interaction dans des conditions comparables. Contrôlez phases, réaction visible, résultat final et erreurs. Après déploiement, surveillez les données réelles par catégorie d’appareil et modèle pertinents.

Utilisez la liste de contrôle des performances pour noter modification et vérification. Les guides Core Web Vitals orientent les problèmes de chargement ou de stabilité restants. Conservez le scénario comme test de régression afin que de futurs scripts ou changements de disposition ne réintroduisent pas discrètement le retard.