INP ou Interaction to Next Paint : qu’est-ce que c’est, ce qu’il mesure et comment optimiser les sites

Interaction to Next Paint ou INP, le nouveau Core Web Vitals de Google

Deux ans exactement se sont écoulés depuis que Google a introduit pour la première fois le concept de Core Web Vitals et, plus généralement, de métriques permettant d'évaluer concrètement l'expérience vécue par les utilisateurs sur les pages d'un site : à l'époque, c'est Ilya Grigorik, ingénieur en performances Web, qui a présenté le projet et dévoilé le premier ensemble de métriques choisies pour mesurer les performances des pages, en prévoyant que la liste serait soumise à une révision périodique. Avance rapide jusqu'à aujourd'hui, car nous sommes en effet sur le point de faire la connaissance d'un nouveau signal web essentiel, à savoir l'Interaction to Next Paint ou INP, qui mesure la réactivité des pages, c'est-à-dire la capacité à répondre aux entrées de l'utilisateur.

La nouvelle mesure de la réactivité : INP

L'INP a été présenté il y a quelques semaines dans un article de Jeremy Wagner sur blog.dev, mais l'attention s'est accrue après l'annonce officielle de la métrique lors de la Google I/O 2022, la conférence d'Annie Sullivan et Michal Mocny étant précisément axée sur le thème de la réactivité et les mesures prises par Google en vue d'une amélioration générale de l'écosystème web sur ce front.

Bien que le délai de première entrée soit "une excellente mesure pour évaluer la réactivité pendant le chargement des pages", affirment les Googlers, le Web devient plus performant et les utilisateurs attendent des interfaces plus riches et plus interactives : regarder uniquement la réactivité pendant le chargement des pages ne dit pas tout, et une approche plus holistique de la mesure de la réactivité est nécessaire, et l'INP va dans ce sens.

Ce que signifie Interaction to Next Paint

Interaction to Next Paint ou INP est la mesure expérimentale qui évalue la réactivité en enregistrant la latence de toutes les interactions tout au long du cycle de vie de la page ; l'INP de la page est enregistré comme la valeur la plus élevée de ces interactions ou la valeur la plus proche de la plus élevée pour les pages comportant de nombreuses interactions, et une valeur INP faible garantit que la page est toujours réactive de manière fiable.

Il s'agit donc d'une mesure du cycle de vie complet de la page, tout comme le Cumulative Layout Shift, qui mesure donc toutes les interactions, et pas seulement la première, en changeant et en se mettant à jour en permanence tout au long du cycle de vie de la page ; de plus, comme dans le cas de CLS, une valeur INP n'est pas enregistrée avant que l'utilisateur ne quitte la page.

L'INP est également appelée réactivité d'exécution pour la différencier de la simple réactivité de chargement. En termes pratiques, elle mesure l'ensemble de la latence d'entrée entre le moment où l'utilisateur interagit et celui où il voit effectivement une réponse visuelle, et pas seulement le délai initial sur le fil d'exécution principal.

Qu'est-ce que la réactivité et pourquoi est-elle importante pour un site ?

Wagner se penche également sur la signification de la réactivité, une valeur qui évalue la rapidité avec laquelle une page répond aux entrées de l'utilisateur et qui est essentielle à l'interaction positive des gens avec les pages.

Des données récentes sur l'utilisation de Chrome montrent qu'environ 90 % du temps passé par un utilisateur sur une page l'est précisément après le chargement de la page. Il est donc important de mesurer soigneusement la réactivité, d'autant plus que de plus en plus de sites Web s'appuient sur le JavaScript pour fournir de l'interactivité.

Lorsque la réactivité est bonne, les pages répondent rapidement aux interactions de l'utilisateur : lorsqu'une application répond aux interactions, les changements qui en résultent dans l'interface utilisateur sont des retours visuels qui "nous indiquent, par exemple, si un article dont nous avons demandé l'ajout au panier d'un site est effectivement ajouté, si le contenu d'un formulaire de connexion est authentifié par le serveur, si un menu mobile s'est ouvert, etc.

