En réduisant le TBT de 30 fois et en migrant vers Next.js, The Ecomomic Times a pu réduire l'INP de près de quatre fois, ce qui a entraîné une diminution de 50 % du taux de rebond et une augmentation de 43 % du nombre de pages vues.
La métrique Interaction to Next Paint (INP) évalue la réactivité d'un site Web aux entrées utilisateur. Une bonne réactivité signifie qu'une page répond rapidement aux interactions des utilisateurs. Plus l'INP d'une page est faible, plus elle est capable de répondre aux interactions des utilisateurs.
Le début flou
Lorsque Google a initialement lancé l'INP en tant que métrique expérimentale pouvant évoluer vers l'une des métriques Core Web Vitals, l'équipe de l'Economic Times s'est lancée dans la mission de la corriger avant qu'elle ne devienne une métrique officielle, car offrir une expérience utilisateur de classe mondiale est essentiel à nos valeurs fondamentales.
L'INP a été l'une des métriques les plus difficiles à résoudre à ce jour. Au début, il n'était pas clair comment mesurer efficacement l'INP. Le manque d'assistance de la part de la communauté a rendu la tâche plus difficile, y compris pour la plupart des fournisseurs de surveillance des utilisateurs réels (RUM, Real User Monitoring). Toutefois, nous disposions d'outils Google RUM tels que le rapport sur l'expérience utilisateur de Chrome (CrUX), la bibliothèque JavaScript web-vitals et d'autres outils qui nous ont permis de nous faire une idée de notre situation pendant que nous évaluions 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). TBT était déjà bien documenté et pris en charge 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 métrique TBT est une métrique de laboratoire qui mesure la réactivité d'une page Web aux entrées utilisateur pendant le chargement de la page. 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, si deux tâches longues sont exécutées pendant le chargement, le temps de blocage est déterminé comme suit :
- La tâche A prend 80 millisecondes (30 millisecondes de plus que 50 millisecondes).
- La tâche B prend 100 millisecondes (50 millisecondes de plus que la tâche A).
La durée de navigation détaillée de la page sera de 80 millisecondes (30 + 50). Plus le TBT est faible, mieux c'est. Il correle également bien avec l'INP.
Voici une comparaison rapide de notre TBT avant et après avoir pris des mesures pour l'améliorer :
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 des utilisateurs, c'est-à-dire les clics, les pressions et les frappes. Si le thread principal est occupé à effectuer d'autres tâches, il risque de ne pas répondre efficacement aux entrées utilisateur et de donner lieu à une expérience utilisateur saccadée.
Il s'agissait de la tâche la plus difficile pour nous, car nous utilisons nos propres algorithmes pour détecter l'identité des utilisateurs afin de diffuser des annonces en fonction de l'état de leur abonnement et de scripts tiers pour les tests A/B, les analyses, etc.
Nous avons commencé par de petits pas, comme la dépriorisation du chargement des éléments métier les moins critiques. Deuxièmement, nous avons utilisé requestIdleCallback pour les tâches non critiques, ce qui peut aider à réduire le volume de données infinies.
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 il s'assure que si le délai donné est écoulé et que le rappel n'a pas encore été appelé, il exécute le rappel immédiatement après le délai avant expiration.
Réduire le temps d'évaluation du script
Nous avons également chargé de manière paresseuse des bibliothèques tierces à 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 aidés à identifier les zones où le tree shaking était nécessaire pour expédier moins de code lors du chargement de la page et, par conséquent, réduire la taille du bundle initial de l'application.
Réduire la taille du DOM
D'après Lighthouse, les DOM de grande taille sollicitent davantage la mémoire, entraînent des nouveaux calculs de style plus longs et génèrent des ajustements de la mise en page coûteux.
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). La taille du DOM a été réduite d'environ 1 200 nœuds.
- Deuxièmement, nous avons chargé de manière différée les 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%:
À ce stade, nous n'avions presque plus de solutions faciles pour réduire davantage le TBT (et l'INP par proxy), mais nous savions que nous avions beaucoup de marge de progression. C'est à ce moment-là 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 d'optimiser l'utilisation des 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 sur 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 auparavant.
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 du rapport CrUX et les résultats commerciaux ont été très encourageants. Nous avons donc étendu nos efforts à l'ensemble du site Web pour en tirer d'autres avantages.
Analyse TBT mPulse d'Akamai
Nous utilisons Akamai mPulse comme solution RUM, qui mesure le TBT sur le terrain. Nous avons observé une baisse constante du taux de traitement des données à distance, 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 TBT sont passées d'environ cinq secondes à environ 200 millisecondes sur le terrain.
Résultat commercial
Globalement, nos efforts pour réduire le TBT de 30 fois et notre migration vers Next.js nous ont permis de réduire l'INP de près de quatre fois, ce qui a finalement entraîné une baisse de 50 % du taux de rebond et une augmentation de 43 % du nombre de pages vues sur les pages de sujets.
Conclusion
Pour résumer, INP a largement contribué à identifier les problèmes de performances d'exécution sur certaines parties du site Web de l'Economic Times. Il s'agit de l'une des métriques les plus efficaces pour avoir un impact positif sur les résultats commerciaux. Compte tenu des chiffres très encourageants que nous avons observés grâce à ces efforts, nous sommes motivés à étendre nos efforts d'optimisation à d'autres sections de notre site Web et à en tirer des avantages supplémentaires.