Plusieurs mois de travail pour améliorer les Core Web Vitals sur la page d'accueil de Mail.ru ont permis d'augmenter de 60% le 75e centile du CLS (Cumulative Layout Shift), ce qui a permis d'augmenter de 2,7% la durée moyenne des sessions et les taux de conversion des sections principales de plus de 10%.
Nos débuts
Mail.ru est l'un des principaux services de messagerie sur Internet russophone et figure dans le top 5 des sites russes en termes de trafic. Mail.ru est une ressource importante pour de nombreuses personnes. Il reçoit plusieurs centaines de millions de visites par mois et constitue un portail à partir duquel les utilisateurs peuvent accéder à des e-mails, des actualités, des réseaux sociaux, des recherches sur les performances sur Internet, etc.
Mail.ru souhaitait offrir à ses visiteurs une expérience utilisateur de haute qualité. C'est pourquoi nous avons commencé à améliorer les métriques Core Web Vitals. Avant de discuter de notre stratégie d'optimisation, notez quelques détails techniques de la page d'accueil de Mail.ru.
Bien que le projet ait été développé depuis longtemps avec notre moteur de création de modèles Fest interne, nous avons commencé à migrer vers Svelte 3 en 2019.
Svelte implémente la réactivité sans utiliser le DOM virtuel, ce qui réduit sa consommation de ressources. L'approche de Svelte supprime les fonctions inutilisées des bundles de production, car le code qui les implémente n'est pas généré par le compilateur si les fonctions ne sont pas utilisées. Le code inutilisé est supprimé lors de la compilation, ce qui se traduit par des bundles plus petits. Cela peut vous aider à réduire le temps de blocage total au démarrage de la page.
Suivre les métriques de performances
Avant d'optimiser les métriques Core Web Vitals, il est utile d'évaluer les performances sur le terrain. Avant le rapport Core Web Vitals, nous suivons d'autres métriques, telles que First Contentful Paint (FCP), dans notre tableau de bord des performances interne.
Notre script de collecte de métriques a été modifié afin de collecter les Core Web Vitals et de les transmettre à notre tableau de bord des performances pour les visualiser. Conformément aux recommandations de Google, notre script utilise l'API PerformanceObserver pour obtenir des métriques, qui font partie de la plate-forme de l'interface universelle de Mail.ru.
Le tableau de bord affichait les métriques suivantes pour les utilisateurs (valeurs moyennes pour la semaine du 15 au 21 mars 2021):
| Nom du groupe de métriques | Core Web Vitals | Autres Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Nom de la métrique | LCP | FID | CLS | FCP | À modifier | TTI | |
| Part d'utilisateurs conforme aux seuils des métriques Core Web Vitals | good | 52 % | 92 % | 33 % | 35 % | 42 % | 43 % |
| amélioration des besoins | 19 % | 5 % | 23 % | 38 % | 16 % | 25 % | |
| médiocre | 29 % | 3 % | 44 % | -27 % | 42 % | 32 % | |
Améliorer les Core Web Vitals
Même s'il existe de nombreux conseils pour améliorer les métriques Core Web Vitals, chaque projet présente des défis uniques. Pour la page d'accueil Mail.ru, les opportunités suivantes ont été identifiées:
- Implémenter des espaces réservés pour les bannières publicitaires afin de réduire le CLS.
- Utiliser le rendu côté serveur pour réduire le LCP (Largest Contentful Paint)
- Fractionnement du code pour réduire le LCP et le FID (First Input Delay)
Squelettes pour améliorer le CLS
Le CLS a été l'une des métriques de champ les moins performantes pour la page d'accueil de Mail.ru. Le profilage de cette page dans le panneau Performances des outils pour les développeurs Chrome a révélé que les annonces étaient à l'origine du problème. Pour améliorer la stabilité de la mise en page, notre équipe a décidé d'utiliser des espaces réservés afin de réserver de l'espace aux annonces avant leur chargement.
Lorsque vous ajoutez des espaces réservés, la première étape consiste à déterminer les dimensions du contenu qui les remplaceront. Heureusement, la version pour ordinateur de la page d'accueil Mail.ru applique des formats d'annonces strictement documentés. Après avoir discuté avec l'équipe de conception, des squelettes d'UI animées au format SVG ont été utilisées comme espaces réservés, car elles réduisent le temps de chargement perçu du contenu.
Le retour du SSR
Pour faciliter la transition de Fest à Svelte, nous avons progressivement réécrit le projet existant au lieu de tout recommencer. En mars 2021, nous avions migré la majeure partie de l'interface vers Svelte, avant d'intégrer la restauration rapide à notre application de production après avoir trié et corrigé les problèmes de performances du backend.
Après avoir implémenté le SSR, l'équipe a découvert la cause d'une régression au niveau du CLS, qui n'était initialement pas remarquée: la section "Actualités" n'était pas insérée au moment de l'affichage du premier contenu sur la page. Un délai est survenu entre le chargement initial du balisage de la page fourni par le serveur et l'insertion de la section "Actualités" sur le client. Ce comportement a entraîné un changement de squelette d'annonce, ce qui a aggravé le CLS.
Bien que les outils de développement Chrome affichaient des événements "Layout Shift", nous n'avons pas trouvé la raison de ce décalage au début. Même si le SSR n’était pas le problème en lui-même, il a aidé à découvrir la solution par la suite. La correction du code responsable du délai de rendu a amélioré la stabilité de la mise en page du composant Google Actualités.
Un autre effet du SSR sur le CLS est le déplacement des composants avant et après l'hydratation, ce qui peut entraîner d'autres décalages de mise en page. Nous avons rencontré ce problème sur la version mobile en particulier, et il a fallu prêter une attention particulière au balisage des composants hydratés. Une bonne solution à ce problème consistait à transférer autant de logique d'affichage de JavaScript vers CSS que possible.
Fractionnement de code et polyfills inutilisés
Pour améliorer la vitesse de chargement perçue des pages, des efforts ont été nécessaires pour réduire les valeurs LCP et FID. Pour ce faire, vous pouvez diviser le code. En plus de la page d'accueil Mail.ru, notre équipe développe un widget de navigation sur le portail. Il est actuellement intégré à un grand nombre de projets de notre entreprise.
Pour des raisons historiques, le widget est inséré au tout début de la page sous la forme d'un script de chargement synchrone. La part de polyfills dans ce script a augmenté au fil du temps. Pour limiter les effets négatifs du chargement de ces polyfills sur les performances, nous avons implémenté la division du code pour les navigateurs modernes et les anciens.
Nous avons décidé de ne pas utiliser le modèle module/nomodule pour charger les bundles JavaScript pour les navigateurs modernes ou anciens, car l'attribut type="module" de l'élément <script> ne ciblait pas les navigateurs suffisamment modernes pour nos besoins. Pour résoudre ce problème, Mail.ru utilise un outil interne qui identifie les versions de navigateurs les plus récentes sur le backend et peut s'adapter en conséquence.
Une fois les navigateurs identifiés dans le backend, nous avons mis en œuvre la division du code pour les navigateurs modernes et les anciens. Cela a permis de réduire de 43,3% la taille du widget JavaScript chargé de manière synchrone pour les navigateurs modernes. Cette pratique a également été appliquée à d'autres scripts de portail.
En plus de réduire la taille des lots et d'avoir des effets positifs sur les métriques Core Web Vitals, la division du code améliore également l'expérience des développeurs. Seuls 3,5% de nos utilisateurs utilisent d'anciens navigateurs, et cette part est en baisse.La mise en œuvre de la division du code a donc permis à nos développeurs d'utiliser les dernières API de navigateur sans introduire l'engorgement nécessaire aux anciens navigateurs pour tous les utilisateurs.
Résultats
Après l'effort d'optimisation, nous avons observé les valeurs moyennes de la semaine du 24 au 30 mai 2021 dans nos données réelles:
| Nom du groupe de métriques | Core Web Vitals | Autres Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Nom de la métrique | LCP | FID | CLS | FCP | À modifier | TTI | |
| Part d'utilisateurs conforme aux seuils des métriques Core Web Vitals | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| amélioration des besoins | 18 % | 4 % | 3 % | 34 % | 17 % | +24 % | |
| médiocre | +24 % | 3 % | 4 % | 23 % | 34 % | 25 % | |
Les graphiques ci-dessous présentent l'évolution des valeurs des métriques de performances des pages Web en fonction de la "plate-forme". Notez les deux dates importantes sur les graphiques:
- 23 mars 2021: publication de l'itération avec les dernières sections de page migrées vers Svelte.
- 19 avril 2021: publication de l'itération avec RRS renvoyé et mise en page modifiée pour corriger les régressions CLS.
La baisse des valeurs entre le 1er et le 10 mai est due aux vacances de mai en Russie.
Les résultats obtenus à l'aide de la "Plate-forme" correspondent à l'augmentation des valeurs des métriques dans le rapport d'expérience utilisateur Chrome (CrUX).
Une comparaison des valeurs de durée moyenne des sessions utilisateur une semaine avant le déploiement des améliorations initiales et une semaine après le déploiement indique une croissance de 2,7 %. En outre, on constate une augmentation globale importante du nombre de conversions dans la plupart des sections de la page. En particulier, les conversions vers l'application de messagerie Mail.ru ont augmenté de 11,6 % et celles de la section "Actualités" de 13,5%.
181%
Augmentation de la part d'un seuil CLS correct
2,7 %
Durée moyenne des sessions plus élevée
13,5 %
d'augmentation du taux de conversion de la section d'actualités
Le résultat le plus inattendu que nous avons obtenu a été une augmentation de 17,4% du taux de clics (CTR) de la bannière marketing (son délai d'affichage a été considérablement réduit grâce à l'introduction des tags SSR et de préchargement).
Après avoir analysé les autres sections de la page, nous avons constaté une amélioration significative des performances dans la grande majorité d'entre elles. Même pour les rubriques comme "Météo" et "Coronavirus", qui ne sont pas essentielles sur notre page, nous constatons une augmentation des conversions de 9,6% et 9,5%, respectivement.
Conclusion
Améliorer les performances représente un défi, car le travail à effectuer peut être prolongé. Vous devez surveiller régulièrement l'évolution des métriques au fil du temps et vous assurer que toutes les nouvelles fonctionnalités du produit n'entraînent pas de régressions dans Core Web Vitals. Pour ce faire, nous surveillons l'évolution de notre budget de performances dans les métriques Core Web Vitals.
Plus important encore, nous avons souligné l'importance des Core Web Vitals pour tous les membres de notre équipe produit, des responsables aux concepteurs en passant par les testeurs et le contrôle qualité. Chaque membre de l'équipe doit connaître les mesures de performance et être habilité à les améliorer. De plus, nous intégrons régulièrement des objectifs d'optimisation des performances dans nos processus métier. Fournir une expérience utilisateur de haute qualité n'est possible qu'avec un effort commun de tous les membres de l'équipe.