Améliorer l'Interaction to Next Paint (INP)

Qu'est-ce que l'Interaction to Next Paint (INP) ?

L'Interaction to Next Paint (INP) est une métrique relativement nouvelle et passionnante qui mesure la réactivité d'une page web à travers toutes les interactions sur une page. Un Interaction to Next Paint faible garantit que la page sera fiable et réactive à tout moment. L'INP deviendra un Core Web Vital en mars 2024 lorsque Google remplacera la métrique FID par la métrique INP.

Pour calculer la métrique Interaction to Next Paint, toutes les différences entre chaque interaction utilisateur et le changement de présentation final sur la page sont enregistrées. Le nombre le plus élevé de toutes les interactions (ou le 98e percentile) sera la métrique finale Interaction to Next Paint (INP).

98e percentile ou le pire INP ?

L'INP est une métrique qui vise à représenter la latence d'interaction globale d'une page en sélectionnant l'une des interactions les plus longues qui se produisent lorsqu'un utilisateur visite une page. Pour les pages avec moins de 50 interactions au total, l'INP est l'interaction avec la pire latence. Pour les pages avec de nombreuses interactions, l'INP est le plus souvent le 98e percentile de la latence d'interaction.

Comment fonctionne exactement l'Interaction to Next Paint (INP) ?

Une interaction se produit lorsqu'un visiteur clique ou tape sur une page. Cette interaction peut entraîner un changement de présentation à l'écran. L'Interaction to Next Paint (INP) mesure le temps entre le clic et la présentation.

La latence d'une seule interaction correspond à la durée la plus longue de tout événement faisant partie de l'interaction, où la durée est mesurée à partir du moment où l'utilisateur a interagi avec la page jusqu'à ce que la frame suivante soit présentée après l'exécution de tous les gestionnaires d'événements associés. La durée est la somme des plages de temps suivantes :

Quelles sont les bonnes et mauvaises valeurs de l'Interaction to Next Paint (INP) ?

Comment mesurer l'Interaction to Next Paint (INP) ?

L'Interaction to Next Paint ne peut être mesuré qu'avec des outils de terrain. Afin de mesurer l'Interaction to Next Paint, nous avons besoin d'une véritable interaction utilisateur. Google mesure toute l'interaction que les véritables utilisateurs de Chrome ont avec une page et la stocke dans le dataset CrUX. Le dataset CrUX est le dataset officiel pour les Core Web Vitals.

Obtenir les métriques INP officielles

Vous pouvez obtenir les métriques INP officielles dans PageSpeed Insights ou le tableau de bord CrUX et Google BigQuery. PageSpeed Insights vous donnera le score du 75e percentile pour les 28 derniers jours. Google BigQuery (via datastudio) vous donnera plus de contexte historique.

Suivi de l'Interaction to Next Paint avec le Real User Monitoring

Bien que le dataset officiel CrUX soit la source finale pour les métriques Interaction to Next Paint, le dataset CrUX n'est pas vraiment utilisable car il est hautement anonymisé. Le dataset CrUX ne fournit pas de surveillance en temps réel et ne permet pas beaucoup de filtrage. C'est pourquoi les consultants en performance web s'appuient généralement sur le Real User Monitoring.

Mesurer l'Interaction to next paint de la session actuelle.

Le moyen le plus simple de déboguer l'Interaction to Next Paint est via Lighthouse en mode 'timespan'.  Vous pouvez également utiliser le Core Web Vitals Visualizer ou si vous vous sentez à l'aise avec la Web Vitals JavaScript Library de Google

Loguez l'INP dans la console avec la bibliothèque Web Vitals JavaScript

<script type="module">
 import {onINP} 
 from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Comment améliorer l'Interaction to Next Paint ?

L'Interaction to Next Paint est une métrique compliquée. Votre page peut être très rapide et répondre instantanément pour la majeure partie. Malheureusement, si une seule interaction est lente, cela affectera l'ensemble de l'Interaction to Next Paint.

Maintenant, rappelez-vous, l'INP peut être décomposé en input delay, processing time et le presentation delay.

ASTUCE PageSpeed : la plupart du temps, l'INP sera bien pire lorsqu'un utilisateur interagit avec la page pendant la phase de démarrage du chargement de la page.  C'est pourquoi, lors du débogage de l'INP, il est logique de loguer toutes les interactions ainsi que l'état de chargement de la page !

1. Minimiser l'input delay - empêcher les longues tâches sur le main thread

Habituellement, toute page est moins réactive pendant la phase de démarrage de la page. C'est à ce moment que la plupart du travail du main thread est effectué (analyse, décodage, rendu et script).  Afin de garder le main thread aussi libre que possible, envisagez :

• Supprimez le code inutilisé. Cela peut être fait par un processus appelé tree shaking (suppression du code inutilisé) et code splitting (regroupement de votre code de manière à ce qu'il soit groupé en plusieurs petits bundles qui peuvent être chargés selon les besoins). 
• Chargez le code non essentiel pendant l'inactivité du navigateur. Par exemple, avez-vous vraiment besoin d'un widget de chat pendant les 500 premières ms du chargement de la page ? Non, probablement pas !
• Identifiez les scripts lents qui nécessitent beaucoup de ressources et réécrivez le code pour le rendre plus efficace.
• Assurez-vous que votre page est 'facile à rendre'. Évitez les grandes tailles de DOM, trop d'images ou des images énormes, trop d'animations CSS de vidéos, etc.
  

2. Minimiser le processing time - fournir un feedback immédiat pour s'assurer que la page répond directement à l'entrée de l'utilisateur

Lorsqu'un visiteur effectue une action comme l'envoi d'un formulaire ou l'ajout d'un article à un panier, n'attendez pas la confirmation côté serveur (votre formulaire a été envoyé, vos articles ont été ajoutés au panier) mais fournissez un feedback immédiat (nous envoyons votre formulaire, ajout de l'article X au panier). 

De plus, yield (cédez) au main thread dès que possible. Parce que JavaScript fait cette chose appelée 'run to completion', il bloquera le main thread jusqu'à ce que tout le code ait été exécuté. Vous pouvez créer manuellement un point d'arrêt où le navigateur peut mettre à jour la mise en page (et ensuite continuer le reste du code) en 'yielding au main thread.' Le moyen le plus simple de le faire est d'envelopper des parties du code dans un setTimeout()

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Envoi du formulaire ... veuillez patienter";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(),0);
});

3. Minimiser le presentation delay - gardez les choses simples !