En réduisant son taux de conversion par 30 et en passant à Next.js, The Ecomonic Times a presque quatre fois diminué son INP, ce qui lui a permis de diminuer son taux de rebond de 50% et d'augmenter le nombre de pages vues de 43 %.
La métrique Interaction to Next Paint (INP) est une métrique qui évalue la réactivité d'un site Web face aux entrées utilisateur. Une bonne réactivité signifie qu'une page réagit rapidement aux interactions des utilisateurs. Plus l'INP d'une page est faible, plus celle-ci est en mesure de répondre aux interactions des utilisateurs.
Le début flou
Lorsque Google a lancé INP en tant que métrique expérimentale susceptible de devenir l'une des métriques Core Web Vitals, l'équipe d'Economics a relevé le défi de la corriger avant qu'elle n'en devienne une, car fournir une expérience utilisateur de classe mondiale est crucial pour les valeurs fondamentales de notre entreprise.
L'INP a été l'une des métriques les plus difficiles à résoudre jusqu'à présent. Au début, on ne savait pas comment mesurer efficacement l'INP. Ce qui rendait le problème encore plus difficile, c'était le manque d'assistance de la communauté, y compris la plupart des fournisseurs RUM (Real User Monitoring) qui ne le prennent pas encore en charge. Cependant, nous disposions d'outils Google RUM comme le rapport d'expérience utilisateur Chrome, la bibliothèque JavaScript web-vitals et d'autres outils compatibles, ce qui nous a donné une idée de notre position au moment d'évaluer la voie à suivre. Au début,notre INP était proche de 1 000 millisecondes au niveau de l'origine.
Lors de la correction de l'INP sur le terrain, il est apparu que l'une des métriques de l'atelier à cibler était le temps de blocage total. La fonctionnalité était déjà bien documentée et a été soutenue par la communauté. Bien que nous ayons déjà atteint les seuils des métriques Core Web Vitals, nous n'étions pas aussi performants sur le plan des métriques de navigation à long terme, car cela prenait plus de trois secondes lorsque nous avons commencé.
Qu'est-ce que la synthèse des e-mails et quelles mesures avons-nous prises pour l'améliorer ?
La fonctionnalité de test de navigation détaillée est une métrique expérimentale qui mesure la réactivité d'une page Web aux entrées utilisateur lors du 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.
La requête de navigation détaillée est calculée en additionnant le temps de blocage de toutes les longues tâches lors du chargement de la page. Par exemple, s'il y a deux tâches longues pendant le chargement, le temps de blocage est déterminé comme suit:
- La tâche A dure 80 millisecondes (30 millisecondes et plus de 50 millisecondes).
- La tâche B dure 100 millisecondes (50 millisecondes et plus que 50 millisecondes).
La durée de vie de la requête de conversion de la page est de 80 millisecondes (30 + 50). Plus la requête de test est faible, mieux c'est, et plus la requête de test est basse, meilleure est la corrélation avec l'INP.
Voici un bref comparatif de notre étude de cas avant et après les mesures prises pour l'améliorer:
Réduire le travail du thread principal
Le thread principal du navigateur gère l'analyse du code HTML, la création du DOM, l'analyse des fichiers 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 utilisateur, c'est-à-dire les clics, les appuis et les appuis sur des touches. Si le thread principal est occupé à effectuer d'autres tâches, il est possible qu'il ne réponde pas efficacement aux entrées utilisateur et que l'expérience utilisateur soit mauvaise.
Cette tâche a été la plus difficile pour nous, car nous disposons de nos propres algorithmes pour détecter l'identité des utilisateurs afin de 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, par exemple en redéfinissant la priorité de chargement des ressources métier moins critiques. Ensuite, nous avons utilisé requestIdleCallback pour les tâches non critiques, ce qui peut aider à réduire la perte de données.
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 lors de l'utilisation de requestIdleCallback, car cela garantit que si le temps donné est écoulé et que le rappel n'a pas déjà été 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 façon différée à l'aide de composants chargeables. Nous avons également supprimé les ressources JavaScript et CSS inutilisées 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 domaines dans lesquels le simulation dans les arbres était nécessaire pour envoyer moins de code lors du chargement de la page et ainsi réduire la taille initiale du bundle de l'application.
Réduire la taille du DOM
Selon Lighthouse, les tailles DOM volumineuses augmentent l'utilisation de la mémoire, entraînent des recalculs de style plus longs et entraînent de coûteux ajustements de la mise en page.
Nous avons réduit le nombre de nœuds DOM de deux façons:
- 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.
- Ensuite, nous avons chargé de façon différée des widgets moins importants.
Grâce à tous ces efforts, nous avons considérablement réduit notre INP de manière significative, tout comme notre INP de près de 50%:
À ce stade, nous n'avons quasiment plus réussi à réduire davantage la valeur de transfert des données (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 notre code récurrent d'interface utilisateur personnalisé vers la dernière version de React avec Next.js afin d'optimiser l'utilisation des hooks et d'éviter que les composants ne s'affichent inutilement.
En raison de mises à jour plus fréquentes et d'un trafic relativement moindre 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 tâches de thread principal supplémentaires et lourdes vers les 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 ?
TTC et INP actuels sur l'origine
Au moment de la publication de cet article, le délai de conversion pour notre origine était de 120 millisecondes, contre 3 260 millisecondes au début de 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.
Tendance CrUX de l'INP
Le trafic reçu sur les pages thématiques représente une partie significative du trafic global. Elle constituait donc l'endroit idéal pour l'expérimentation. Les résultats CrUX, ainsi que les résultats commerciaux, ont été très encourageants. Ils nous ont poussés à redoubler nos efforts sur l'ensemble du site Web pour en tirer de nouveaux avantages.
Analyse de la requête de synthèse vocale Akamai mPulse
Nous utilisons Akamai mPulse comme solution de type RUM, qui permet de mesurer la TVB sur le terrain. Nous avons observé une baisse constante des conversions après affichage, ce qui correspond clairement aux résultats de nos efforts pour réduire l'INP. Comme le montre la capture d'écran ci-dessous, les valeurs de conversion après modification sont finalement passées d'environ 5 secondes à environ 200 millisecondes sur le terrain.
Résultat commercial
Globalement, nos efforts pour réduire la valeur de conversion par 30 fois et la migration vers Next.js nous ont permis de presque diviser l'INP par quatre, ce qui s'est traduit par une réduction de 50% du taux de rebond et une augmentation de 43% du nombre de pages vues sur les pages thématiques.
Conclusion
En résumé, INP a largement contribué à déterminer les problèmes de performances d'exécution sur certaines parties du site Web d'Economics Times. Cette métrique s'est révélée l'une des plus efficaces pour avoir un impact positif sur les résultats commerciaux. En raison des résultats très encourageants que nous avons obtenus grâce à ces efforts, nous souhaitons étendre nos efforts d'optimisation à d'autres sections de notre site Web et en tirer des bénéfices supplémentaires.