Nach mehreren Monaten Arbeit zur Verbesserung der Core Web Vitals auf der Startseite von Mail.ru stieg der 75. Perzentilwert für den kumulativen Layout-Verschiebeeffekt (Cumulative Layout Shift, CLS) um 60 %. Die durchschnittliche Sitzungsdauer wurde um 2,7% und die Conversion-Raten der Hauptabschnitte um mehr als 10 % gesteigert.
Der Anfang
Mail.ru ist einer der führenden E-Mail-Dienste im russischsprachigen Internet und gehört zu den fünf meistbesuchten Websites in Russland. Mail.ru ist eine wichtige Ressource für viele Menschen. Es verzeichnet mehrere hundert Millionen Zugriffe pro Monat und ist ein Portal, über das Nutzer unter anderem auf E-Mails, Nachrichten, soziale Medien und leistungsstarke Internetsuchen zugreifen können.
Mail.ru wollte seinen Besuchern eine hohe Nutzerfreundlichkeit bieten. Daher begannen die Arbeiten zur Verbesserung der Core Web Vitals. Bevor wir unsere Optimierungsstrategie besprechen, sollten wir uns einige technische Details zur Startseite von Mail.ru ansehen.
Das Projekt wurde zwar schon lange mit unserer internen Fest-Template-Engine entwickelt, aber 2019 begannen wir mit der Migration zu Svelte 3.
Bei Svelte wird die Reaktivität so implementiert, dass kein virtuelles DOM verwendet wird. Das macht es weniger ressourcenintensiv. Beim Ansatz von Svelte werden nicht verwendete Funktionen aus Produktions-Bundles entfernt, da der Code, der sie implementiert, vom Compiler nicht generiert wird, wenn die Funktionen nicht verwendet werden. Nicht verwendeter Code wird während der Kompilierung entfernt, was zu kleineren Bundles führt. Dies kann dazu beitragen, die Gesamtblockierungszeit (Total Blocking Time, TBT) beim Seitenstart zu reduzieren.
Leistungsmesswerte erfassen
Bevor Sie Core Web Vitals optimieren, ist es hilfreich, die Leistung vor Ort zu bewerten. Vor Core Web Vitals haben wir in unserem internen Leistungsdashboard andere Messwerte wie First Contentful Paint (FCP) erfasst.
Unser Script zur Erfassung von Messwerten wurde so geändert, dass die Core Web Vitals erfasst und zur Visualisierung an unser Leistungsdashboard gesendet werden. Gemäß den Empfehlungen von Google verwendet unser Script die PerformanceObserver API, um Messwerte zu erhalten. Diese API ist Teil der universellen Frontend-Plattform von Mail.ru.
Im Dashboard wurden die folgenden Messwerte für Nutzer angezeigt (Mittelwerte für die Woche vom 15. bis 21. März 2021):
| Name der Messwertgruppe | Core Web Vitals | Weitere Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Messwertname | LCP | FID | CLS | FCP | TBT | TTI | |
| Anteil der Nutzer gemäß den Core Web Vitals-Grenzwerten | good | 52 % | 92 % | 33 % | 35 % | 42 % | 43 % |
| needs-improvement | 19 % | 5 % | 23 % | 38 % | 16 % | 25 % | |
| Schwach | 29 % | 3 % | 44 % | 27 % | 42 % | 32 % | |
Core Web Vitals verbessern
Es gibt zwar viele Anleitungen zur Verbesserung der Core Web Vitals, aber jedes Projekt stellt seine eigenen Herausforderungen. Für die Startseite von Mail.ru wurden die folgenden Verbesserungsmöglichkeiten identifiziert:
- Platzhalter für Anzeigenbanner implementieren, um den CLS zu senken.
- Verwenden Sie serverseitiges Rendering (SSR), um den Largest Contentful Paint (LCP) zu reduzieren.
- Code-Splitting zur Verringerung von LCP und First Input Delay (FID).
Skelette zur Verbesserung der CLS
Der CLS war einer der Feldmesswerte mit der schlechtesten Leistung für die Startseite von Mail.ru. Bei der anschließenden Profilierung dieser Seite im Bereich Leistung der Chrome-Entwicklertools wurde festgestellt, dass das Problem auf Anzeigen zurückzuführen war. Um die Layoutstabilität zu verbessern, hat unser Team beschlossen, Platzhalter zu verwenden, um Platz für Anzeigen zu reservieren, bevor sie geladen werden.
Wenn Sie Platzhalter implementieren, müssen Sie zuerst die Abmessungen der Inhalte ermitteln, die sie ersetzen sollen. Glücklicherweise sind die Anzeigengrößen auf der Desktopversion der Startseite von Mail.ru genau dokumentiert. Nach einem Gespräch mit dem Designteam wurden SVG-animierte UI-Skelette als Platzhalter verwendet, da sie die wahrgenommene Ladezeit der Inhalte reduzieren.
Die Rückkehr von SSR
Um die Umstellung von Fest auf Svelte zu erleichtern, haben wir das vorhandene Projekt schrittweise neu geschrieben, anstatt von vorn anzufangen. Bis März 2021 hatten wir den Großteil des Frontends zu Svelte migriert und schließlich SSR in unsere Produktionsanwendung eingeführt, nachdem wir Backend-Leistungsprobleme behoben hatten.
Nach der Implementierung von SSR fand das Team die Ursache für die CLS-Rückschritte, die anfangs unbemerkt geblieben waren: Der Nachrichtenbereich wurde nicht zum Zeitpunkt des Renderns der ersten Inhalte auf der Seite eingefügt. Zwischen dem ersten Zeichnen des vom Server bereitgestellten Seiten-Markups und dem Einfügen des Nachrichtenbereichs auf dem Client gab es eine Verzögerung. Dieses Verhalten führte zu einer Verschiebung des Anzeigen-Skeletts, was den CLS verschlechterte.
In den DevTools von Chrome wurden zwar Layout-Shift-Ereignisse angezeigt, wir konnten den Grund dafür aber zunächst nicht finden. Obwohl SSR nicht das Problem war, half es später, die Lösung zu finden. Durch die Behebung des Codes, der für die Verzögerung beim Zeichnen verantwortlich war, wurde die Layoutstabilität der Nachrichtenkomponente verbessert.
Ein weiterer Effekt, den SSR auf den CLS haben kann, ist die Bewegung von Komponenten vor und nach der Hydratation, was zu weiteren Layoutverschiebungen führen kann. Dieses Problem trat vor allem in der mobilen Version auf und erforderte besondere Aufmerksamkeit beim Markup der gepufferten Komponenten. Eine gute Lösung für dieses Problem bestand darin, nach Möglichkeit so viel Darstellungslogik wie möglich von JavaScript in CSS zu übertragen.
Codesplitting und nicht verwendete Polyfills
Um die wahrgenommene Ladegeschwindigkeit der Seite zu verbessern, mussten die LCP- und FID-Werte gesenkt werden. Eine Möglichkeit dazu ist das Code-Splitting. Neben der Mail.ru-Startseite entwickelt unser Team ein Widget für die Portalnavigation. Sie ist derzeit in vielen Projekten unseres Unternehmens eingebettet.
Aus historischen Gründen wird das Widget als synchrones Lades-Script ganz am Anfang der Seite eingefügt. Der Anteil der Polyfills in diesem Script stieg im Laufe der Zeit an. Um die negativen Leistungsauswirkungen des Ladens dieser Polyfills zu begrenzen, haben wir Code Splitting sowohl für moderne als auch für ältere Browser implementiert.
Wir haben uns gegen das module/nomodule-Muster zum Laden von JavaScript-Bundles für moderne oder ältere Browser entschieden, da das type="module"-Attribut des <script>-Elements nicht auf Browser ausgerichtet war, die für unsere Anforderungen modern genug waren. Um dies zu beheben, verwendet Mail.ru ein internes Tool, um moderne Browserversionen im Backend zu identifizieren und sich entsprechend an diese Browser anzupassen.
Sobald Browser im Backend erkannt werden konnten, haben wir Code Splitting für moderne und ältere Browser implementiert. Das Ergebnis war eine Reduzierung der Größe des synchron geladenen JavaScript-Widgets für moderne Browser um 43,3 %. Diese Vorgehensweise wurde auch auf einige andere Portalscripts angewendet.
Neben der Verringerung der Bundle-Größe und positiven Auswirkungen auf die Core Web Vitals verbessert das Code-Splitting auch die Entwicklerfreundlichkeit. Nur 3,5% unserer Nutzer verwenden alte Browser und dieser Anteil ist rückläufig.Durch die Implementierung von Code Splitting konnten unsere Entwickler die neuesten Browser-APIs verwenden, ohne dass für alle Nutzer die für alte Browser erforderlichen Polyfills erforderlich waren.
Ergebnisse
Nach der Optimierung haben wir in unseren Felddaten die Mittelwerte für die Woche vom 24. bis 30. Mai 2021 beobachtet:
| Name der Messwertgruppe | Core Web Vitals | Weitere Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Messwertname | LCP | FID | CLS | FCP | TBT | TTI | |
| Anteil der Nutzer gemäß den Core Web Vitals-Grenzwerten | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 18 % | 4 % | 3 % | 34 % | 17 % | 24 % | |
| Schwach | 24 % | 3 % | 4 % | 23 % | 34 % | 25 % | |
In den folgenden Grafiken sind die Änderungen der Werte der Leistungsmesswerte für Webseiten nach „Plattform“ dargestellt. Beachten Sie die beiden wichtigen Daten in den Diagrammen:
- 23. März 2021: Veröffentlichung der Iteration, bei der die Abschnitte der letzten Seite zu Svelte migriert wurden;
- 19. April 2021: Iteration mit zurückgegebenem SSR und geändertem Layout zur Korrektur von CLS-Rückgängen veröffentlicht.
Der Rückgang der Werte vom 1. bis zum 10. Mai ist auf die Maifeiertage in Russland zurückzuführen.
Die Ergebnisse, die mit „Plattform“ erzielt wurden, stimmen mit dem Anstieg der Messwerte im Chrome UX-Bericht (CrUX) überein.
Ein Vergleich der Werte für die durchschnittliche Sitzungsdauer von Nutzern eine Woche vor der Einführung der ersten Verbesserungen und eine Woche nach der Einführung zeigt ein Wachstum von 2,7 %. Außerdem ist in den meisten Bereichen der Seite eine deutliche Steigerung der Conversions zu verzeichnen. Insbesondere stieg die Anzahl der Conversions für die Mail.ru-E-Mail-App um 11, 6 % und die Anzahl der Conversions für den Nachrichtenbereich um 13,5%.
181 %
Anteil der Seiten mit guter CLS erhöht
2,7 %
Höhere durchschnittliche Sitzungsdauer
13,5 %
Steigerung der Conversion-Rate im Bereich „Nachrichten“
Das unerwartetste Ergebnis war eine Steigerung der Klickrate (Click-through-Rate, CTR) des Marketing-Banners um 17,4 %. Die Renderzeit wurde durch die Einführung von SSR- und Preloader-Tags deutlich reduziert.
Bei der Analyse der restlichen Abschnitte der Seite haben wir bei den meisten von ihnen eine deutliche Leistungssteigerung festgestellt. Sogar bei Abschnitten wie „Wetter“ und „Coronavirus“, die auf unserer Seite nicht im Mittelpunkt stehen, konnten wir eine Steigerung der Conversions um 9,6% bzw. 9,5 % verzeichnen.
Fazit
Die Leistungssteigerung ist eine Herausforderung, da die erforderlichen Arbeiten möglicherweise in die Länge gezogen werden. Sie sollten die Änderungen der Messwerte im Zeitverlauf regelmäßig beobachten und dafür sorgen, dass alle neuen Produktfunktionen keine Rückschritte bei den Core Web Vitals verursachen. Dazu überwachen wir Änderungen bei den Core Web Vitals in unserem Leistungsbudget.
Vor allem haben wir allen Mitgliedern unseres Produktteams die Bedeutung von Core Web Vitals vermittelt, von Managern und Designern bis hin zu Testern und QA-Experten. Jedes Teammitglied sollte mit den Leistungsmesswerten vertraut sein und die Möglichkeit haben, diese zu verbessern. Außerdem integrieren wir regelmäßig Ziele zur Leistungsoptimierung in unsere Geschäftsprozesse. Eine hochwertige Nutzererfahrung ist nur durch die gemeinsame Anstrengung aller Teammitglieder möglich.