Eine Fallstudie zu den Änderungen, die das YouTube Web-Team vorgenommen hat, um die Leistung zu verbessern, die Erfolgsquoten für die Core Web Vitals zu steigern und wichtige Geschäftsmesswerte zu steigern.
Das Chrome-Team spricht oft von einem besseren Web, aber was bedeutet das? Websites sollten schnell und zugänglich sein und Gerätefunktionen genau dann nutzen, wenn die Nutzer sie am meisten brauchen. Dogfooding gehört zur Kultur von Google. Deshalb hat sich das Chrome-Team mit YouTube zusammengetan, um in der neuen Serie "Building a better web" in Zusammenarbeit mit YouTube Erfahrungen auszutauschen, die dabei gewonnen wurden. Im ersten Teil der Reihe geht es darum, wie YouTube eine schnellere Internetnutzung ermöglicht hat.
Unser schnelleres Web
Bei YouTube bezieht sich die Leistung darauf, wie schnell Videos und andere Inhalte wie Empfehlungen und Kommentare auf Webseiten geladen werden. Die Leistung wird außerdem dadurch gemessen, wie schnell YouTube auf Nutzerinteraktionen wie Suche, Steuerung des Players, „Mag ich“-Bewertungen und geteilte Inhalte reagiert.
Wachsende Schwellenländer wie Brasilien, Indien und Indonesien sind für das mobile Web auf YouTube wichtig. Da viele Nutzer in diesen Regionen langsamere Geräte und eine begrenzte Netzwerkbandbreite haben, ist es besonders wichtig, eine schnelle und nahtlose Erfahrung sicherzustellen.
Damit alle Nutzer inklusiv sind, haben wir uns entschieden, durch Lazy Loading und Codemodernisierung Leistungsmesswerte wie Core Web Vitals zu verbessern.
Core Web Vitals verbessern
Anhand des Berichts zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) ermittelte das YouTube-Team, wie echte Nutzer die Wiedergabe- und Suchergebnisseite auf Mobilgeräten in diesem Bereich erleben. Das Unternehmen stellte fest, dass seine Core Web Vitals-Messwerte viel Raum für Verbesserungen bieten, da der Messwert Largest Contentful Paint (LCP) in einigen Fällen 4–6 Sekunden beträgt. Das lag deutlich über dem Zielwert von 2,5 Sekunden.
Um Verbesserungsmöglichkeiten zu finden, nutzte das Unternehmen Lighthouse, um die YouTube-Wiedergabeseiten zu prüfen. Dabei wurde ein niedriger Lighthouse-Wert (Lab) mit einem First Contentful Paint (FCP) von 3,5 Sekunden und einem LCP von 8,5 Sekunden festgestellt.
Um FCP und LCP zu optimieren, führte das YouTube-Team mehrere Tests durch, die zu zwei großen Entdeckungen führten.
Die erste Entdeckung war, dass man die Leistung verbessern könnte, indem man den HTML-Code für den Google Video Player über das Skript verschiebt, das den Video Player interaktiv macht. Laut Labortests kann dies sowohl FCP als auch LCP von 4,4 Sekunden auf 1,1 Sekunden verbessern.
Die zweite Entdeckung war, dass bei LCP nur
<video>-Elementbilder und keine Frames aus dem Videostream selbst berücksichtigt werden. Bisher hat YouTube die schnellstmögliche Zeit bis zum Start der Wiedergabe des Videos optimiert. Um den LCP-Wert zu verbessern, begann das Team auch mit der Optimierung der Geschwindigkeit, mit der das Posterbild ausgeliefert werden kann. Das Team experimentierte mit verschiedenen Varianten von Posterbildern und wählte das aus, das bei Nutzungstests die beste Punktzahl erzielt hat. So konnten sowohl FCP als auch LCP deutlich verbessert werden, wobei der LCP-Wert im Feld von 4,6 auf 2,0 Sekunden verbessert wurde.
Diese Optimierungen haben zwar den LCP-Wert verbessert, das Team war jedoch der Meinung, dass die aktuelle Definition des LCP-Messwerts aus Sicht des Nutzers nicht vollständig erfasst wurde, als der „Hauptinhalt“ der Seite geladen war – das ist das Ziel des LCP.
Deshalb haben Mitglieder des YouTube-Teams gemeinsam mit dem Chrome-Team nach Möglichkeiten gesucht, den LCP-Messwert zu verbessern. Nachdem die Teams die Machbarkeit und Auswirkungen einiger Optionen geprüft hatten, entstand ein Vorschlag, bei dem die Farbzeit des ersten Frames eines Videoelements als LCP-Kandidaten betrachtet werden sollte.
Sobald diese Änderung in Chrome umgesetzt wird, freut sich das YouTube-Team darauf, die Optimierung für LCP fortzusetzen. Und in der aktualisierten Version des Messwerts haben diese Optimierungen einen direkteneren Einfluss auf die tatsächliche Nutzererfahrung.
Modularisierung mit Lazy Loading
YouTube-Seiten enthielten viele Module, die mit Begeisterung geladen wurden. Um das Rendern von mehr als 50 Komponenten zu optimieren, erstellte das Team eine Komponente in die JS-Modulzuordnung, die dem Client mitteilt, welche Module geladen werden sollen. Wenn Sie die Komponenten als „verzögert“ kennzeichnen, werden die JS-Module später geladen, wodurch die anfängliche Ladezeit der Seite und die Menge an nicht verwendetem JavaScript reduziert werden, die an den Client gesendet wird.
Nach der Implementierung von Lazy Loading stellte das Team jedoch einen Wasserfalleffekt fest, bei dem Lazy Loading-Komponenten und ihre Abhängigkeiten zu suboptimalen Zeiten geladen werden.
Zur Lösung dieses Problems hat das Team die für eine Ansicht erforderliche Mindestanzahl an Komponenten ermittelt und in einer einzelnen Netzwerkanfrage zusammengefasst. Das Ergebnis: eine höhere Seitengeschwindigkeit, eine geringere JavaScript-Parsing-Zeit und letztendlich bessere anfängliche Renderingzeiten.
Komponentenübergreifende Statusverwaltung
Bei YouTube traten aufgrund der Steuerelemente des Videoplayers Leistungsprobleme auf, insbesondere auf älteren Geräten. Die Codeanalyse zeigte, dass der Player, mit dem Nutzer Funktionen wie die Wiedergabegeschwindigkeit und den Fortschritt steuern können, im Laufe der Zeit zu einer Überkomponentenverteilung kam.
Jedes Touch-Move-Ereignis für die Fortschrittsanzeige hat zwei zusätzliche Stil-Neuberechnungen ausgelöst.Während der Leistungstestläufe im Labor dauerte dies 21,17 ms. Da im Laufe der Zeit neue Steuerelemente hinzugefügt wurden, führte das Muster der dezentralisierten Kontrolle häufig zu zirkulären Abhängigkeiten und Speicherlecks, was sich negativ auf die Leistung der Wiedergabeseite auswirkte.
Um die Probleme aufgrund der dezentralisierten Steuerung zu beheben, aktualisierte das Team die Player-Benutzeroberfläche, um alle Updates zu synchronisieren. Dabei wurde der Player im Wesentlichen in eine Komponente der obersten Ebene refaktoriert, die Daten an seine untergeordneten Elemente übergibt. Dadurch wurde für jede Statusänderung nur ein einziger UI-Aktualisierungs- bzw. Rendering-Zyklus sichergestellt, wodurch verkettete Updates beseitigt wurden. Für das neue Ereignis „Touch-move“ in der Fortschrittsanzeige des Players werden während der JavaScript-Ausführung keine Stilneuberechnungen durchgeführt. Es sind nur noch 25% der Zeit des alten Players erforderlich.
Diese Codemodernisierung führte auch zu weiteren Leistungsverbesserungen wie verbesserten Ladezeiten auf alten Geräten, weniger abgebrochenen Wiedergaben und einer geringeren Anzahl nicht schwerwiegender Fehler.
Fazit
Dank der Investitionen von YouTube in die Leistung werden Wiedergabeseiten viel schneller geladen. 76% der URLs mobiler YouTube-Websites erfüllen jetzt die Grenzwerte für Core Web Vitals-Messwerte. Auf dem Computer wurde der Lab-LCP für die Wiedergabeseite von ungefähr 4,6 Sekunden auf 1,6 Sekunden reduziert. Die Interaktions- und Rendering-Leistung der Website, insbesondere im YouTube-Videoplayer, kann bis zu 75% weniger Zeit für die JavaScript-Ausführung aufwenden als zuvor.
Die Leistung von YouTube im letzten Jahr hat sich auch bei den Unternehmensmesswerten wie Wiedergabezeit und aktive Nutzer pro Tag verbessert. Angesichts des Erfolgs dieser Bemühungen planen wir, in Zukunft noch weitere Optimierungsmöglichkeiten zu finden.
Im zweiten Teil der Reihe, „Ein barrierefreies Web schaffen“ erfahren Sie, wie YouTube seine Website für Nutzer mit Screenreadern zugänglicher gemacht hat.
Ein besonderer Dank gilt Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra und den YouTube- und Chrome-Teams für ihren Beitrag zu dieser Arbeit.