La documentation officielle sur la façon dont les Core Web Vitals sont notés a été récemment mise à jour avec de nouvelles informations sur la façon dont les seuils de notation de l’Interaction to Next Paint (INP) ont été choisis et offre une meilleure compréhension de l’Interaction To Next Paint.
Interaction avec la peinture suivante (INP)
L’interaction avec Next Paint (INP) est une mesure relativement nouvelle, devenant officiellement un Core Web Vitals au printemps 2024. Il s’agit d’une mesure du temps qu’il faut à un site pour répondre à des interactions telles que des clics, des tapotements et lorsque les utilisateurs appuient sur un site Web. clavier (réel ou à l’écran).
Le Web.dev officiel documentation le définit :
«INP observe la latence de toutes les interactions qu’un utilisateur a effectuées avec la page et rapporte une valeur unique en dessous de laquelle toutes (ou presque toutes) les interactions se trouvaient. Un INP faible signifie que la page a toujours été capable de répondre rapidement à toutes, ou à la grande majorité, des interactions des utilisateurs.
INP mesure la latence de toutes les interactions sur la page, ce qui est différent de la métrique First Input Delay, désormais retirée, qui mesurait uniquement le retard de la première interaction. L’INP est considéré comme une meilleure mesure que l’INP car il donne une idée plus précise de l’expérience utilisateur réelle.
Seuils de score INP Core Web Vitals
Le principal changement apporté à la documentation est de fournir une explication des seuils de performance de vitesse qui indiquent mauvais, doivent être améliorés et bons.
L’un des choix effectués pour décider de la notation était la manière de gérer la notation, car il est plus facile d’obtenir des scores INP élevés sur un ordinateur de bureau que sur un appareil mobile, car des facteurs externes tels que la vitesse du réseau et les capacités des appareils favorisent fortement les environnements de bureau.
Mais l’expérience utilisateur ne dépend pas de l’appareil, c’est pourquoi ils créent différents seuils pour différents types d’appareils et se contentent d’une métrique basée sur les appareils mobiles.
La nouvelle documentation explique :
« L’utilisation des appareils mobiles et des ordinateurs de bureau présente généralement des caractéristiques très différentes en termes de capacités des appareils et de fiabilité du réseau. Cela a un impact considérable sur les critères de « réalisabilité » et suggère donc que nous devrions envisager des seuils distincts pour chacun.
Cependant, les attentes des utilisateurs concernant une expérience bonne ou mauvaise ne dépendent pas de l’appareil, même si les critères de réalisabilité le sont. Pour cette raison, les seuils recommandés par Core Web Vitals ne sont pas séparés par appareil et le même seuil est utilisé pour les deux. Cela présente également l’avantage supplémentaire de rendre les seuils plus simples à comprendre.
De plus, les appareils ne rentrent pas toujours dans une seule catégorie. Cela doit-il être basé sur le format de l’appareil, la puissance de traitement ou les conditions du réseau ? Avoir les mêmes seuils présente l’avantage secondaire d’éviter cette complexité.
La nature plus contrainte des appareils mobiles signifie que la plupart des seuils sont donc fixés en fonction de la réalisabilité mobile. Il s’agit plus probablement de seuils mobiles, plutôt que d’un véritable seuil commun à tous les types d’appareils. Cependant, étant donné que le mobile représente souvent la majorité du trafic sur la plupart des sites, cela est moins préoccupant.
Voici les scores sur lesquels Chrome a opté :
Les scores inférieurs à 200 ms (millisecondes) ont été choisis pour représenter un « bon » score. Les scores compris entre 200 ms et 500 ms représentent un score « à améliorer ». Des performances supérieures à 500 ms représentent un score « médiocre ».
Capture d’écran d’une interaction avec le prochain score de peinture
Les appareils bas de gamme ont été pris en compte
Chrome s’est concentré sur le choix de mesures réalisables. C’est pourquoi les seuils d’INP devaient être réalistes pour les appareils mobiles bas de gamme, car un grand nombre d’entre eux sont utilisés pour accéder à Internet.
Ils ont expliqué :
« Nous avons également accordé une attention particulière à la possibilité de réussir l’INP pour les appareils mobiles bas de gamme, où ceux-ci représentaient une proportion élevée de visites sur les sites. Cela a confirmé en outre la pertinence d’un seuil de 200 ms.
En prenant en compte le seuil de 100 ms soutenu par la recherche sur la qualité de l’expérience et les critères de réalisabilité, nous concluons que 200 ms est un seuil raisonnable pour de bonnes expériences.
Les sites les plus populaires ont influencé les seuils INP
Un autre aspect intéressant de la nouvelle documentation est que la réalisabilité des scores dans le monde réel était une autre considération pour les mesures de notation INP, mesurées en millisecondes (ms). Ils ont examiné les performances des 10 000 meilleurs sites Web, car ils représentaient la grande majorité des visites de sites Web, afin de déterminer le seuil approprié pour les mauvais scores.
Ils ont découvert que les 10 000 meilleurs sites Web avaient du mal à atteindre des scores de performances de 300 ms. Les données CrUX qui rapportent l’expérience utilisateur réelle ont montré que 55 % des visites sur les sites les plus populaires se déroulaient au seuil de 300 ms. Cela signifiait que l’équipe Chrome devait choisir un score en millisecondes plus élevé, réalisable par les sites les plus populaires.
La nouvelle documentation explique :
« Lorsque nous examinons les 10 000 principaux sites – qui représentent la grande majorité de la navigation sur Internet – nous voyons émerger une image plus complexe…
Sur mobile, un seuil « médiocre » de 300 ms classerait la majorité des sites populaires comme « médiocres », ce qui étendrait nos critères de réalisabilité, tandis qu’un seuil de 500 ms correspondrait mieux à une fourchette de 10 à 30 % des sites. Il convient également de noter que le seuil « bon » de 200 ms est également plus strict pour ces sites, mais avec 23 % des sites qui réussissent toujours ce seuil sur mobile, cela dépasse toujours nos critères de taux de réussite minimum de 10 %.
Pour cette raison, nous concluons qu’un seuil de 200 ms est un « bon » seuil raisonnable pour la plupart des sites, et qu’un seuil supérieur à 500 ms est un « mauvais » seuil raisonnable.
Barry Pollard, Web Performance Developer Advocate sur Google Chrome et co-auteur de la documentation, a ajouté un commentaire à une discussion sur LinkedIn qui offre plus d’informations générales :
« Nous avons fait des progrès incroyables sur INP au cours de la dernière année. Bien plus que ce que nous aurions pu espérer. Mais moins de 200 ms va être très difficile pour les appareils mobiles bas de gamme pendant un certain temps. Alors que les appareils mobiles haut de gamme sont désormais des chevaux de puissance absolus, le bas de gamme n’augmente pas à ce rythme… »
Une compréhension plus approfondie des scores INP
La nouvelle documentation offre une meilleure compréhension de la manière dont Chrome choisit les métriques réalisables et élimine une partie du mystère de la métrique relativement nouvelle INP Core Web Vital.
Lisez la documentation mise à jour :
Comment les seuils des métriques Core Web Vitals ont été définis
Image en vedette par Shutterstock/Vectorslab