La vidéo clarifie ces aspects, en montrant une représentation visuelle d'une mauvaise (à gauche) et d'une bonne (à droite) réactivité d'une image pleine grandeur chargée à partir d'une galerie de vignettes : l'exemple de droite fournit un retour visuel (l'indicateur de chargement) qui apparaît immédiatement après la demande de l'image et disparaît au moment opportun, ce qui représente une manière valide de communiquer le résultat d'une interaction. Dans le cas de gauche, en revanche, la réactivité est faible car l'image doit être téléchargée avant d'être affichée, ce qui entraîne un retard considérable.

La définition de l’INP et la valeur de la métrique

L'article de Wagner explique comment fonctionne l'INP, comment le mesurer et propose des suggestions pour l'améliorer, en partant du principe qu'une bonne réactivité est essentielle à une bonne expérience utilisateur.

Conformément à cette définition, l'Interaction to Next Paint est une mesure qui vise à représenter la latence globale des interactions d'une page en sélectionnant l'une des interactions individuelles les plus longues qui se produisent lorsqu'un utilisateur visite une page.

Pour les pages comportant moins de 50 interactions au total, INP est l'interaction présentant la pire latence ; pour les pages comportant de nombreuses interactions, INP correspond souvent au 98e percentile de la latence des interactions.

Comment l'INP est mesuré

Une interaction est un ensemble d'événements d'entrée connexes qui sont déclenchés au cours du même geste logique de l'utilisateur : par exemple, les interactions de type "tapotement" sur un dispositif à écran tactile comprennent plusieurs événements, tels que l'élévation du pointeur, l'abaissement du pointeur et le clic, qui peuvent contribuer à la latence globale de l'interaction.

La latence d'une interaction unique est constituée de la durée la plus longue de chaque événement faisant partie de l'interaction, la durée étant mesurée à partir du moment où l'utilisateur a interagi avec la page jusqu'à la présentation de la trame suivante après l'exécution de tous les gestionnaires d'événements associés.

La durée est la somme des temps suivants :

• Le délai d'entrée, qui est le temps entre le moment où l'utilisateur interagit avec la page et l'exécution des gestionnaires d'événements.
• Le temps de traitement, qui est le temps total nécessaire pour exécuter le code dans les gestionnaires d'événements associés.
• Le délai de présentation, qui est le temps entre la fin de l'exécution des gestionnaires d'événements et la présentation de la trame suivante par le navigateur.

Calcul de l'INP : quelles sont les valeurs optimales ?

Selon Wagner, il est difficile d'attribuer des étiquettes telles que "bon" ou "mauvais" à une mesure de réactivité : d'une part, Google souhaite encourager le développement d'expériences utilisateur offrant une bonne réactivité, mais d'autre part, il est nécessaire de tenir compte du fait que les capacités des appareils utilisés varient considérablement et, par conséquent, de fixer des attentes réellement réalisables en sélectionnant un objectif qui n'est pas impossible à atteindre sur les appareils bas de gamme.

En gardant cela à l'esprit, il est important que la mesure de la réactivité soit appropriée pour une variété de cas d'utilisation, et pour être sûr d'y parvenir, un bon seuil à mesurer est le 75e percentile des chargements de pages enregistrés sur le terrain, segmenté entre les appareils mobiles et de bureau :

• Une valeur INP de 200 millisecondes ou moins signifie que la page a une bonne réactivité.
• Un INP supérieur à 200 millisecondes et inférieur ou égal à 500 millisecondes signifie que la réactivité de la page doit être améliorée.
• Un INP supérieur à 500 millisecondes signifie que la réactivité de la page est faible.

Toutefois, l'INP étant une mesure expérimentale, les indications de seuil peuvent changer au fil du temps, à mesure que la mesure est affinée, prévient l'article.

