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 susceptible de devenir 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 est l'une des métriques les plus difficiles à résoudre à ce jour. Au début, nous ne savions pas 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. Au début,notre INP était proche de 1 000 millisecondes au niveau de l'origine.
Une chose est ressortie lors de la correction de l'INP dans le champ : l'une des métriques de laboratoire à cibler pourrait être le temps de blocage total (TBT). TBT était déjà bien documenté et pris en charge par la communauté. Bien que nous ayons déjà atteint les seuils des métriques Core Web Vitals, nous n'étions pas aussi performants en termes de TBT, qui était supérieur à trois secondes au début.
Qu'est-ce que le TBT 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 qui prend plus de 50 millisecondes à s'exécuter est considérée comme une tâche longue. Le temps qui suit le seuil de 50 millisecondes est appelé temps de blocage.
Le TBT est calculé en additionnant le temps de blocage de toutes les tâches longues 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).
Le TBT 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 CSS et l'application des styles, ainsi que l'évaluation et l'exécution du code 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 contribuer à réduire le temps de réponse.
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é le JavaScript et le CSS inutilisés en profilant la page avec 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
Selon 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 temps de traitement des demandes et notre INP a diminué d'environ 50%:
À ce stade, nous n'avions presque plus de solutions simples pour réduire davantage le TBT (et l'INP par proxy), mais nous savions que nous avions beaucoup de marge de progression. C'est alors que nous avons décidé de passer à la dernière version de React avec Next.js pour mieux utiliser les hooks et éviter le rendu inutile des composants.
En raison de mises à jour plus fréquentes et d'un trafic relativement moins important que les autres parties du site Web, nous avons commencé à migrer nos pages thématiques vers Next.js. Nous avons également utilisé PartyTown pour décharger des tâches lourdes supplémentaires du thread principal vers des workers 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 TBT de 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 généré par les pages de thèmes représente une part beaucoup plus faible du trafic global. C'est pourquoi il était idéal pour les tests. 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 de la durée de chargement de la page avec mPulse d'Akamai
Nous utilisons Akamai mPulse comme solution RUM, qui mesure le TBT sur le terrain. Nous avons constaté une diminution constante du TBT, qui correspond clairement aux résultats de nos efforts visant à 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'est avéré être 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.