Innerhalb weniger Monate konnte die führende Nachrichtenwebsite im Vereinigten Königreich den CLS im 75. Perzentil um 250% von 0,25 auf 0,1 verbessern.
Die Herausforderung der visuellen Stabilität
Layoutänderungen können sehr störend sein. Bei der Telegraph Media Group (TMG) ist die visuelle Stabilität besonders wichtig, da Leser vorwiegend unsere Apps verwenden, um sich die Nachrichten anzusehen. Wenn sich das Layout beim Lesen eines Artikels ändert, verliert der Leser wahrscheinlich seine Leseposition. Das kann frustrierend und ablenkend sein.
Aus technischer Sicht kann es schwierig sein, dafür zu sorgen, dass sich die Seiten nicht verschieben und den Leser nicht unterbrechen, insbesondere wenn Bereiche Ihrer Anwendung asynchron geladen und der Seite dynamisch hinzugefügt werden.
Bei TMG gibt es mehrere Teams, die clientseitig Code beitragen:
- Kernentwicklung Implementierung von Drittanbieterlösungen für Bereiche wie Inhaltsempfehlungen und Kommentare
- Marketing. A/B-Tests durchführen, um zu beurteilen, wie unsere Leser mit neuen Funktionen oder Änderungen interagieren.
- Werbung Anzeigenanfragen und Pre-Bidding für Anzeigen verwalten
- Redaktionelle Anforderungen Einbetten von Code in Artikeln wie Tweets oder Videos sowie benutzerdefinierte Widgets (z. B. Corona-Tracker)
Es kann schwierig sein, dafür zu sorgen, dass keines dieser Teams das Layout der Seite beeinträchtigt. Mit dem Messwert Cumulative Layout Shift konnten die Teams messen, wie oft das Problem für unsere Leser auftritt. So erhielten sie einen besseren Einblick in die tatsächliche Nutzererfahrung und ein klares Ziel, das sie anstreben konnten. Dadurch konnte der CLS im 75. Perzentil von 0,25 auf 0,1 verbessert und der Bucket für bestandene Tests von 57% auf 72 % erhöht werden.
250 %
CLS-Verbesserung beim 75. Perzentil
15 %
Mehr Nutzer mit gutem CLS-Wert
Der Anfang
Mithilfe der CrUX-Dashboards konnten wir feststellen, dass sich unsere Seiten mehr als gewünscht verschoben.
Idealerweise sollten mindestens 75% unserer Leser eine „gute“ Erfahrung machen. Deshalb haben wir uns daran gemacht, die Ursachen für die Layoutinstabilität zu ermitteln.
So haben wir die Layoutänderungen gemessen
Wir haben eine Kombination aus Chrome DevTools und WebPageTest verwendet, um herauszufinden, was das Layout verschoben hat. In DevTools haben wir auf dem Tab Leistung im Bereich Nutzerfreundlichkeit einzelne Instanzen des sich ändernden Layouts hervorgehoben und gezeigt, wie sie zur Gesamtbewertung beigetragen haben.
In WebPageTest wird die Stelle, an der die Layoutänderung auftritt, in der Zeitachse hervorgehoben, wenn „Layoutänderungen hervorheben“ ausgewählt ist.
Nachdem wir alle Schichten in unseren meistbesuchten Vorlagen überprüft hatten, haben wir eine Liste mit Ideen zusammengestellt, wie wir sie verbessern könnten.
Layoutverschiebungen reduzieren
Wir haben uns auf vier Bereiche konzentriert, in denen wir Layoutverschiebungen reduzieren konnten: - Anzeigen - Bilder - Überschriften - Einbettungen
Anzeigen
Die Anzeigen werden nach der ersten Darstellung über JavaScript geladen. Einige der geladenen Container hatten keine reservierte Höhe.
Auch wenn wir die genaue Höhe nicht kennen, können wir Platz reservieren, indem wir die gängigste Anzeigengröße verwenden, die im Slot geladen ist.
In einigen Fällen haben wir die durchschnittliche Höhe der Anzeige falsch eingeschätzt. Bei Tablet-Lesegeräten wurde der Steckplatz minimiert.
Wir haben den Slot überarbeitet und die Höhe so angepasst, dass die gängigste Größe verwendet wird.
Bilder
Viele der Bilder auf der Website werden mit verzögertem Laden angezeigt und der dafür erforderliche Platz ist reserviert.
Für die Inline-Bilder oben in den Artikeln war jedoch kein Platz im Container reserviert und die Tags hatten keine Breite- und Höhe-Attribute. Dadurch hat sich das Layout beim Laden verschoben.
Durch das einfache Hinzufügen der Attribute „width“ und „height“ zu den Bildern konnte das Layout nicht verschoben werden.
Header
Der Header befand sich im Markup unter dem Inhalt und wurde mit CSS oben positioniert. Ursprünglich sollte das Laden der Inhalte vor der Navigation priorisiert werden, was jedoch dazu führte, dass sich die Seite kurzzeitig verschob.
Durch das Verschieben der Überschrift an den Anfang des Markups konnte die Seite ohne diese Verschiebung gerendert werden.
Embeds API
Einige der häufig verwendeten Einbettungen haben ein definiertes Seitenverhältnis. Beispielsweise YouTube-Videos. Während der Player geladen wird, wird das Thumbnail von YouTube abgerufen und als Platzhalter verwendet, bis das Video geladen ist.
Auswirkungen messen
Mit den Tools, die wir zu Beginn des Artikels erwähnt haben, konnten wir die Auswirkungen auf Funktionsebene ganz einfach messen. Wir wollten den CLS jedoch sowohl auf Vorlagen- als auch auf Websiteebene messen. Wir haben SpeedCurve verwendet, um Änderungen sowohl in der Vorproduktion als auch in der Produktion zu validieren.
Sobald der Code in der Produktion ist, können wir die Ergebnisse in unseren RUM-Daten (von mPulse bereitgestellt) validieren.
Die Überprüfung der RUM-Daten gibt uns eine gute Sicherheit, dass die von uns vorgenommenen Änderungen sich positiv auf unsere Leser auswirken.
Die endgültigen Zahlen beziehen sich auf die von Google erhobenen RUM-Daten. Das ist jetzt besonders relevant, da sie bald einen Einfluss auf das Seitenranking haben werden. Zuerst haben wir den Chrome UX-Bericht verwendet, sowohl die monatlichen Daten auf Ursprungsebene, die über das CrUX-Dashboard verfügbar sind, als auch BigQuery-Abfragen, um Verlaufsdaten für den P75 abzurufen. So konnten wir ganz einfach sehen, dass sich für den gesamten mit CrUX gemessenen Traffic der CLS-Wert des 75. Perzentil um 250% von 0,25 auf 0,1 verbessert und der Bucket für erfolgreiche Seiten von 57% auf 72%gestiegen ist.
Außerdem konnten wir die Chrome UX Report API verwenden und einige interne Dashboards in Vorlagen unterteilen.
CLS-Rückgänge vermeiden
Ein wichtiger Aspekt bei der Leistungsverbesserung ist die Vermeidung von Rückschritten. Wir haben einige grundlegende Leistungsbudgets für unsere wichtigsten Messwerte eingerichtet und CLS darin aufgenommen.
Wenn das Budget überschritten wird, wird eine Nachricht an einen Slack-Kanal gesendet, damit wir der Ursache auf den Grund gehen können. Außerdem haben wir wöchentliche Berichte eingerichtet, damit wir auch dann über Änderungen informiert sind, wenn die Vorlagen im Budget bleiben, aber eine negative Auswirkung haben.
Außerdem planen wir, unsere Budgets zu erweitern, um sowohl RUM- als auch synthetische Daten zu verwenden. Mit mPulse können wir sowohl statische Benachrichtigungen als auch Anomalieerkennungen einrichten, die uns auf ungewöhnliche Änderungen aufmerksam machen.
Bei der Entwicklung neuer Funktionen ist es wichtig, den CLS im Hinterkopf zu behalten. Viele der von mir erwähnten Änderungen mussten wir korrigieren, nachdem sie für unsere Leser veröffentlicht wurden. Die Layoutstabilität wird beim Design der Lösung für jede neue Funktion berücksichtigt, damit wir von Anfang an unerwartete Layoutänderungen vermeiden können.
Fazit
Die bisher vorgenommenen Verbesserungen waren recht einfach umzusetzen und haben sich deutlich ausgewirkt. Viele der in diesem Artikel beschriebenen Änderungen konnten schnell umgesetzt werden und wurden auf alle am häufigsten verwendeten Vorlagen angewendet. Das hat sich positiv auf viele unserer Leser ausgewirkt.
Es gibt jedoch noch Bereiche der Website, die wir verbessern müssen. Wir prüfen derzeit, wie wir mehr clientseitige Logik serverseitig ausführen können, um den CLS weiter zu verbessern. Wir werden unsere Messwerte weiter beobachten und analysieren, um sie kontinuierlich zu verbessern und unseren Lesern die bestmögliche Nutzererfahrung zu bieten.