Eine Fallstudie zu Änderungen, die das YouTube-Webteam vorgenommen hat, um die Leistung zu verbessern, die Bestehensraten für Core Web Vitals zu erhöhen und wichtige Geschäftsmesswerte zu steigern.
Das Chrome-Team spricht oft davon, das Web besser zu machen. Was bedeutet das? Webinhalte sollten schnell, barrierefrei und gerätespezifisch sein, damit Nutzer genau das finden, was sie gerade brauchen. Dogfooding ist Teil der Unternehmenskultur von Google. Deshalb hat sich das Chrome-Team mit YouTube zusammengetan, um die gewonnenen Erkenntnisse in einer neuen Serie mit dem Titel "Building a better web" zu teilen. Im ersten Teil der Reihe geht es darum, wie YouTube eine schnellere Webversion entwickelt hat.
Bei YouTube bezieht sich die Leistung darauf, wie schnell Videos und andere Inhalte wie Empfehlungen und Kommentare auf Webseiten geladen werden. Die Leistung wird auch daran gemessen, wie schnell YouTube auf Nutzerinteraktionen wie Suchen, Steuerelemente des Players, „Mag ich“-Bewertungen und das Teilen von Inhalten reagiert.
Wachsende Entwicklungsmärkte wie Brasilien, Indien und Indonesien sind für YouTube im mobilen Web wichtig. Da viele Nutzer in diesen Regionen langsamere Geräte und eine begrenzte Netzwerkbandbreite haben, ist es wichtig, eine schnelle und reibungslose Nutzung zu ermöglichen.
Um allen Nutzern eine inklusive Nutzung zu ermöglichen, hat YouTube sich zum Ziel gesetzt, Leistungsmesswerte wie die Core Web Vitals durch Lazy Loading und Codemodernisierung zu verbessern.
Core Web Vitals verbessern
Das YouTube-Team ermittelte mithilfe des Chrome User Experience Reports (CrUX) Verbesserungspotenzials, um herauszufinden, wie echte Nutzer auf Mobilgeräten Videos und Suchergebnisseiten vor Ort sehen. Sie stellte fest, dass bei ihren Core Web Vitals-Messwerten noch viel Luft nach oben war. Der Messwert Largest Contentful Paint (LCP) betrug in einigen Fällen 4 bis 6 Sekunden. Das war deutlich höher als das Ziel von 2,5 Sekunden.
Um Verbesserungsmöglichkeiten zu identifizieren, nutzte das Team Lighthouse, um die YouTube-Wiedergabeseiten zu analysieren. Dabei wurde ein niedriger Lighthouse-Wert (Lab) mit einem First Contentful Paint (FCP) von 3,5 Sekunden und einem LCP von 8,5 Sekunden ermittelt.
Um FCP und LCP zu optimieren, führte das YouTube-Team mehrere Tests durch. Dabei wurden zwei wichtige Erkenntnisse gewonnen.
Die erste Erkenntnis war, dass die Leistung verbessert werden konnte, indem der HTML-Code für den Videoplayer über das Script gelegt wurde, das den Videoplayer interaktiv macht. Lab-Tests haben gezeigt, dass sich dadurch sowohl der FCP als auch der LCP von 4,4 Sekunden auf 1,1 Sekunden verbessern lassen.
Die zweite Erkenntnis war, dass der LCP nur
<video>Element-Posterbilder und keine Frames aus dem Videostream selbst berücksichtigt. YouTube hat traditionell die Zeit bis zum Start der Videowiedergabe optimiert. Um den LCP zu verbessern, hat das Team auch die Geschwindigkeit optimiert, mit der das Posterbild bereitgestellt werden kann. Er experimentierte mit einigen Varianten von Posterbildern und wählte dasjenige aus, das in den Nutzertests am besten abgeschnitten hatte. So konnten sowohl der FCP als auch der LCP deutlich verbessert werden, wobei sich der LCP im Feld von 4,6 auf 2,0 Sekunden verbesserte.
Diese Optimierungen verbesserten zwar den LCP, das Team war jedoch der Meinung, dass die aktuelle Definition des LCP-Messwerts aus Sicht der Nutzer nicht vollständig erfasst, wann der „Hauptinhalt“ der Seite geladen wurde – was das Ziel des LCP ist.
Um diese Bedenken auszuräumen, haben Mitglieder des YouTube-Teams gemeinsam mit Mitgliedern des Chrome-Teams nach Möglichkeiten gesucht, den LCP-Messwert zu verbessern, um ihren Anwendungsfall zu berücksichtigen. Nachdem die Machbarkeit und Auswirkungen einiger Optionen geprüft wurden, empfohlen die Teams, die Paint-Zeit des ersten Frames eines Videoelements als LCP-Kandidat zu verwenden.
Sobald diese Änderung in Chrome eingeführt wurde, wird das YouTube-Team seine Arbeit an der Optimierung für LCP fortsetzen. Durch die aktualisierte Version des Messwerts wirken sich diese Optimierungen direkter auf die Nutzerfreundlichkeit aus.
Modularisierung mit Lazy Loading
YouTube-Seiten enthielten viele Module, die sofort geladen wurden. Um die Darstellung von über 50 Komponenten zu optimieren, erstellte das Team eine Komponenten-zu-JS-Modulzuordnung, die dem Client mitteilte, welche Module geladen werden sollten. Wenn Komponenten als „lazy“ gekennzeichnet werden, werden die JS-Module später geladen. Dadurch verringert sich die anfängliche Ladezeit der Seite und die Menge an nicht verwendetem JavaScript, das 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 wurden.
Um dieses Problem zu lösen, ermittelte das Team die minimalen Komponenten, die in einer Ansicht benötigt werden, und fasste sie in einer einzigen Netzwerkanfrage zusammen. Die Ergebnisse waren eine verbesserte Seitengeschwindigkeit, eine reduzierte JavaScript-Parsezeit und letztendlich kürzere anfängliche Rendering-Zeiten.
Zustandsverwaltung über Komponenten hinweg
Aufgrund der Playersteuerung kam es auf YouTube zu Leistungsproblemen, insbesondere auf älteren Geräten. Die Codeanalyse ergab, dass der Player, mit dem Nutzer Funktionen wie Wiedergabegeschwindigkeit und Fortschritt steuern können, im Laufe der Zeit zu viele Komponenten hatte.
Jedes Touch-Move-Ereignis in der Fortschrittsanzeige löste zwei zusätzliche Stil-Neuberechnungen aus und dauerte 21,17 ms während des Leistungstests im Labor. Da im Laufe der Zeit neue Einstellungen hinzugefügt wurden, verursachte das Muster der dezentralisierten Kontrolle häufig zirkuläre Abhängigkeiten und Speicherlecks, was sich negativ auf die Leistung der Wiedergabeseite auswirkte.
Um die Probleme aufgrund der dezentralisierten Kontrolle zu beheben, aktualisierte das Team die Spieler-UI, um alle Updates zu synchronisieren. Dabei wurde der Player im Grunde auf eine Komponente der obersten Ebene refaktoriert, die Daten an seine untergeordneten Elemente weitergeben würde. So wurde sichergestellt, dass bei jeder Statusänderung nur ein UI-Aktualisierungs- (Rendering-)Zyklus ausgeführt wird, wodurch verkettete Aktualisierungen vermieden wurden. Für das neue Spieler-Fortschrittsbalken-Ereignis vom Typ „Touch-Move“ gibt es während der JavaScript-Ausführung keine Stilneuberechnungen. Es erfordert jetzt nur noch 25% der Zeit des alten Players.
Diese Codemodernisierung führte auch zu weiteren Leistungsverbesserungen, z. B. zu kürzeren Ladezeiten auf älteren Geräten, weniger abgebrochenen Wiedergaben und einer geringeren Anzahl nicht kritischer Fehler.
Ergebnisse und Optimierungen
Durch die Investitionen von YouTube in die Leistung laden Wiedergabeseiten jetzt viel schneller. 76% der URLs der mobilen YouTube-Websites erfüllen jetzt die Grenzwerte für die Core Web Vitals-Messwerte. Auf dem Computer wurde der LCP für die Wiedergabeseite von etwa 4,6 Sekunden auf 1,6 Sekunden reduziert. Die Interaktions- und Renderingleistung der Website, insbesondere im YouTube-Videoplayer, ist um bis zu 75% schneller als zuvor.
Im letzten Jahr hat sich die Leistung der YouTube-Website verbessert und auch die Geschäftsmesswerte wie Wiedergabezeit und Anzahl der aktiven Nutzer pro Tag verbessert. Aufgrund des Erfolgs dieser Bemühungen planen wir, in Zukunft noch mehr Möglichkeiten zur Optimierung zu untersuchen.
Wir danken Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra sowie den YouTube- und Chrome-Teams für ihren Beitrag zu dieser Arbeit.