Die Arbeit an der Verbesserung der Core Web Vitals auf der Startseite von Mail.ru in mehreren Monaten führte zu einem Anstieg des 75. Perzentils beim Cumulative Layout Shift (CLS) um 60 %. Dies führte zu einer Steigerung der durchschnittlichen Sitzungsdauer um 2,7% und der Conversion-Raten der Kernbereiche um mehr als 10%.
Wir haben angefangen
Mail.ru ist einer der führenden E-Mail-Dienste im russischsprachigen Internet und im Hinblick auf den Traffic zu den fünf führenden Websites in Russland. Mail.ru ist für viele Menschen eine wichtige Ressource. Es erhält mehrere hundert Millionen Besuche pro Monat und ist ein Portal, über das Menschen auf E-Mails, Nachrichten, soziale Medien, Internetrecherchen und mehr zugreifen können.
Da Mail.ru den Besuchern eine hohe Nutzerfreundlichkeit bieten wollte, begannen die Arbeiten, die Core Web Vitals zu verbessern. Bevor wir auf unsere Optimierungsstrategie eingehen, sollten wir zunächst einige technische Details der Mail.ru-Startseite notieren.
Das Projekt wurde schon lange mithilfe unserer internen Vorlagen-Engine Fest entwickelt, aber wir begannen 2019 mit der Migration zu Svelte 3.
Svelte implementiert Reaktivität auf eine Weise, die kein virtuelles DOM verwendet, wodurch es weniger ressourcenintensiv wird. Beim Ansatz von Svelte werden nicht verwendete Funktionen aus Produktions-Bundles entfernt, da der Code, der sie implementiert, nicht vom Compiler 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 Total Blocking Time (TBT) während des Seitenstarts zu reduzieren.
Leistungsmesswerte erfassen
Bevor Sie die Core Web Vitals optimieren, sollten Sie zuerst die Leistung analysieren. Vor den Core Web Vitals haben wir in unserem internen Dashboard zur Leistungsüberwachung andere Messwerte wie First Contentful Paint (FCP) erfasst.
Unser Script zur Messwerterfassung wurde geändert, um Core Web Vitals zu erfassen und sie zur Visualisierung in unser Leistungsdashboard zu übertragen. Gemäß den Empfehlungen von Google verwendet unser Skript die PerformanceObserver API, um Messwerte zu erhalten. Diese ist Teil der universellen Frontend-„Platform“ in Mail.ru.
Im Dashboard wurden für Nutzer die folgenden Messwerte angezeigt (durchschnittliche Werte für die Woche vom 15. bis zum 21. März 2021):
| Name der Messwertgruppe | Core Web Vitals | Andere Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Messwertname | LCP | FID | CLS | FCP | Noch offen | TTI | |
| Anteil der Nutzer unter Berücksichtigung der Core Web Vitals-Grenzwerte | good | 52 % | 92 % | 33 % | 35 % | 42 % | 43 % |
| verbesserungsbedürftig | 19 % | 5 % | 23 % | 38 % | 16 % | 25 % | |
| Schwach | 29 % | 3 % | 44 % | 27 % | 42 % | 32 % | |
Core Web Vitals verbessern
Es gibt zwar viele Empfehlungen zur Verbesserung von Core Web Vitals, aber jedes Projekt hat eigene Herausforderungen. Für die Mail.ru-Startseite wurden die folgenden Möglichkeiten identifiziert:
- Platzhalter für Anzeigenbanner verwenden, um den CLS zu reduzieren
- Durch serverseitiges Rendering (SSR) den Largest Contentful Paint (LCP) reduzieren
- Codeaufteilung, um den LCP und First Input Delay (FID) zu reduzieren.
Skelettes zur Verbesserung der CLS
CLS war einer der Feldmesswerte mit der schlechtesten Leistung auf der Mail.ru-Startseite. Eine anschließende Profilerstellung dieser Seite im Bereich Leistung der Chrome-Entwicklertools ergab, dass Werbung die Ursache des Problems war. Um die Stabilität des Layouts zu verbessern, beschloss unser Team, Platzhalter zu verwenden, um Platz für Anzeigen zu reservieren, bevor diese geladen werden.
Bei der Implementierung von Platzhaltern besteht der erste Schritt darin, die Abmessungen des Inhalts zu bestimmen, durch den sie ersetzt werden sollen. Glücklicherweise enthält die Desktop-Version der Mail.ru-Startseite streng dokumentierte Größen für Anzeigen. Nach Rücksprache mit dem Designteam wurden SVG-animierte UI-Skelette als Platzhalter verwendet, da sie die wahrgenommene Ladezeit der Inhalte reduzieren.
Die Rückkehr der SSR
Um den Übergang vom Fest zu Svelte zu erleichtern, haben wir das bestehende Projekt inkrementell umgeschrieben, anstatt von vorne zu beginnen. Im März 2021 hatten wir den Großteil des Frontends zu Svelte migriert und SSR schließlich in unsere Produktionsanwendung integriert, nachdem wir Probleme mit der Backend-Leistung erkannt und behoben hatten.
Nach der Implementierung der SSR entdeckte das Team die Ursache für die CLS-Regression, die anfangs unbemerkt blieb: Der Nachrichtenbereich wurde beim Rendern des ersten Inhalts auf der Seite nicht eingefügt. Zwischen dem ersten Malen 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 Grundgerüsts der Anzeige, wodurch sich der CLS-Wert verschlechterte.
Obwohl in den Entwicklertools von Chrome Layout Shift-Ereignisse angezeigt wurden, konnten wir den Grund dafür zunächst nicht finden. Obwohl die SSR selbst nicht das Problem war, half sie später, die Lösung zu finden. Die Korrektur des für die Painting-Verzögerung verantwortlichen Codes verbesserte die Layoutstabilität der News-Komponente.
Ein weiterer Effekt, den SSR auf den CLS haben kann, ist die Bewegung der Komponenten vor und nach der Hydration, was zu weiteren Layoutverschiebungen führen kann. Wir haben dieses Problem insbesondere in der mobilen Version festgestellt und es erforderte besondere Aufmerksamkeit auf die Auszeichnung der hydratisierten Komponenten. Eine gute Lösung für dieses Problem war es, möglichst viel Anzeigelogik von JavaScript in CSS zu übertragen.
Codeaufteilung und nicht verwendete Polyfills
Um die wahrgenommene Seitenladegeschwindigkeit zu verbessern, mussten die LCP- und FID-Werte gesenkt werden. Eine Möglichkeit dafür ist die Codeaufteilung. Zusätzlich zur Mail.ru-Startseite selbst entwickelt unser Team ein Widget für die Portalnavigation. Sie ist derzeit in vielen Projekten unseres Unternehmens integriert.
Aus historischen Gründen wird das Widget ganz am Anfang der Seite als Skript zum synchronen Laden eingefügt. Der Anteil von Polyfills in diesem Skript ist im Laufe der Zeit gestiegen. Um die negativen Auswirkungen des Ladens dieser Polyfills auf die Leistung zu begrenzen, haben wir sowohl für moderne als auch für ältere Browser Codeaufteilung 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 modern genug waren, um unsere Anforderungen zu erfüllen. Um dieses Problem zu beheben, verwendet Mail.ru ein internes Tool, mit dem moderne Browserversionen im Back-End identifiziert werden, und kann sich entsprechend an diese Browser anpassen.
Sobald die Browser im Back-End identifiziert werden konnten, haben wir die Codeaufteilung für moderne und ältere Browser implementiert. Dadurch ließ sich die Größe des synchron geladenen JavaScript-Widgets für moderne Browser um 43,3% reduzieren. Diese Vorgehensweise wurde auch auf einige andere Portalskripts angewendet.
Die Codeaufteilung verbessert nicht nur die Paketgröße, sondern verbessert auch die Erfahrung der Entwicklerteams und wirkt sich positiv auf die Core Web Vitals aus. Nur 3,5% unserer Nutzer verwenden ältere Browser, und dieser Anteil befindet sich im Abwärtstrend.Durch die Implementierung der Codeaufteilung konnten unsere Entwickler die neuesten Browser-APIs nutzen, ohne die für ältere Browser erforderliche Polyfill-Bloat für alle Nutzer zu nutzen.
Ergebnisse
Nach der Optimierung haben wir in unseren Felddaten die Mittelwerte für die Woche vom 24. bis zum 30. Mai 2021 beobachtet:
| Name der Messwertgruppe | Core Web Vitals | Andere Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Messwertname | LCP | FID | CLS | FCP | Noch offen | TTI | |
| Anteil der Nutzer unter Berücksichtigung der Core Web Vitals-Grenzwerte | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| verbesserungsbedürftig | 18 % | 4 % | 3 % | 34 % | 17 % | 24 % | |
| Schwach | 24 % | 3 % | 4 % | 23 % | 34 % | 25 % | |
In den Grafiken unten sehen Sie Änderungen der Messwerte für die Leistung von Webseiten nach „Plattform“. Beachten Sie die beiden wichtigen Daten in den Diagrammen:
- 23. März 2021: Die Iteration mit den letzten Seitenabschnitten wurde zu Svelte migriert.
- 19. April 2021: Iteration mit zurückgegebener SSR und geändertem Layout zur Korrektur von CLS-Regressionen.
Der Rückgang der Werte zwischen dem 1. Mai und dem 10. Mai ist auf die Feiertage im Mai in Russland zurückzuführen.
Die Ergebnisse, die Sie über „Plattform“ erhalten, orientiert sich an dem Anstieg der Messwerte im UX-Bericht für Chrome (CrUX).
Ein Vergleich der durchschnittlichen Werte für die Nutzersitzungsdauer eine Woche vor der Einführung der ersten Verbesserungen und eine Woche nach der Einführung zeigt einen Anstieg von 2,7 %. Darüber hinaus ist in den meisten Bereichen der Seite ein deutlicher Anstieg der Conversions zu beobachten. So stiegen die Conversions für die E-Mail-App Mail.ru um 11, 6 % und die Conversions für den Nachrichtenbereich um 13,5%.
181%
Steigerung des Anteils an fehlerfreiem CLS-Grenzwert
2,7 %
Längere durchschnittliche Sitzungsdauer
13,5 %
höhere Conversion-Rate für den Nachrichtenbereich
Das unerwartetste Ergebnis war eine Steigerung der Klickrate (Click-through-Rate, CTR) des Marketingbanners um 17,4 %. Durch die Einführung von SSRs und Tags für das Vorabladen konnte die Renderingzeit deutlich verkürzt werden.
Bei einer Analyse der restlichen Seitenbereiche haben wir eine erhebliche Leistungsverbesserung in den meisten Bereichen festgestellt. Selbst für Bereiche wie „Wetter“ und „Coronavirus“, die auf unserer Seite nicht wichtig sind, erzielen wir eine Steigerung der Conversions um 9,6% bzw. 9,5 %.
Fazit
Die Leistungsverbesserung ist eine Herausforderung, da die damit verbundene Arbeit unter Umständen länger dauert. Sie sollten regelmäßig Änderungen der Messwerte im Zeitverlauf beobachten und darauf achten, dass keine neuen Produktfunktionen zu Regressionen in den Core Web Vitals führen. Dazu beobachten wir Änderungen bei den Core Web Vitals in unserem Leistungsbudget.
Vor allem haben wir die Bedeutung von Core Web Vitals für alle Mitglieder unseres Produktteams betont, angefangen bei Managern und Designern bis hin zu Testern und QA. Jedes Teammitglied sollte die Leistungsmesswerte kennen und in der Lage sein, diese zu verbessern. Außerdem binden wir regelmäßig Ziele zur Leistungsoptimierung in unsere Geschäftsprozesse ein. Die erfolgreiche Bereitstellung einer qualitativ hochwertigen User Experience ist nur durch die gemeinsame Anstrengung aller Teammitglieder möglich.