Quête de l'Economic Times pour résoudre l'INP

En réduisant son taux de rebond par 30 et en migrant vers Next.js, The Ecomonic Times a pu réduire son INP de près de quatre fois, avec une diminution de 50% du taux de rebond et une augmentation de 43% du nombre de pages vues.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

L'Interaction to Next Paint (INP) est une métrique qui évalue la réactivité d'un site Web aux entrées utilisateur. Une bonne réactivité signifie qu'une page est rapide à répondre aux interactions des utilisateurs. Plus l'INP d'une page est faible, meilleure est sa capacité à répondre aux interactions des utilisateurs.

Les bonnes valeurs INP sont inférieures ou égales à 200 millisecondes, les valeurs faibles sont supérieures à 500 millisecondes et tous les éléments intermédiaires doivent être améliorés.

Un début flou

Lorsque Google a initialement lancé INP comme métrique expérimentale pouvant évoluer vers l'une des métriques Core Web Vitals, l'équipe de l'équipe Economic Times a relevé le défi de la corriger avant qu'elle ne devienne une métrique unique, car offrir une expérience utilisateur de premier ordre est crucial pour nos valeurs métier fondamentales.

L'INP a été l'une des métriques les plus difficiles à résoudre jusqu'à présent. Au début, il n'était pas clair de savoir comment mesurer efficacement l'INP. Ce qui était encore plus difficile, c'était le manque d'assistance de la communauté, y compris la plupart des fournisseurs de Real User Monitoring (RUM) qui n'en assurent pas encore la prise en charge. Cependant, nous disposions d'outils RUM de Google, tels que le rapport sur l'expérience utilisateur de Chrome (CrUX), la bibliothèque JavaScript web-vitals et d'autres solutions compatibles. Cela nous a donné une idée de notre position lorsque nous évaluons la voie à suivre. Notre INP était proche de 1 000 millisecondes au niveau de l'origine lorsque nous avons commencé.

Lors de la correction de l'INP sur le terrain, l'une des métriques à cibler pourrait être Total Blocking Time (TBT). L'équipe Fitbit était déjà bien documentée et soutenue par la communauté. Bien que nous respections déjà les seuils des métriques Core Web Vitals, nous n'étions pas aussi bons sur le devant de la plate-forme, car plus de trois secondes étaient écoulées lorsque nous avons commencé.

Qu'est-ce que le TLN et quelles mesures avons-nous prises pour l'améliorer ?

La mesure de l'état de la page est une métrique d'atelier qui mesure la réactivité d'une page Web aux entrées utilisateur lors de son chargement. Toute tâche dont l'exécution prend plus de 50 millisecondes est considérée comme une tâche longue, et le temps après le seuil de 50 millisecondes est appelé temps de blocage.

Le calcul du délai d'affichage est calculé en additionnant le temps de blocage de toutes les longues tâches pendant le chargement de la page. Par exemple, s'il y a deux longues tâches pendant le chargement, le temps de blocage est déterminé comme suit:

  • La tâche A prend 80 millisecondes (30 millisecondes plus que 50 millisecondes).
  • La tâche B prend 100 millisecondes (50 millisecondes de plus que 50 millisecondes).

La durée de navigation détaillée de la page sera de 80 millisecondes (30 + 50). Plus le Tot est bas, mieux c'est. De plus, plus il est corrélé avec l'INP.

Voici un bref comparatif en laboratoire entre l'avant et l'après avoir pris des mesures pour l'améliorer:

<ph type="x-smartling-placeholder">
</ph> Image composite de longues tâches au démarrage, comme indiqué dans le panneau &quot;Performances&quot; des outils pour les développeurs Chrome, et rapport sur les métriques de la page. Le thread principal est bloqué pendant le chargement de la page pendant 3 260 millisecondes. <ph type="x-smartling-placeholder">
</ph> Thread principal au démarrage avant d'optimiser la TA Le temps de latence estimé est de 3 260 millisecondes.
<ph type="x-smartling-placeholder">
</ph> Image composite de longues tâches au démarrage, comme indiqué dans le panneau &quot;Performances&quot; des outils pour les développeurs Chrome, et rapport sur les métriques de la page. Le thread principal est bloqué pendant le chargement de la page pendant 120 millisecondes. <ph type="x-smartling-placeholder">
</ph> Thread principal lors du démarrage après avoir optimisé la fonctionnalité de navigation détaillée. Le temps de latence estimé est de 120 millisecondes.

Réduire le travail du thread principal

Le thread principal du navigateur gère tout, de l'analyse du code HTML à la création du DOM, en passant par l'analyse du code CSS et l'application de styles, ainsi que l'évaluation et l'exécution de JavaScript. Le thread principal gère également les interactions utilisateur, c'est-à-dire les clics, les appuis et les appuis sur des touches. Si le thread principal est occupé par d'autres tâches, il peut ne pas répondre efficacement aux entrées utilisateur et entraîner une expérience utilisateur saccadée.

Cette tâche a été la plus difficile pour nous, car nous disposons de nos propres algorithmes permettant de détecter l'identité des utilisateurs pour diffuser des annonces en fonction de l'état d'abonnement et de scripts tiers pour les tests A/B, les analyses, etc.

Au début, nous avons pris de petites mesures, comme abaisser la priorité du chargement des ressources d'entreprise moins importantes. Deuxièmement, nous avons utilisé requestIdleCallback pour les tâches non critiques, ce qui peut aider à réduire le volume de données de localisation.

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

Il est recommandé de spécifier un délai avant expiration lorsque vous utilisez requestIdleCallback, car cela garantit que si le délai donné est écoulé et que le rappel n'est pas déjà appelé, il exécute le rappel immédiatement après le délai d'inactivité.

