Après plusieurs mois de travail pour améliorer les Core Web Vitals sur la page d'accueil de Mail.ru, le 75e percentile du Cumulative Layout Shift (CLS) a augmenté de 60 %, ce qui a permis d'augmenter la durée moyenne des sessions de 2,7% 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 l'Internet russophone et figure parmi les cinq premiers sites de Russie 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 permet aux utilisateurs d'accéder à leur messagerie, aux actualités, aux réseaux sociaux, aux recherches Internet axées sur les performances et plus encore.
Mail.ru souhaitait offrir à ses visiteurs une expérience utilisateur de haute qualité. Il a donc commencé à travailler sur l'amélioration des métriques Core Web Vitals. Avant de discuter de notre stratégie d'optimisation, nous devons d'abord noter quelques détails techniques sur la page d'accueil de Mail.ru.
Bien que le projet ait été développé depuis longtemps à l'aide de notre moteur de création de modèles interne Fest, nous avons commencé à migrer vers Svelte 3 en 2019.
Svelte implémente la réactivité sans utiliser de DOM virtuel, ce qui le rend moins gourmand en 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 permet de créer des bundles plus petits. Cela peut aider à réduire le temps de blocage total (TBT) 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 les Core Web Vitals, nous suivions d'autres métriques, comme le First Contentful Paint (FCP), dans notre tableau de bord interne sur les performances.
Notre script de collecte de métriques a été modifié pour collecter les Core Web Vitals et les transmettre à notre tableau de bord de performances à des fins de visualisation. 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 frontend universel dans 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 | TBT | TTI | |
| Pourcentage d'utilisateurs en fonction des seuils des métriques Core Web Vitals | bien | 52 % | 92 % | 33 % | 35 % | 42 % | 43 % |
| needs-improvement | 19 % | 5 % | 23 % | 38 % | 16 % | 25 % | |
| médiocre | 29 % | 3 % | 44 % | 27 % | 42 % | 32 % | |
Améliorer les métriques Core Web Vitals
Bien que de nombreux conseils existent pour améliorer les métriques Core Web Vitals, chaque projet présente des défis uniques. Pour la page d'accueil de Mail.ru, les opportunités suivantes ont été identifiées:
- Implémentation d'espaces réservés pour les bannières publicitaires afin de réduire le CLS.
- Utiliser le rendu côté serveur (SSR) pour réduire le LCP (Largest Contentful Paint).
- Fractionnement du code pour réduire le LCP et le First Input Delay (FID).
Squelettes pour améliorer le CLS
Le CLS était l'une des métriques de champ les moins performantes pour la page d'accueil de Mail.ru. Le profilage ultérieur de cette page dans le panneau "Performances" des outils pour les développeurs de 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 pour réserver de l'espace aux annonces avant leur chargement.
Lorsque vous implémentez des espaces réservés, la première étape consiste à déterminer les dimensions du contenu qui les remplacera. Heureusement, la version classique de la page d'accueil de Mail.ru présente des tailles d'annonces strictement documentées. Après avoir discuté avec l'équipe de conception, des squelettes d'UI animés en SVG ont été utilisés comme espaces réservés, car ils réduisent le temps de chargement perçu du contenu.
Le retour de SSR
Pour faciliter la transition de Fest vers Svelte, nous avons réécrit le projet existant de manière incrémentielle plutôt que de repartir de zéro. En mars 2021, nous avions migré la majeure partie du frontend vers Svelte et avons finalement implémenté le SSR dans 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 de la régression du CLS, qui était passée inaperçue au départ: la section d'actualités n'était pas insérée au moment du rendu du premier contenu sur la page. Un délai s'est produit entre la peinture initiale du balisage de la page fournie par le serveur et l'insertion de la section d'actualités sur le client. Ce comportement a entraîné un décalage du squelette de l'annonce, ce qui a aggravé le CLS.
Bien que les outils de développement de Chrome aient affiché des événements de décalage de mise en page, nous n'avons pas pu en déterminer la raison au début. Bien que le SSR ne soit pas le problème, il a permis de trouver la solution plus tard. La correction du code responsable du délai de peinture a amélioré la stabilité de la mise en page du composant "Actualités".
Le SSR peut également avoir un impact sur le CLS en déplaçant les 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 en particulier sur la version mobile. Nous avons donc dû accorder une attention particulière au balisage des composants hydratés. Une bonne solution à ce problème a été de transférer autant de logique d'affichage de JavaScript vers CSS que possible.
Fractionnement du code et polyfills inutilisés
Pour améliorer la vitesse de chargement perçue de la page, nous avons dû réduire les valeurs du LCP et du FID. Pour ce faire, vous pouvez utiliser la division du code. En plus de la page d'accueil de Mail.ru, notre équipe développe un widget de navigation pour le portail. Il est actuellement intégré à de nombreux projets de notre entreprise.
Pour des raisons historiques, le widget est inséré au tout début de la page en tant que script de chargement synchrone. La part des polyfills dans ce script a augmenté au fil du temps. Pour limiter les effets négatifs sur les performances du chargement de ces polyfills, nous avons implémenté le fractionnement du code pour les navigateurs modernes et anciens.
Nous avons décidé de ne pas utiliser le modèle module/nomodule pour charger des 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 y remédier, Mail.ru utilise un outil interne permettant d'identifier les versions modernes des navigateurs côté backend et de s'adapter en conséquence.
Une fois que les navigateurs ont pu être identifiés dans le backend, nous avons implémenté le fractionnement du code pour les navigateurs modernes et anciens. Résultat : la taille du widget JavaScript chargé de manière synchrone pour les navigateurs modernes a été réduite de 43,3 %. Cette pratique a également été appliquée à d'autres scripts du portail.
En plus de réduire la taille du bundle et d'avoir un impact positif sur les métriques Core Web Vitals, le fractionnement du code améliore également l'expérience pour les développeurs. Seuls 3,5% de nos utilisateurs utilisent d'anciens navigateurs, et cette part est à la baisse.L'implémentation du fractionnement du code a donc permis à nos développeurs d'utiliser les dernières API de navigateur sans imposer à tous les utilisateurs le gonflement des polyfills nécessaire pour les anciens navigateurs.
Résultats
Après l'optimisation, nous avons observé les valeurs moyennes pour la semaine du 24 au 30 mai 2021 dans nos données sur le terrain:
| Nom du groupe de métriques | Core Web Vitals | Autres Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Nom de la métrique | LCP | FID | CLS | FCP | TBT | TTI | |
| Pourcentage d'utilisateurs en fonction des seuils des métriques Core Web Vitals | bien | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 18 % | 4 % | 3 % | 34 % | 17 % | 24 % | |
| médiocre | 24 % | 3 % | 4 % | 23 % | 34 % | 25 % | |
Les graphiques ci-dessous montrent 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 sections de la dernière page migrées vers Svelte.
- 19 avril 2021: publication de l'itération avec SSR renvoyé et mise à jour de la mise en page pour corriger les régressions CLS.
La baisse des valeurs du 1er mai au 10 mai est due aux vacances de mai en Russie.
Les résultats obtenus avec "Plate-forme" sont conformes à la croissance des valeurs des métriques dans le rapport d'expérience utilisateur Chrome (CrUX).
Une comparaison des valeurs de la durée moyenne des sessions utilisateur une semaine avant le déploiement des améliorations initiales et une semaine après le déploiement montre une augmentation de 2,7 %. De plus, le nombre de conversions a augmenté de manière significative dans la plupart des sections de la page. Plus précisément, les conversions vers l'application de messagerie Mail.ru ont augmenté de 11,6%, et celles vers la section d'actualités de 13,5%.
181 %
Augmentation de la part du seuil de CLS correct
2,7 %
Durée moyenne de session plus élevée
13,5 %
Augmentation du taux de conversion de la section "Actualités"
Le résultat le plus inattendu que nous avons obtenu est une augmentation de 17,4% du taux de clics (CTR) de la bannière marketing (son temps de rendu a été considérablement réduit grâce à l'introduction des balises SSR et de préchargement).
Après avoir analysé le reste des sections de la page, nous avons constaté une amélioration significative des performances dans la grande majorité d'entre elles. Même pour des sections telles que "Météo" et "Coronavirus", qui ne sont pas essentielles sur notre page, nous constatons une augmentation du taux de conversion de 9,6% et 9,5%, respectivement.
Conclusion
Améliorer les performances est difficile, car le travail impliqué peut être long. Vous devez surveiller régulièrement les variations des métriques au fil du temps et vous assurer que toutes les nouvelles fonctionnalités de votre produit ne provoquent pas de régressions dans les Core Web Vitals. Pour ce faire, nous surveillons les variations des métriques Core Web Vitals dans notre budget de performances.
Plus important encore, nous avons souligné l'importance des Core Web Vitals auprès de tous les membres de notre équipe produit, des responsables et concepteurs aux testeurs et à l'équipe d'assurance qualité. Chaque membre de l'équipe doit connaître les métriques de performances et être en mesure de les améliorer. Nous intégrons également régulièrement des objectifs d'optimisation des performances à nos processus métier. Pour offrir une expérience utilisateur de haute qualité, tous les membres de l'équipe doivent s'impliquer.