So erreichte The Economic Times die Core Web Vitals-Grenzwerte und erreichte eine um 43% bessere Absprungrate

Durch die Optimierung der Core Web Vitals auf der Website von The Economic Times konnte die Nutzerfreundlichkeit erheblich verbessert und die Absprungrate auf der gesamten Website erheblich gesenkt werden.

Anshu Sharma
Anshu Sharma
Prashant Mishra
Prashant Mishra
Sumit Gugnani
Sumit Gugnani

Die Internetgeschwindigkeit wird immer besser und Nutzer erwarten, dass Websites schneller reagieren und sich schneller als je zuvor verhalten. Die Economy Times hat monatlich mehr als 45 Millionen aktive Nutzer. Durch die Optimierung im Hinblick auf Core Web Vitals in der gesamten Domain auf AMP- und Nicht-AMP-Seiten konnten wir die Absprungraten deutlich senken und die Lesequalität verbessern.

Messen der Auswirkungen

Dabei haben wir uns auf Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS) konzentriert, da diese vor allem im Hinblick auf die Nutzerfreundlichkeit beim Lesen am wichtigsten sind. Nach der Implementierung verschiedener Leistungskorrekturen wie unten beschrieben konnte The Economic Times innerhalb weniger Monate die Messwerte des Berichts zu Chrome-Nutzertests (CrUX-Bericht) deutlich verbessern.

Insgesamt verbesserte sich der CLS-Wert um 250% von 0,25 auf 0,09. Insgesamt verbesserte sich der LCP um 80% von 4,5 Sekunden auf 2,5 Sekunden.

Außerdem wurden die LCP-Werte im Bereich „Langsam“ zwischen Oktober 2020 und Juli 2021 um 33% gesenkt:

LCP-Verteilungen nach Monat gruppiert ab Oktober 2020 bis Juli 2021. Die Menge der als „Langsam“ eingestuften LCP-Werte wurde von 15,03% auf 10,08 % gesenkt.

Außerdem wurden die CLS-Werte im Bereich „Langsam“ um 65 % gesenkt und die CLS-Werte im Bereich „Gut“ um 20% im selben Zeitraum:

CLS-Verteilungen nach Monat gruppiert von Oktober 2020 bis Juli 2021. Die Menge der als „Schlecht“ klassifizierten CLS-Werte wurde von 25,92% auf 9 % gesenkt und die Menge der als „Gut“ eingestuften CLS-Werte von 62,62% auf 76,5 % erhöht.

Das Ergebnis war, dass The Economic Times – die bislang nicht die Core Web Vitals-Grenzwerte nicht erfüllte – nun die Core Web Vitals-Grenzwerte für den gesamten Ursprung erreicht und die Absprungraten insgesamt um 43% reduzierte.

Eine Vorher-Nachher-Animation der Artikelseite der Economic Times.

Was ist LCP und wie haben wir ihn verbessert?

Der wichtigste Punkt ist die Verbesserung der Nutzererfahrung und das Erkennen der Ladegeschwindigkeit. Leistungsmesswerte wie First Contentful Paint (FCP) erfassen nur den ersten Eindruck des Seitenaufbaus. LCP erfasst hingegen die Renderingzeit des größten Bild-, Text- oder Videoabschnitts, der für den Nutzer sichtbar ist.

Neben dem Wechsel zu einem schnelleren DNS-Anbieter und der Optimierung von Bildern stellen wir Ihnen hier einige der Techniken vor, die wir zur Verbesserung des LCP angewendet haben.

Kritische Anfragen zuerst

Da bei allen modernen Browsern die Anzahl gleichzeitiger Anfragen begrenzt ist, müssen Entwickler zuerst die kritischen Inhalte laden. Um eine komplexe Webseite zu laden, müssen wir Assets wie Kopfzeilenelemente, CSS, JavaScript-Ressourcen, Hero-Image, Artikeltext, Kommentare, andere relevante Nachrichten, Fußzeile und Anzeigen herunterladen. Wir haben ausgewertet, welche Elemente für LCP erforderlich sind, und haben angegeben, dass diese Elemente zuerst geladen werden sollten, um den LCP zu verbessern. Außerdem haben wir die Aufrufe verschoben, die nicht Teil des anfänglichen Seiten-Renderings waren.

Textdarstellung