Réduire le temps d'évaluation des scripts

Nous avons également chargé des bibliothèques tierces de manière différée à l'aide de composants chargeables. Nous avons également supprimé les codes JavaScript et CSS inutilisés en profilant la page à l'aide de l'outil de couverture dans les outils pour les développeurs Chrome. Cela nous a permis d'identifier les domaines dans lesquels il était nécessaire de faire secousses d'arborescence pour expédier moins de code lors du chargement de la page, et ainsi réduire la taille du bundle initial de l'application.

Capture d&#39;écran de l&#39;outil de couverture dans les outils pour les développeurs Chrome. Ici, l&#39;outil affiche les parties inutilisées des fichiers JavaScript et CSS pendant le chargement de la page.

Réduire la taille du DOM

Selon Lighthouse, les grandes tailles de DOM augmentent l'utilisation de la mémoire, ce qui entraîne des recalculs de style plus longs et de coûteux ajustements de la mise en page.

Capture d&#39;écran de l&#39;audit de la taille du DOM dans Lighthouse Le nombre d&#39;éléments DOM signalés est de 2 706.

Nous avons réduit le nombre de nœuds DOM de deux manières:

  • Tout d'abord, nous avons affiché nos éléments de menu à la demande de l'utilisateur (lors d'un clic). Elle a réduit la taille du DOM d'environ 1 200 nœuds.
  • Deuxièmement, nous avons chargé de manière différée des widgets moins importants.

Grâce à tous ces efforts, nous avons considérablement réduit le volume de données tubulaires, de même que notre INP de près de 50%:

Capture d&#39;écran de l&#39;audit INP dans CrUX L&#39;INP de la page est de 539 millisecondes, ce qui dépasse la valeur &quot;médiocre&quot; de sortie.

À ce stade, nous n'étions presque pas parvenus à obtenir les résultats escomptés pour réduire davantage le taux de conversion supplémentaire (et l'INP par proxy), mais nous savions que nous avions beaucoup de possibilités d'amélioration. C'est alors que nous avons décidé de mettre à niveau le code récurrent de notre interface utilisateur personnalisée vers la dernière version de React avec Next.js afin de mieux utiliser les hooks et d'éviter le reaffichage inutile des composants.

En raison de mises à jour plus fréquentes et d'un trafic relativement inférieur par rapport aux autres parties du site Web, nous avons commencé à migrer nos pages thématiques vers Next.js. Nous avons également utilisé PartyTown pour décharger les threads principaux supplémentaires des nœuds de calcul Web, ainsi que des techniques telles que requestIdleCallBack pour différer les tâches non critiques.

En quoi l'amélioration de l'INP a-t-elle aidé The Economic Times ?

TBT et INP actuels à l'origine

Au moment de la publication de cet article, le délai de mise en correspondance pour notre origine était de 120 millisecondes, contre 3 260 millisecondes lorsque nous avons commencé nos efforts d'optimisation. De même, l'INP de notre origine était de 257 millisecondes après nos efforts d'optimisation, contre plus de 1 000 millisecondes.

Capture d&#39;écran de l&#39;audit INP dans CrUX L&#39;INP de la page est de 257 millisecondes, ce qui est dans la plage des « améliorations nécessaires » de sécurité.

Tendance INP CrUX

Le trafic reçu sur les pages thématiques ne représente qu'une part significative du trafic global. C'était donc un lieu idéal pour faire des expérimentations. Les résultats de l'expérience utilisateur CrUX, ainsi que les résultats commerciaux, étaient très encourageants et nous ont poussés à étendre nos efforts sur l'ensemble du site Web afin d'en récolter davantage.

Capture d&#39;écran de la répartition des INP telle qu&#39;illustrée dans l&#39;expérience utilisateur Chrome (CrUX) sur une période de quatre mois, de juillet 2022 à octobre 2022 Les valeurs comprises dans la catégorie &quot;pauvres&quot; et « à améliorer » Les seuils ont légèrement diminué, alors que les valeurs comprises dans la plage &quot;Satisfaisantes&quot; le seuil a augmenté.

Analyse Akamai mPulse

Nous utilisons la solution RUM Akamai mPulse, qui mesure le taux de précision sur le terrain. Nous avons observé une baisse constante du taux d'intoxication, ce qui reflète clairement les résultats de nos efforts pour réduire l'INP. Comme le montre la capture d'écran ci-dessous, les valeurs de ciblage par niveau d'appareil ont fini par passer d'environ 5 secondes à environ 200 millisecondes sur le terrain.

Capture d&#39;écran d&#39;un graphique dans Akamai mPulse, qui montre une baisse de la TAT sur environ un mois.

Résultat commercial

Dans l'ensemble, nos efforts visant à réduire le taux de change de 30 fois et la migration vers Next.js nous ont permis de diviser l'INP près de quatre fois, ce qui a conduit à une baisse de 50% du taux de rebond et à une augmentation de 43% du nombre de pages vues sur les pages thématiques.

Capture d&#39;écran de Google Analytics comparant les pages vues au taux de rebond. Grâce aux optimisations apportées à INP sur le site Web de The Economic Times, l&#39;entreprise a enregistré une diminution de 50% du taux de rebond et une augmentation de 43% du nombre de pages vues.

Conclusion

Pour résumer, INP a largement contribué à déterminer les problèmes de performances d'exécution sur certaines parties du site Web d'Economics Times. Il s'est avéré l'une des métriques les plus efficaces pour avoir un impact positif sur les résultats commerciaux. Les chiffres très encourageants que nous avons observés suite à ces efforts nous incitent à étendre nos efforts d'optimisation à d'autres sections de notre site Web et à en tirer des avantages supplémentaires.