Interaction avec la peinture suivante (INP)

L'indicateur « Interaction to Next Paint » mesure la rapidité avec laquelle une page réagit visuellement à l'interaction de l'utilisateur, en fournissant une valeur représentative des latences d'interaction les plus importantes rencontrées lors d'une visite. Il a remplacé le « First Input Delay » (délai de première interaction) en tant qu'indicateur de réactivité Core Web Vitals en mars 2024, et ce changement a été significatif : alors que l'ancien indicateur ne prenait en compte que le délai avant le début du traitement lors de la première interaction, celui-ci mesure la durée totale, de l'interaction initiale au traitement complet jusqu'à l'affichage de l'image suivante, pour toutes les interactions de la session.

Cette différence est importante car l'ancien indicateur était trompeur pour de nombreux sites. Une page pouvait afficher un excellent délai de première interaction tout en restant lente par la suite, car la mesure ignorait le temps d'exécution du gestionnaire d'événements et le temps nécessaire au navigateur pour afficher le résultat, et parce qu'elle ne prenait en compte qu'une seule interaction. Les sites qui paraissaient réactifs avec l'ancien indicateur ne le sont souvent plus avec le nouveau, en particulier les applications monopages et les interfaces comportant une logique côté client complexe.

La valeur affichée est calculée à partir des interactions les plus longues observées, en tenant compte des valeurs aberrantes sur les pages comportant de nombreuses interactions. Le seuil publié par Google considère une durée inférieure ou égale à 200 millisecondes comme optimale, correspondant au 75e percentile des expériences utilisateur réelles. Comme elle prend en compte l'intégralité du processus, de la saisie à l'affichage, les scores faibles peuvent avoir plusieurs origines : tâches longues sur le thread principal empêchant le navigateur de traiter l'événement, gestionnaires d'événements effectuant un travail synchrone excessif, perturbations de la mise en page dues à l'entrelacement des styles de lecture et d'écriture, et rendus coûteux après les modifications d'état.

Le diagnostic pointe généralement vers l'exécution de JavaScript plutôt que vers les conditions réseau, ce qui distingue cette métrique des mesures de charge. Parmi les causes fréquentes, on trouve les gros modules monolithiques exécutés sur le thread principal, les scripts tiers effectuant des tâches arbitraires pendant l'interaction, les rendus du framework qui modifient une partie de l'arbre bien plus importante que nécessaire, et les gestionnaires effectuant des calculs synchrones qui pourraient être différés ou déplacés hors du thread principal. Les tâches longues constituent le mécanisme sous-jacent dans la plupart des cas, car le navigateur ne peut pas répondre aux entrées pendant l'exécution d'une tâche.

La correction fait suite au diagnostic. Découper les tâches longues en segments plus petits, avec une gestion explicite des interactions, permet au navigateur de gérer les entrées entre ces segments. Reporter les tâches non essentielles après la mise à jour visuelle, afin que l'utilisateur obtienne une réponse immédiate, permet de résoudre le problème le plus fréquent. Réduire la quantité de JavaScript embarqué, auditer l'impact des scripts tiers sur le thread principal, virtualiser les longues listes et déplacer les calculs lourds vers un nœud de calcul dédié ciblent chacune des causes spécifiques. Fournir un retour visuel immédiat pour les opérations lentes n'améliore pas la valeur mesurée, mais modifie la perception du délai.

Les scripts tiers méritent une attention particulière car ils sont une cause fréquente de problèmes et échappent au contrôle direct de l'équipe. Les widgets de chat, les gestionnaires de consentement, les bibliothèques d'analyse, les outils de personnalisation et les scripts publicitaires s'exécutent tous sur le thread principal et peuvent l'occuper précisément au moment où un visiteur tente d'interagir. Auditer le coût de chaque script tiers sur le thread principal, idéalement en mesurant la page avec et sans ce script, permet d'établir une liste précise du coût de chaque fournisseur en termes de réactivité. Ce chiffre permet de discuter du compromis avec les équipes ayant demandé chaque outil, une approche généralement plus productive que d'essayer d'optimiser le code de l'application autour d'un script qui absorbe la majeure partie du budget disponible.

Étant donné que cette métrique est pilotée par le code applicatif plutôt que par la mise à disposition des ressources, son amélioration nécessite généralement un travail d'ingénierie plutôt qu'une configuration. En pratique, elle se situe à la frontière entre performances web et le développement de produitset cela a des conséquences particulièrement importantes pour les interfaces de commerce interactif et de réservation, où le filtrage, la configuration et les interactions avec le panier qui ne répondent pas entraînent des abandons qui apparaissent dans les analyses comme des abandons ordinaires sans cause évidente.