Wir haben mit der Property font-display experimentiert, da sich dies sowohl auf den LCP als auch auf CLS auswirkt. Wir haben font-display: auto; ausprobiert und dann zu font-display: swap; gewechselt. Dadurch wird der Text zuerst in der am besten passenden und verfügbaren Schriftart angezeigt und nach dem Download in die Schriftart geändert. Dies führte dazu, dass unser Text schnell gerendert wurde, unabhängig von der Netzwerkgeschwindigkeit.

Bessere Komprimierung

Brotli ist ein von Google entwickelter alternativer Komprimierungsalgorithmus zu Gzip und Deflate. Wir haben unsere Schriftarten und Assets ersetzt und die Serverkomprimierung von Gzip in Brotli geändert, um den Platzbedarf zu verringern:

  • JavaScript-Dateien sind 15% kleiner als Gzip.
  • HTML-Dateien sind 18% kleiner als Gzip.
  • CSS- und Schriftartdateien sind 17% kleiner als Gzip.

Vorabverbindung zu Drittanbieterdomains

preconnect sollte mit Vorsicht verwendet werden, da es dennoch wertvolle CPU-Zeit in Anspruch nehmen und andere wichtige Ressourcen verzögern kann, insbesondere bei sicheren Verbindungen.

Falls jedoch bekannt ist, dass eine Ressource in einer Drittanbieterdomain abgerufen wird, ist preconnect fehlerfrei. Wenn der Fehler nur gelegentlich auf Websites mit vielen Zugriffen auftritt, kann preconnect unnötige TCP- und TLS-Vorgänge auslösen. Daher eignete sich dns-prefetch besser für Ressourcen von Drittanbietern wie soziale Medien, Analysen usw., um DNS-Lookups im Voraus durchzuführen.

Code in Blöcke aufteilen

Im Kopfbereich der Website haben wir nur die Ressourcen geladen, die entweder einen wesentlichen Teil der Geschäftslogik enthalten oder für das Rendern „above the fold“ (ohne Scrollen sichtbar) entscheidend waren. Außerdem teilen wir unseren Code mit der Code-Aufteilung in Teile auf. Dadurch konnten wir den LCP-Wert weiter verbessern.

Besseres Caching

Für alle Frontend-Routen haben wir die Redis hinzugefügt, die Vorlagen aus dem Cache bereitstellt. Dadurch wird die Rechenzeit auf dem Server reduziert und die gesamte UI für jede Anfrage erstellt. Dadurch wird der LCP-Wert bei nachfolgenden Anfragen verringert.

LCP-Ziele und Erfolge zusammenfassen

Vor Beginn des Optimierungsprojekts ermittelte das Team den LCP-Wert auf 4, 5 Sekunden (für das 75.Perzentil der Nutzer, basierend auf den Daten aus dem Bericht zur Nutzererfahrung in Chrome). Nach der Optimierung wurde sie auf 2, 5 Sekunden reduziert.

LCP-Verteilungen zwischen September 2020 und Juni 2021. Insgesamt ergab das 75.Perzentil der LCP-Werte im Bericht zur Nutzererfahrung in Chrome einen Rückgang von 8, 97% bei den LCP-Werten mit dem Status „Langsam“. Die Gesamtverringerung der LCP-Zeit beim 75.Perzentil betrug 200 Millisekunden, wobei 77,63% der LCP-Werte in den Bereich „Gut“ lagen.
Quelle: CrUX Report of The Economic Times Gesamt-LCP

Was ist CLS und wie haben wir es verbessert?

Sind Ihnen beim Surfen auf einer Website unerwartete Verschiebungen von Seiteninhalten aufgefallen? Ein Grund dafür ist das asynchrone Laden von Medien (Bilder, Videos, Anzeigen usw.) auf der Seite, die unbekannte Abmessungen haben. Sobald Medienressourcen geladen werden, verschieben sie das Layout der Seite.

Wir gehen auf die Maßnahmen ein, die wir zur Verbesserung des CLS ergriffen haben, auf der Website der Economic Times.

Platzhalter verwenden

Wir haben einen Platzhalter mit benutzerdefinierten Stilen für Anzeigenblöcke und Medienelemente mit bekannten Abmessungen verwendet, um Layoutverschiebungen beim Laden und Rendern von Seitenanzeigen in der Anzeigenbibliothek zu vermeiden. Dadurch werden Layoutverschiebungen vermieden, da Platz für die Anzeige reserviert wird.