Qu’y a-t-il dans une interaction ?

Il devient utile à ce stade de comprendre également ce que l'on entend par interaction, et Wagner s'attarde particulièrement sur cet aspect.

Lors de l'interaction avec une page, le moteur de l'interactivité est souvent JavaScript, bien que les navigateurs fournissent également une interactivité par le biais de contrôles non gérés par JavaScript, tels que les cases à cocher, les boutons radio, l'élément HTML , etc.

En ce qui concerne l'interaction avec la peinture suivante, une interaction consiste en l'une des actions suivantes :

• Cliquez avec la souris sur un élément interactif.
• Toucher un élément interactif sur un dispositif équipé d'un écran tactile.
• Appuyer sur une touche d'un clavier physique ou à l'écran.

Une interaction peut être composée de plusieurs événements - par exemple, une frappe au clavier est composée des événements keydown et keyup (majuscules/minuscules ou autres caractères atteints par la même touche) et les interactions tactiles contiennent les événements pointerup et pointerdown (lever et baisser le pointeur) - et tous les événements d'une interaction font partie de ce qu'on appelle une interaction logique avec l'utilisateur.

Chaque interaction se compose de trois phases : le délai d'entrée, le temps de traitement et le délai de présentation. L'image ci-dessus montre les phases d'une seule interaction. Le délai d'entrée se produit à partir du moment où une entrée est reçue et peut être causé par des facteurs tels que le blocage d'activités sur le thread principal. Le temps de traitement est le temps nécessaire à l'exécution des gestionnaires d'événements de l'interaction. À la fin de l'exécution, il y a le délai de présentation, qui est le temps nécessaire pour rendre et peindre l'image suivante.

La durée des rappels d'événements associés à une interaction est la somme des temps des trois phases ; l'événement dont la durée est la plus longue dans l'interaction logique de l'utilisateur est enregistré.

Comme pour le CLS, l'INP est calculé lorsque l'utilisateur quitte la page, ce qui donne une valeur unique représentative de la réactivité globale de la page sur l'ensemble de son cycle de vie. Si la page répond rapidement aux interactions du percentile élevé, cela signifie que les interactions de tous les percentiles inférieurs sont également rapides.

Que se passe-t-il s'il n'y a pas d'interactions

Dans certains cas, la page se charge, mais aucune interaction avec l'utilisateur n'a lieu. Cela peut se produire pour plusieurs raisons :

• Il est possible qu'un utilisateur ait chargé la page, mais se soit laissé distraire et ne l'ait jamais utilisée.
• L'utilisateur a chargé la page, l'a fait défiler (ce n'est pas une interaction prise en compte par l'INP), mais n'a jamais cliqué, tapé ou appuyé sur une touche du clavier. Peut-être que la partie utile de la page que l'utilisateur recherchait ne nécessitait aucune interaction pour l'atteindre.
• La page a été visitée par un robot (par exemple, un robot de recherche ou un navigateur sans tête) qui n'était pas programmé pour interagir avec la page.

Dans tous ces cas, aucune valeur INP ne sera rapportée.

Pourquoi INP n'évalue pas la pire latence d'interaction

On peut se demander, à ce stade, pourquoi Google a choisi de mesurer l'interaction avec le tableau suivant en prenant "l'une des plus longues interactions individuelles" et non la pire latence d'interaction.

Wagner répond que la pire interaction pourrait être appropriée "pour des pages avec un nombre relativement faible d'interactions", mais toutes les pages web ne sont pas égales et "certaines nécessitent plus d'interactivité que d'autres, par exemple un éditeur de texte ou une application de jeu vidéo qu'un blog ou un site d'information". Pour les pages présentant un nombre très élevé d'interactions, en particulier, l'échantillonnage du pire pourrait être trompeur, et même sur les sites Web qui privilégient la réactivité, des problèmes occasionnels se produisent, et ces interactions doivent être négligées.

