Innerhalb weniger Monate konnte die führende Nachrichtenwebsite im Vereinigten Königreich den CLS-Wert des 75. Perzentils um 250% von 0,25 auf 0,1 verbessern.
Herausforderungen bei der visuellen Stabilität
Layout Shifts können sehr störend sein. Bei der Telegraph Media Group (TMG) ist die visuelle Stabilität besonders wichtig, da die Leser hauptsächlich unsere Anwendungen nutzen, um Nachrichten zu lesen. Wenn sich das Layout beim Lesen eines Artikels ändert, verliert der Leser wahrscheinlich seine Position. 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 unterbrechen, insbesondere wenn Bereiche Ihrer Anwendung asynchron geladen und der Seite dynamisch hinzugefügt werden.
Bei TMG haben mehrere Teams, die clientseitig Code beitragen:
- Core Engineering: Implementieren von Drittanbieterlösungen zur Unterstützung von Bereichen wie Inhaltsempfehlungen und -kommentare.
- Marketing: A/B-Tests ausführen, um zu bewerten, wie unsere Leser mit neuen Funktionen oder Änderungen interagieren
- Werbung: Anzeigenanfragen und Pre-Bidding verwalten
- Redaktionelle Anforderungen Einbetten von Code in Artikel wie Tweets oder Videos sowie in benutzerdefinierte Widgets (z. B. den COVID-19-Fall-Tracker).
Es kann schwierig sein, dafür zu sorgen, dass keines dieser Teams das Layout der Seite ruckelt. Mithilfe des Messwerts Cumulative Layout Shift, um zu messen, wie oft es für unsere Leser auftritt, konnten die Teams mehr über die tatsächliche Nutzererfahrung erfahren und ein klares Ziel verfolgen. Dies führte dazu, dass sich der CLS-Wert unseres 75. Perzentils von 0,25 auf 0,1 verbesserte und der übergebene Bucket von 57% auf 72 % anstieg.
250%
CLS-Verbesserung am 75. Perzentil
15 %
Mehr Nutzer mit gutem CLS-Wert
Wir haben angefangen
Mithilfe von CrUX-Dashboards konnten wir feststellen, dass sich unsere Seiten stärker als gewünscht verschieben.
Im Idealfall sollten mindestens 75% unserer Leser eine „gute“ Erfahrung haben, also begannen wir damit, die Ursachen für die Layout-Instabilität zu identifizieren.
So haben wir die Layoutverschiebungen gemessen
Wir haben eine Kombination aus Chrome-Entwicklertools und WebPageTest verwendet, um die Ursache für die Layoutverschiebung zu ermitteln. In den Entwicklertools haben wir den Abschnitt Erfahrung des Tabs Leistung verwendet, um einzelne Instanzen mit Layoutverschiebungen hervorzuheben und zu zeigen, wie sie zur Gesamtpunktzahl beigetragen haben.
WebPageTest hebt hilfreich hervor, an welcher Stelle auf der Zeitachse die Layoutverschiebung erfolgt, wenn „Layout Shifts hervorheben“ ausgewählt ist.
Nachdem wir jede Schicht in unseren meistbesuchten Vorlagen überprüft hatten, haben wir eine Liste von Verbesserungsvorschlägen erstellt.
Layout Shifts reduzieren
Wir haben uns auf vier Bereiche konzentriert, in denen wir Layoutverschiebungen reduzieren können: - Anzeigen - Bilder - Überschriften - Einbettungen
Werbung
Die Anzeigen werden nach dem anfänglichen Paint über JavaScript geladen. Einige der Container, in die sie geladen wurden, hatten keine reservierte Höhe.
Auch wenn die genaue Höhe nicht bekannt ist, können wir Platz reservieren, indem wir die am häufigsten in der Anzeigenfläche geladene Anzeigengröße verwenden.
In einigen Fällen hatten wir die durchschnittliche Höhe der Anzeige falsch eingeschätzt. Bei Tablet-Lesern wurde die Anzeigenfläche minimiert.
Wir haben uns die Anzeigenfläche noch einmal angesehen und die Höhe an die am häufigsten verwendete Größe angepasst.
Bilder
Viele Bilder auf der Website sind Lazy Loading und haben Platz für sie.
Für die Inline-Bilder oben in den Artikeln wurde jedoch kein Platz im Container reserviert. Außerdem waren den Tags keine Breiten- und Höhenattribute zugeordnet. Dadurch hat sich das Layout beim Laden verschoben.
Allein das Hinzufügen der Attribute für Breite und Höhe zu den Bildern sorgte dafür, dass das Layout nicht verschoben wurde.
Header
Der Header befand sich unter dem Inhalt im Markup und wurde mithilfe von CSS oben positioniert. Ursprünglich sollte das Laden der Inhalte vor der Navigation priorisiert werden. Dadurch hat sich die Seite jedoch kurzzeitig verändert.
Durch das Verschieben des Headers an den Anfang des Markups konnte die Seite ohne diese Verschiebung gerendert werden.
Embeds API
Einige der häufig verwendeten Einbettungen haben ein festgelegtes Seitenverhältnis. Zum Beispiel YouTube-Videos. Während der Player lädt, rufen wir das Thumbnail von YouTube ab und verwenden es als Platzhalter, während das Video geladen wird.
Messen der Auswirkungen
Mit den zu Beginn des Artikels erwähnten Tools konnten wir die Auswirkungen auf Featureebene ganz einfach messen. Wir wollten jedoch CLS sowohl auf Vorlagenebene als auch auf Websiteebene messen. Wir haben SpeedCurve synthetisch verwendet, um Änderungen in der Vorproduktion und in der Produktion zu validieren.
Wir können die Ergebnisse dann in unseren von mPulse bereitgestellten RUM-Daten validieren, sobald der Code die Produktion erreicht hat.
Die Überprüfung der RUM-Daten gibt uns eine gute Gewissheit, dass sich die von uns vorgenommenen Änderungen positiv auf unsere Leser auswirken.
Die endgültigen Zahlen, die wir uns angesehen haben, beziehen sich auf die RUM-Daten, die Google erhebt. Dies ist inzwischen besonders relevant, da sie sich bald auf das Ranking auswirken werden. Zuerst haben wir den UX-Bericht für Chrome verwendet, sowohl für die monatlichen Daten auf Ursprungsebene, die über das CrUX-Dashboard verfügbar sind, als auch für die Abfrage von BigQuery, um frühere P75-Daten abzurufen. So konnten wir leicht feststellen, dass für den gesamten von CrUX gemessenen Traffic der CLS-Wert unseres 75. Perzentils um 250% von 0,25 auf 0,1 verbessert wurde und der Prozentsatz des übergebenen Buckets von 57% auf 72%gestiegen ist.
Darüber hinaus konnten wir die Chrome UX Report API nutzen und einige interne Dashboards erstellen, die in Vorlagen unterteilt sind.
CLS-Regressionen vermeiden
Ein wichtiger Aspekt bei Leistungsverbesserungen ist die Vermeidung von Regressionen. Wir haben einige grundlegende Leistungsbudgets für unsere wichtigsten Messwerte eingerichtet und darin CLS berücksichtigt.
Wenn der Test das Budget überschreitet, wird eine Nachricht an einen Slack-Kanal gesendet, damit wir der Ursache auf den Grund gehen können. Wir haben auch wöchentliche Berichte eingerichtet, sodass wir wissen, welche Änderungen sich negativ auf das Budget ausgewirkt haben, selbst wenn die Vorlagen im Budget bleiben.
Außerdem planen wir, unsere Budgets auf die Verwendung von RUM-Daten und synthetischen Daten auszuweiten. Wir verwenden mPulse, um sowohl statische Warnungen als auch möglicherweise Anomalieerkennung festzulegen, um uns auf ungewöhnliche Änderungen aufmerksam zu machen.
Für uns ist es wichtig, neue Funktionen unter Berücksichtigung des CLS zu entwickeln. Viele der von mir erwähnten Änderungen wurden nach der Veröffentlichung für unsere Leser behoben. Die Layoutstabilität wird auch in Zukunft beim Lösungsdesign neuer Funktionen berücksichtigt, um unerwartete Layoutverschiebungen von Anfang an zu vermeiden.
Fazit
Die Verbesserungen, die wir bisher vorgenommen haben, waren recht einfach umzusetzen und hatten erhebliche Auswirkungen. Viele der in diesem Artikel beschriebenen Änderungen haben nicht viel Zeit in Anspruch genommen und sie wurden auf alle am häufigsten verwendeten Vorlagen angewendet, was bedeutet, dass sie einen weitreichenden positiven Einfluss auf unsere Leser hatten.
Es gibt immer noch Bereiche der Website, die verbessert werden müssen. Wir suchen nach Möglichkeiten, die clientseitige Logik serverseitig besser nutzen zu können, um den CLS noch weiter zu verbessern. Wir werden unsere Messwerte weiterhin im Blick behalten und beobachten, um sie kontinuierlich zu verbessern und unseren Lesern das bestmögliche Nutzererlebnis zu bieten.