L'optimisation des métriques Core Web Vitals sur le site Web The Economic Times a considérablement amélioré l'expérience utilisateur et réduit considérablement le taux de rebond sur l'ensemble du site.
Avec l'amélioration du débit Internet jour après jour, les utilisateurs s'attendent à ce que les sites Web répondent et se comportent plus rapidement que jamais. The Economic Times gère plus de 45 millions d'utilisateurs actifs par mois. En optimisant les métriques Core Web Vitals pour l'ensemble du domaine, sur les pages AMP et non-AMP, nous avons réussi à réduire considérablement les taux de rebond et à améliorer l'expérience de lecture.
Mesurer l'impact
Nous nous sommes concentrés sur les métriques Largest Contentful Paint (LCP) et Cumulative Layout Shift (CLS), car elles sont les plus importantes pour offrir une expérience de lecture de qualité aux utilisateurs. Après avoir amélioré les performances de ses rapports (comme décrit ci-dessous), The Economic Times est parvenu à améliorer considérablement les métriques de ses rapports Chrome User Experiments (CrUX) en quelques mois.
Dans l'ensemble, le CLS s'est amélioré de 250 %, passant de 0,25 à 0,09. Globalement, le LCP a augmenté de 80 %, passant de 4,5 secondes à 2,5 secondes.
De plus, les valeurs LCP de la plage "Médiocre" ont diminué de 33% entre octobre 2020 et juillet 2021:
De plus, les valeurs CLS de la plage "Médiocre" ont été réduites de 65 % et les valeurs CLS de la plage "Bon" ont augmenté de 20% au cours de la même période:
Résultat : The Economic Times, qui n'avait pas atteint auparavant les seuils des métriques Core Web Vitals, a désormais dépassé les seuils des métriques Core Web Vitals pour l'ensemble de son origine et a réduit ses taux de rebond de 43% au total.
Qu'est-ce que le LCP et comment l'avons-nous amélioré ?
Le plus grand élément est le plus pertinent pour améliorer l'expérience utilisateur et mesurer la vitesse de chargement. Les métriques de performances telles que First Contentful Paint (FCP) ne tiennent compte que de l'expérience de chargement initiale d'une page. En revanche, le LCP indique le délai d'affichage de la plus grande section d'image, de texte ou de vidéo visible par l'utilisateur.
En plus de passer à un fournisseur DNS plus rapide et d'optimiser les images, voici quelques-unes des techniques que nous avons appliquées pour améliorer le LCP.
Requêtes critiques en premier
Étant donné que tous les navigateurs récents limitent le nombre de requêtes simultanées, les développeurs doivent commencer par charger le contenu critique en priorité. Pour charger une page Web complexe, nous devons télécharger des assets tels que des éléments d'en-tête, des fichiers CSS, des ressources JavaScript, une hero image, le corps de l'article, des commentaires, d'autres actualités associées, un pied de page et des annonces. Nous avons évalué les éléments requis pour le LCP et avons donné la préférence de charger ces éléments en premier afin d'améliorer le LCP. Nous avons également reporté les appels qui ne faisaient pas partie de l'affichage initial de la page.
Apparence du texte
Nous avons testé la propriété font-display
, car elle affecte à la fois le LCP et le CLS. Nous avons essayé font-display: auto;
, puis nous sommes passés à font-display: swap;
. Le texte s'affiche ainsi initialement dans la police la plus adaptée et disponible, puis bascule vers la police une fois téléchargée. Cela nous a permis d'afficher notre texte rapidement, indépendamment de la vitesse du réseau.
Meilleure compression
Brotli est un algorithme de compression qui remplace Gzip et Deflate, développé par Google. Nous avons remplacé nos polices et nos éléments, et modifié la compression des serveurs, passant de Gzip à Brotli, pour réduire l'encombrement:
- Les fichiers JavaScript sont 15% plus petits qu'avec Gzip.
- Les fichiers HTML sont 18% plus petits qu'avec Gzip.
- Les fichiers CSS et de police sont 17% plus petits qu'avec Gzip.
Connexion préalable à des domaines tiers
preconnect
doit être utilisé avec précaution, car il peut occuper un temps CPU précieux et retarder d'autres ressources importantes, en particulier sur les connexions sécurisées.
Toutefois, si l'on sait qu'une ressource va être récupérée sur un domaine tiers, preconnect
est la bonne option. Si cela ne se produit que de manière occasionnelle sur un site Web très fréquenté, preconnect
peut déclencher des tâches TCP et TLS inutiles. Ainsi, dns-prefetch
était plus adapté aux ressources tierces (réseaux sociaux, analyses, etc.) pour effectuer des résolutions DNS en amont.
Diviser le code en blocs
Dans l'en-tête du site, nous n'avons chargé que les ressources qui contiennent une partie essentielle de la logique métier ou qui étaient essentielles à l'affichage de la page au-dessus de la ligne de flottaison. De plus, nous avons divisé notre code en fragments avec la scission du code. Cela nous a aidés à améliorer davantage le LCP des pages.
Amélioration de la mise en cache
Pour toutes les routes d'interface, nous avons ajouté une couche Redis qui diffusait les modèles à partir du cache. Cela réduit le temps de calcul sur le serveur et crée l'intégralité de l'UI dans chaque requête, ce qui réduit le LCP des requêtes suivantes.
Synthèse des objectifs et des résultats LCP
Avant de commencer le projet d'optimisation, l'équipe a comparé son score LCP à 4,5 secondes (pour le 75e centile de ses utilisateurs, d'après les données des champs du rapport d'expérience utilisateur Chrome). À l'issue du projet d'optimisation, elle a été réduite à 2,5 secondes.
Qu'est-ce que le CLS et comment l'avons-nous amélioré ?
Avez-vous déjà remarqué un mouvement inattendu du contenu d'une page en parcourant un site Web ? Cela peut être dû au chargement asynchrone de contenus multimédias (images, vidéos, annonces, etc.) sur la page dont les dimensions sont inconnues. Dès que les ressources multimédias sont chargées, la mise en page est décalée.
Nous allons passer en revue les mesures que nous avons prises pour améliorer le CLS sur le site Web de The Economic Times.
Utiliser des espaces réservés
Nous avons utilisé un espace réservé stylisé pour les blocs d'annonces et les éléments multimédias de dimensions connues afin d'éviter les décalages de mise en page lors du chargement et de l'affichage des annonces sur la page. Cela permet d'éliminer les décalages de mise en page en réservant de l'espace pour l'annonce.
Dimensions de conteneur définies
Nous avons spécifié des dimensions explicites pour toutes les images et tous les conteneurs afin que le moteur de navigateur n'ait pas besoin de calculer la largeur et la hauteur des éléments DOM une fois qu'ils sont disponibles. Cela a évité des décalages de mise en page inutiles et des tâches de peinture supplémentaires.
Résumer les objectifs et les réalisations du CLS
Avant de commencer le projet d'optimisation, l'équipe a comparé son score CLS à 0,25. Nous avons pu réduire ce nombre de façon significative de 90%, pour atteindre 0,09.
Qu'est-ce que le FID (First Input Delay) et comment l'améliorer ?
Le premier délai d'entrée est la métrique qui suit la réactivité d'un site Web à l'entrée utilisateur. La principale cause d'un score FID médiocre est une charge JavaScript lourde qui maintient le thread principal du navigateur occupé, ce qui peut retarder les interactions de l'utilisateur. Nous avons amélioré FID de plusieurs façons.
Décomposer les longues tâches JavaScript
Les tâches longues sont des tâches qui durent 50 millisecondes ou plus. Les tâches longues occupent le thread principal du navigateur et l'empêchent de répondre à l'entrée utilisateur. Lorsque cela était possible, nous avons divisé les tâches de longue durée en tâches plus petites, à la demande de l'utilisateur, ce qui nous a permis de réduire l'encombrement JavaScript.
Différer le code JavaScript inutilisé
Pour que la page reste plus réactive, nous avons privilégié le contenu de la page par rapport à des scripts tiers tels que des outils d'analyse. Cependant, certaines bibliothèques sont soumises à certaines limites, car elles doivent être chargées dans le document <head>
afin de suivre avec précision le parcours utilisateur.
Réduire les polyfills
Nous avons réduit notre dépendance à certains polyfills et bibliothèques, car les navigateurs sont compatibles avec les API modernes et moins d'utilisateurs utilisent d'anciens navigateurs, comme Internet Explorer.
Annonces avec chargement différé
Le chargement différé des annonces dans la partie en dessous de la ligne de flottaison a permis de réduire le temps de blocage du thread principal et donc d'améliorer le FID.
Résumer les objectifs et les résultats du FID
À partir de tests de routine, nous avons pu réduire le FID de 200 ms à moins de 50 ms aujourd'hui.
Prévenir les régressions
The Economics Times prévoit de lancer des contrôles de performance automatisés en production pour éviter les régressions des performances des pages. Elle prévoit d'évaluer Lighthouse-CI pour automatiser les tests de laboratoire, ce qui peut éviter les régressions sur sa branche de production.