Inversement, en se concentrant sur un percentile élevé, mais pas toujours le plus élevé, il est possible d'évaluer correctement si la majorité des interactions sur une page reçoivent une réponse en temps voulu.

La relation entre INP et FID : INP est plus fiable

L'introduction de l'INP a immédiatement intéressé la communauté internationale des référenceurs, d'autant plus que cette nouvelle métrique semble entrer en collision avec le First Input Delay et en est presque une évolution. Cela a également été confirmé par la présentation de Mocny lors de la Google I/O 2022, dans laquelle le développeur des mesures de vitesse de Chrome et des Core Web Vitals ( !) a admis que "FID a quelques angles morts assez importants", ajoutant que "c'est pourquoi nous introduisons une nouvelle mesure expérimentale de réactivité, Interaction to Next Paint", laissant ouverte la possibilité que INP remplace (ou du moins flanque) FID au sein des signaux web de base et des signaux d'expérience de page.

Pour en venir aux aspects pratiques, la différence entre INP et FID est évidente : First Input Delay ne prend en compte que la première interaction et ne mesure que le délai de saisie, et non le temps de traitement des gestionnaires d'événements ou le délai de présentation de la trame suivante, alors qu'au contraire Interaction to Next Paint prend en compte toutes les interactions sur la page.

Étant donné qu'il s'agit d'une mesure de la réactivité au chargement, le FID applique une logique de base selon laquelle "si la première interaction avec une page au cours de la phase de chargement ne présente que peu ou pas de délai d'entrée, la page a fait une bonne première impression".

L'INP va toutefois au-delà de cette "première impression", car elle couvre l'ensemble des interactions qui peuvent se produire entre le moment où la page commence à se charger et celui où l'utilisateur la quitte. En échantillonnant toutes les interactions, il est en mesure d'évaluer la réactivité de manière exhaustive, ce qui "fait de l'INP un indicateur de réactivité plus fiable que le FID", résume M. Wagner.

Les différences entre INP et FID et les avantages de l'INP

Leena Sohoni, Addy Osmani et Keen Yee Liau vont plus loin dans les détails. Toujours dans les pages de web.dev, ils écrivent un article de fond intéressant sur la relation entre la métrique INP et l'expérience des sites construits avec des frameworks et des bibliothèques JavaScript.

En discutant des différences entre le FID et l'INP, les trois techniciens soulignent que le First Input Delay "mesure le temps d'attente entre la première interaction de l'utilisateur et le moment où le navigateur est en mesure de traiter les gestionnaires d'événements de l'interaction", mais n'inclut pas le temps nécessaire pour traiter les gestionnaires d'événements, pour traiter les interactions ultérieures sur la même page ou pour afficher la trame suivante après l'exécution des rappels d'événements.

Toutefois, ils notent que la réactivité est essentielle à l'expérience de l'utilisateur pendant tout le cycle de vie de la page, car les utilisateurs passent environ 90 % de leur temps sur une page après son chargement. De plus, comme le FID ne mesure que le délai d'entrée de la première interaction, il est probable que les développeurs web n'ont pas optimisé de manière proactive les interactions ultérieures dans le cadre de leur processus d'amélioration.

C'est là qu'intervient l'INP, qui mesure le temps qu'il faut à une page web pour répondre aux interactions de l'utilisateur, depuis le moment où celui-ci commence l'interaction jusqu'à l'apparition de la trame suivante à l'écran. Avec cette nouvelle mesure, Google espère "obtenir une mesure agrégée de la latence perçue de toutes les interactions dans le cycle de vie de la page", une "estimation plus précise de la réactivité de chargement et d'exécution des pages web".

FID vs. INP : caractéristiques, calcul et optimisations

L'article présente également un précieux tableau récapitulatif et comparatif entre les caractéristiques du First Input Delay et de l'Interaction to Next Paint.

