Pourquoi Google Lighthouse n’inclut pas INP, un élément vital pour le web

By: Mr. Cointe

Spread the love

Lighthouse de Google n’utilise pas la métrique Interaction to Next Paint (INP) dans ses tests standard, bien qu’INP soit l’un des Core Web Vitals.

Barry Pollard, défenseur des développeurs de performances Web sur Google Chrome, expliqué le raisonnement derrière cela et a offert un aperçu de la mesure de l’INP.

Lighthouse mesure les charges de page, pas les interactions

Lighthouse mesure un simple chargement de page et capture diverses caractéristiques au cours de ce processus.

Il peut estimer le Largest Contentful Paint (LCP) et le Cumulative Layout Shift (CLS) dans des conditions de charge spécifiques, identifier les problèmes et donner des conseils sur l’amélioration de ces mesures.

Cependant, INP est différent car il dépend des interactions des utilisateurs.

Pollard a expliqué :

« Le problème est que Lighthouse, comme de nombreux outils de performance Web, charge généralement simplement la page et n’interagit pas avec elle. Aucune interaction = Aucun INP à mesurer ! »

Les flux d’utilisateurs personnalisés permettent la mesure INP

Bien que Lighthouse ne puisse pas mesurer l’INP, connaître les parcours utilisateur courants vous permet d’utiliser les « flux d’utilisateurs » pour mesurer l’INP.

Pollard a ajouté :

« Si, en tant que propriétaire de site, vous connaissez vos parcours d’utilisateurs courants, vous pouvez les mesurer dans Lighthouse à l’aide de « flux d’utilisateurs » qui mesureront ensuite l’INP.

Ces parcours utilisateur courants peuvent être automatisés dans un environnement d’intégration continue, permettant aux développeurs de tester INP sur chaque validation et de repérer les régressions potentielles.

En rapport: Comment mesurer les éléments essentiels du Web

Temps de blocage total en tant que proxy INP

Bien que Lighthouse ne puisse pas mesurer l’INP sans interactions, il peut mesurer les causes probables, particulièrement longues, du blocage des tâches JavaScript.

C’est là que la métrique Total Blocking Time (TBT) entre en jeu.

Selon Pollard :

« TBT (Total Blocking Time) mesure la durée totale de toutes les tâches supérieure à 50 ms. La théorie étant :

  • Beaucoup de tâches longues et bloquantes = risque élevé d’INP !
  • Peu de tâches longues et bloquantes = faible risque d’INP !

Limites du TBT en tant que substitut de l’INP

Le TBT présente des limites en tant que substitut à l’INP.

Pollard a noté :

« Si vous n’interagissez pas lors de tâches longues, vous n’aurez peut-être aucun problème d’INP. De plus, les interactions peuvent charger PLUS de JavaScript qui n’est pas mesuré par Lighthouse.

Il ajoute :

“C’est donc un indice, mais ne remplace pas la mesure réelle de l’INP.”

Optimisation des scores Lighthouse par rapport à l’expérience utilisateur

Certains développeurs optimisent les scores Lighthouse sans tenir compte de l’impact sur l’utilisateur.

Pollard met en garde contre cela, déclarant :

« Un modèle courant que je vois est de retarder TOUS les JS jusqu’à ce que l’utilisateur interagisse avec une page : idéal pour les scores Lighthouse ! Souvent terrible pour les utilisateurs 😢 :

  • Parfois, rien ne se charge jusqu’à ce que vous déplaciez la souris.
  • Souvent, votre première interaction prend plus de temps.

 

Pourquoi c’est important

Comprendre les relations Lighthouse, INP et TBT est nécessaire pour optimiser l’expérience utilisateur.

Reconnaître les limites de la mesure de l’INP permet d’éviter des optimisations malavisées.

Le conseil de Pollard pour mesurer l’INP est de se concentrer sur les interactions réelles des utilisateurs afin de garantir que les améliorations des performances améliorent l’UX.

L’INP restant un Core Web Vital, il est essentiel d’en saisir les nuances pour le maintenir dans un seuil acceptable.

Applications pratiques

Pour surveiller les performances du site et l’INP :

  1. Utilisez les « flux d’utilisateurs » de Lighthouse pour mesurer l’INP dans les parcours courants.
  2. Automatisez les flux d’utilisateurs dans CI pour surveiller l’INP et détecter les régressions.
  3. Utilisez TBT comme proxy INP, mais comprenez ses limites.
  4. Donnez la priorité aux mesures sur le terrain pour obtenir des données INP précises.
  5. Équilibrez les optimisations des performances avec les considérations UX.

Spread the love

Leave a Comment