Ein Vergleich der Website der Economic Times auf einem Smartphone. Auf der linken Seite ist für das Hero-Image des Artikels ein grauer Platzhalter reserviert. Rechts wird der Platzhalter durch das geladene Bild ersetzt.

Definierte Containerdimensionen

Wir haben explizite Abmessungen für alle Bilder und Container angegeben, damit die Browser-Engine Breite und Höhe der DOM-Elemente nicht berechnen muss, sobald sie verfügbar sind. Dadurch wurden unnötige Layoutverschiebungen und zusätzliche Malarbeiten vermieden.

CLS-Ziele und Erfolge zusammenfassen

Vor Beginn des Optimierungsprojekts legte das Team einen CLS-Wert von 0, 25 fest. Wir konnten ihn um 90% auf 0,09 senken.

CLS-Verteilungen im Bericht zur Nutzererfahrung in Chrome. 76% der CLS-Werte sind „Gut“, 15% sind „Ausreichend“ und 9% sind „Schlecht“. Für das 75.Perzentil der Nutzererfahrung auf der Website der Economic Times ergab sich eine CLS von 0,09.

Was ist First Input Delay (FID) und wie haben wir es verbessert?

First Input Delay ist der Messwert, der die Reaktionsfähigkeit einer Website auf Nutzereingaben misst. Die Hauptursache für eine schlechte FID-Wertung ist eine aufwendige JavaScript-Arbeit, die den Hauptthread des Browsers hält, was zu Verzögerungen von Nutzerinteraktionen führen kann. Wir haben FID in mehreren Bereichen verbessert.

Lange JavaScript-Aufgaben aufteilen

Lange Aufgaben sind Aufgaben, die mindestens 50 Millisekunden dauern. Lange Aufgaben belegen den Hauptthread des Browsers und verhindern, dass dieser auf Nutzereingaben reagiert. Lang andauernde Aufgaben haben wir nach Möglichkeit auf Nutzeranfrage in kleinere Aufgaben aufgeteilt, um die JavaScript-Blut zu reduzieren.

Die CPU-Zeit aufgeschlüsselt nach Aktivitätstyp im Leistungsbereich der Chrome-Entwicklertools. Das Laden von Ressourcen wurden 143 Millisekunden geplant. 4.553 Millisekunden wurden für JavaScript aufgewendet. Es wurden 961 Millisekunden für das Rendern aufgewendet. 191 Millisekunden wurden für den Streichvorgang aufgewendet. 1.488 Millisekunden für Systemaufgaben mit 3.877 Millisekunden Inaktivität Der gesamte Zeitrahmen betrug 11.212 Millisekunden.

Nicht verwendetes JavaScript aufschieben

Wir haben Seiteninhalte gegenüber Skripts von Drittanbietern wie Analytics priorisiert, damit die Seite reaktionsschneller bleibt. Bei einigen Bibliotheken gelten jedoch gewisse Einschränkungen, da sie in das Dokument <head> geladen werden müssen, um den Kaufprozess genau nachverfolgen zu können.

Polyfills reduzieren

Wir haben unsere Abhängigkeit von bestimmten Polyfills und Bibliotheken reduziert, da Browser moderne APIs unterstützen und weniger Nutzer ältere Browser wie Internet Explorer verwenden.

Lazy Loading von Anzeigen

Durch Lazy Loading von Anzeigen „below the fold“ (mit Scrollen sichtbar) wurde die Blockierung des Hauptthreads reduziert und der FID-Wert verbessert.

Ziele und Erfolge von FID

Mithilfe von Routinetests konnten wir unsere FID heute von 200 ms auf unter 50 ms reduzieren.

FID-Verteilungen im Bericht zur Nutzererfahrung in Chrome. 86% der CLS-Werte sind „Gut“, 10% sind „Ausreichend“ und 4% sind „Schlecht“. Beim 75. Perzentil der Nutzererfahrung auf der Website der Economic Times lag die FID bei 44 Millisekunden.

Regressionen verhindern

Die Economics Times plant, automatisierte Leistungsprüfungen in der Produktion einzuführen, um Leistungseinbußen bei der Seitenleistung zu vermeiden. Das Unternehmen plant, Lighthouse-CI zur Automatisierung von Labortests zu evaluieren, die Regressionen in der Produktion verhindern können.