En général, l'INP a tendance à avoir des taux de dépassement plus faibles et la différence dans le processus de mesure nécessite une optimisation supplémentaire du code. Plus précisément, les points sur lesquels il faut se concentrer sont les suivants :

1. Mesure

• FID mesure la durée entre la première entrée de l'utilisateur et le moment où le gestionnaire d'événement correspondant est exécuté.
• L'INP mesure la latence globale de l'interaction en utilisant le retard
• de l'interaction la plus importante pour moins de 50 transactions.
• de la plus grande interaction pour plus de 50 transactions.

2. Ce dont cela dépend

• Le FID dépend de la disponibilité du thread principal à exécuter le gestionnaire d'événements requis pour la première interaction. Le thread principal peut être bloqué parce qu'il traite d'autres ressources dans le cadre du chargement initial de la page.
• INP dépend de la disponibilité du thread principal et de la taille du script exécuté par les gestionnaires d'événements pour plusieurs interactions, y compris la première.

3. Principale cause des mauvais résultats

• Un mauvais FID dépend principalement de l'exécution lourde de JavaScript sur le thread principal.
• Un traitement lourd des événements JavaScript et d'autres activités de rendu après l'exécution des gestionnaires peuvent entraîner un mauvais DIF.

4. Optimisation

• Le FID peut être optimisé en améliorant le chargement des ressources lors du chargement de la page et en optimisant le code JavaScript.
• Le processus d'optimisation est similaire à celui du FID pour chaque interaction, mais nécessite également l'utilisation de modèles de rendu qui donnent la priorité aux mises à jour clés de l'UX par rapport aux autres tâches de rendu.

Comment mesurer l’INP : outils et techniques pour calculer la réactivité

C'est plutôt l'article de Wagner qui entre dans les détails techniques de la façon de mesurer l'interaction avec Next Paint sur les pages d'un site, offrant également des conseils pratiques utiles pour corriger les situations où les valeurs ne sont pas optimales.

Tout d'abord, l'INP peut être mesuré sur le terrain ou en laboratoire (avec un certain effort) à l'aide d'une variété d'instruments.

Parmi les outils de terrain, on trouve :

• PageSpeed Insights.
• Rapport sur l'expérience utilisateur de Chrome (CrUX).
• via BigQuery dans la table experimental_interaction_to_next_paint de l'ensemble de données CrUX.
• API CrUX via experimental_interaction_to_next_paint.
• Tableau de bord du CrUX.
• La bibliothèque JavaScript Web-vitals.

M. Wagner prévient toutefois qu'à l'heure actuelle, la collecte des mesures INP sur le terrain ne fonctionne que sur les navigateurs qui prennent pleinement en charge l'API Event Timing, y compris la propriété interactionId.

Parmi les outils de laboratoire à la place, nous pouvons utiliser :

• Panneau Lighthouse dans DevTools, disponible en "Timespan Mode".
• Module npm du phare.
• Flux d'utilisateurs de Lighthouse.
• Extension Web Vitals pour Chrome.

Il existe une autre possibilité, à savoir mesurer l'interaction avec Newt Paint en JavaScript, soit en écrivant votre propre PerformanceObserver (mais cela peut être difficile, prévient Google), soit en utilisant la bibliothèque JavaScript web-vitals, qui exporte une fonction onINP pour faire ce travail.

Comment améliorer la valeur de l'INP

Si notre site Web signale des valeurs INP qui se situent en dehors du seuil "bon", nous pouvons bien sûr intervenir pour tenter d'améliorer les performances et donc la réactivité.

En général, des valeurs INP élevées indiquent une forte dépendance vis-à-vis de JavaScript ou d'autres threads principaux non-JavaScript qui peuvent s'exécuter en même temps que les interactions avec l'utilisateur.

Les corrections commencent par l'identification du moment critique pour la réactivité, c'est-à-dire au démarrage de la page ou plus tard.

Comment améliorer l'INP pendant le démarrage de la page

L'INP peut être un facteur pendant le chargement de la page car les utilisateurs peuvent tenter d'interagir avec une page pendant qu'elle récupère le JavaScript pour mettre en place les gestionnaires d'événements qui fournissent l'interactivité nécessaire au fonctionnement.

Selon HTTP Archive, le temps de blocage total (TBT) est deux fois plus corrélé avec l'INP qu'avec le FID. Le TBT est une mesure de laboratoire, mais si des valeurs élevées de TBT sont observées dans les instruments de laboratoire, "cela pourrait être le signe de valeurs plus élevées d'INP" sur le terrain également.

Pour améliorer la réactivité lors du chargement des pages, nous pouvons examiner les solutions suivantes :

• Supprimez le code inutilisé à l'aide de l'outil de couverture dans DevTools de Chrome.
• Trouvez des occasions de diviser le code, de sorte que le JavaScript inutile puisse être chargé "paresseusement" pendant le chargement de la page (utilisez à nouveau l'outil de couverture pour obtenir des informations).
• Identifiez les JavaScript tiers lents qui peuvent se charger pendant le démarrage.
• Utilisez le profileur de performance pour trouver les tâches longues qui peuvent être optimisées.
• Vérifiez que vous n'avez pas besoin d'un rendu excessif du navigateur après la fin du code JavaScript : par exemple, le rendu d'une grande arborescence de composants, le décodage de grandes images, trop d'effets css lourds, etc.

Amélioration de l'INP après le démarrage de la page

Mais l'interaction d'une page avec le tableau suivant peut également être affectée par ce qui se passe après le démarrage de la page, car les mesures sont calculées, comme nous l'avons mentionné, sur la base des données échantillonnées pendant tout le cycle de vie de la page.

Lorsque cela se produit, nous pouvons examiner certains domaines pour trouver des solutions :

• Utilisez l'API postTask pour établir les priorités de manière appropriée.
• Planifiez les travaux non essentiels lorsque le navigateur est inactif avec requestIdleCallback.
• Utilisez le profileur de performance pour évaluer les interactions discrètes (par exemple, l'activation d'un menu de navigation mobile) et trouver les tâches qui prennent beaucoup de temps à optimiser.
• Vérifiez l'exécution de JavaScript tiers sur le site Web pour voir s'il affecte la réactivité de la page.

INP et JavaScript : points critiques et optimisations possibles

Il est déjà clair, d'après ce qui a été écrit, que JavaScript a une incidence évidente sur la réactivité d'une page, et on peut en effet supposer (sans trop craindre d'être contredit) que tout script qui bloque le thread principal pendant une longue durée est mauvais pour l'INP, compte tenu également de la corrélation susmentionnée entre les valeurs de l'INP sur le terrain et le temps de blocage total (TBT) observé en laboratoire.

Par conséquent, une exécution intensive de JavaScript après une interaction peut bloquer le fil d'exécution principal pendant une période prolongée et retarder la réponse à l'interaction. L'article des développeurs révèle certaines des causes courantes qui conduisent au blocage des scripts, avec quelques actions correctives rapides que nous pouvons appliquer.

• JavaScript non optimisé. Le code redondant ou les mauvaises stratégies de fractionnement et de chargement du code peuvent faire gonfler le code JavaScript et bloquer le fil principal pendant de longues périodes. Le fractionnement du code, le chargement progressif et le fractionnement des tâches longues peuvent améliorer considérablement les temps de réponse.
• Scripts tiers. Les scripts tiers, qui ne sont parfois pas nécessaires pour traiter une interaction (par exemple, les scripts publicitaires), peuvent bloquer le fil d'exécution principal et provoquer des retards inutiles. Donner la priorité aux scripts essentiels peut contribuer à réduire l'impact négatif des scripts tiers.
• Gestionnaires d'événements multiples. Les multiples gestionnaires d'événements associés à chaque interaction, chacun exécutant un script différent, peuvent interférer les uns avec les autres et provoquer de longs délais. Certaines de ces activités peuvent être non essentielles et peuvent être programmées sur un travailleur web ou lorsque le navigateur est inactif.
• Framework pour la gestion des événements. Les cadres peuvent avoir des fonctionnalités/syntaxes supplémentaires pour le traitement des événements. Par exemple, Vue utilise v-on pour lier les écouteurs d'événements aux éléments, tandis qu'Angular s'occupe des gestionnaires d'événements utilisateur. La mise en œuvre de ces fonctionnalités nécessite du code supplémentaire pour le framework par rapport au JavaScript standard.
• Hydratation. Lorsqu'on utilise un cadre JavaScript, il n'est pas rare qu'un serveur génère le HTML initial d'une page, qui doit ensuite être complétée par des gestionnaires d'événements et l'état de l'application, afin qu'elle puisse être interactive dans un navigateur web. Ce processus s'appelle l'hydratation. Le processus peut être lourd pendant le chargement, en fonction du temps qu'il faut à JavaScript pour charger et terminer l'hydratation. Il peut également faire apparaître des pages interactives qui ne le sont pas. Souvent, l'hydratation se produit automatiquement pendant le chargement de la page ou dans le cadre d'un chargement retardé (par exemple, sur la base d'une interaction avec l'utilisateur) et peut avoir un impact sur l'INP ou le temps de traitement en raison de la planification des tâches. Dans des bibliothèques telles que React, il est possible d'exploiter useTransition pour qu'une partie du rendu d'un composant ait lieu dans la trame suivante et que les effets secondaires plus "gourmands en ressources" soient laissés aux trames suivantes. C'est pourquoi les mises à jour d'une transition qui se rapportent à des mises à jour plus urgentes, comme les clics, peuvent constituer un modèle utile pour l'INP.
• La préextraction agressive des ressources nécessaires à la navigation ultérieure peut constituer un avantage en termes de performances, si elle est bien réalisée. Toutefois, si vous effectuez la préextraction et le rendu des chemins SPA de manière synchrone, vous risquez d'avoir un impact négatif sur l'INP, car tout ce rendu coûteux tente d'être achevé en une seule image. C'est le cas si vous ne préfixez pas le chemin et ne commencez pas le travail nécessaire (par exemple fetch() ) et ne déverrouillez pas la visualisation. Il convient donc de réexaminer si l'approche du cadre de travail en matière de préextraction offre une interface utilisateur optimale et comment (le cas échéant) cela peut affecter l'INP.

En fin de compte, pour obtenir un bon score INP, les développeurs devront donc se concentrer sur l'examen du code qui est exécuté après chaque interaction sur la page et optimiser le chunking, la réhydratation, les stratégies de chargement et la taille de chaque mise à jour render() pour les scripts de première et de troisième partie.

Nous souhaitons la bienvenue à Interaction à Next Paint

Selon les Googlers, le score INP deviendra une "meilleure boussole pour les sites web" afin d'améliorer la réactivité et les performances dans un avenir proche.

Pour l'instant, la communauté internationale a réagi avec curiosité, mais sans frénésie apparente, notamment à la lumière de l'expérience acquise avec Page Experience et Core Web Vitals, qui se sont finalement révélés être un facteur de classement de faible impact (du moins jusqu'à présent), malgré les nobles prémisses.

Il ne reste donc plus qu'à attendre les prochains développements et à comprendre comment optimiser nos pages pour intercepter cette nouvelle métrique, dans le but de rendre nos sites de plus en plus performants et (dans ce cas) réellement réactifs.

Contactez en ligne les spécialistes de Metadosi, ou par téléphone au 09 73 88 45 37, pour voir comment nous pouvons vous aider à optimiser votre score INP.