Ein besseres Web: Ein schnelleres YouTube

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.

Sriram Krishnan
Sriram Krishnan

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 Google-Kultur. Deshalb hat das Chrome-Team mit YouTube zusammengearbeitet, um in einer neuen Reihe mit dem Titel „Building a better web“ (Ein besseres Web schaffen) die Erfahrungen zu teilen, die es dabei gemacht hat. Im ersten Teil der Reihe geht es darum, wie YouTube eine schnellere Webversion entwickelt hat.

PageSpeed Insights mit den Daten aus dem Bericht zur Nutzererfahrung in Chrome
Die Wiedergabeseite von YouTube für das mobile Web erfüllt die Grenzwerte für Core Web Vitals.

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 Suchanfragen, Playersteuerung, „Mag ich“-Bewertungen und geteilte Inhalte 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 sich YouTube zum Ziel gesetzt, Leistungsmesswerte wie die Core Web Vitals durch Lazy Loading und Codemodernisierung zu verbessern.

Core Web Vitals verbessern

Um Verbesserungsmöglichkeiten zu identifizieren, nutzte das YouTube-Team den Bericht zur Nutzererfahrung in Chrome (Chrome User Experience Report, CrUX), um zu sehen, wie echte Nutzer die Wiedergabe von Videos und die Suchergebnisseiten auf Mobilgeräten in der Praxis nutzen. 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.

Diagramme für FCP und LCP mit den Überspringungsraten auf der YouTube-Wiedergabeseite sowie der YouTube-Quelle.

Um Verbesserungsmöglichkeiten zu ermitteln, 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.

Lighthouse-Bericht für die mobile YouTube-Version
In Chrome gilt als Goldstandard ein Zielwert von 1,8 Sekunden für FCP und 2,5 Sekunden für LCP. FCP und LCP waren mit 3,5 Sekunden bzw. 8,5 Sekunden deutlich im gelben und roten Bereich.

Um FCP und LCP zu optimieren, führte das YouTube-Team mehrere Tests durch. Dabei wurden zwei wichtige Erkenntnisse gewonnen.

  1. 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.

  2. 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 Posterbildvarianten und wählte das Bild aus, das in den Nutzertests am besten abgeschnitten hatte. Durch diese Arbeit konnten sowohl der FCP als auch der LCP deutlich verbessert werden. Der LCP im Feld sank von 4, 6 Sekunden auf 2, 0 Sekunden.

LCP-Test für Seiten im mobilen Web mit Kontrollgruppe, Test A (Bild-Thumbnail) und Test B (schwarzes Thumbnail) ansehen
In unserem Lab konnten wir nach dieser Änderung eine Verbesserung der FCP und LCP von 4,4 Sekunden auf 1,1 Sekunden feststellen. Test A: Die Verwendung des tatsächlichen Video-Thumbnails funktioniert gut auf Seiten, auf denen das Video pausiert gestartet wird. Bei Seiten mit automatischer Videowiedergabe wie der Wiedergabeseite schnitt es in Nutzerstudien jedoch schlecht ab. Außerdem ging die Zahl der aktiven Nutzer zurück. Test B: Ein einfarbiges schwarzes Posterbild erzielte in den Nutzerstudien die besten Ergebnisse. Nutzer fanden den Übergang von einem schwarzen Bildschirm zum ersten Frame des Videos bei Autoplay-Videos weniger störend.
Das schwarze Thumbnail wurde im Juli 2021 für alle mobilen Webnutzer in der Produktion eingeführt. Wie die obige RUM-Analyse zeigt, konnte damit eine deutliche Verbesserung der FCP und LCP erzielt werden.
Das schwarze Thumbnail wurde im Juli 2021 für alle mobilen Webnutzer in der Produktion eingeführt. Wie die obige RUM-Analyse zeigt, konnte dadurch eine deutliche Verbesserung der FCP und LCP erzielt werden.

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 Komponente zur 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 wird die anfängliche Ladezeit der Seite und die Menge an nicht verwendetem JavaScript reduziert, das an den Client gesendet wird.

Nach der Implementierung des Lazy Loadings stellte das Team jedoch einen Kaskadeneffekt fest, bei dem Lazy Loaded-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 Renderingzeiten.

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.

YouTube-Player und Steuerelemente visualisiert
Mit dem YouTube-Videoplayer können Nutzer unter anderem die Wiedergabegeschwindigkeit steuern, den Fortschritt verfolgen und Abschnitte überspringen. Wenn ein Nutzer auf ein bestimmtes Steuerelement tippt, muss die Statusänderung an andere Steuerelemente weitergegeben werden. Wenn ein Nutzer beispielsweise auf die Fortschrittsanzeige tippt, muss dies an Steuerelemente wie den Wiedergabestandort und die Untertitel weitergegeben werden.

Jedes Touch-Bewegungsereignis der Fortschrittsanzeige hat zwei zusätzliche Stilneuberechnungen ausgelöst und während der Leistungstests im Lab 21,17 ms in Anspruch genommen. Da im Laufe der Zeit neue Steuerelemente hinzugefügt wurden, führte das dezentrale Kontrollmuster häufig zu zyklischen Abhängigkeiten und Speicherlecks, was sich negativ auf die Leistung der Wiedergabeseite auswirkte.

Ereignis mit 21,17 ms auf der Zeitachse für die Leistung
Chrome-Entwicklertools mit einer 4-fachen CPU-Verlangsamung.

Um die Probleme aufgrund der dezentralen Steuerung zu beheben, aktualisierte das Team die Player-Benutzeroberfläche, um alle Updates zu synchronisieren. Im Grunde wurde der Player in eine einzelne Komponente der obersten Ebene umstrukturiert, die Daten an die untergeordneten Elemente weitergibt. So wurde sichergestellt, dass bei jeder Statusänderung nur ein UI-Aktualisierungs- (Rendering-)Zyklus ausgeführt wird, wodurch verkettete Aktualisierungen vermieden wurden. Beim neuen Ereignis „Touch-Move“ der Fortschrittsanzeige des Players werden während der JavaScript-Ausführung keine Stile neu berechnet. Es benötigt jetzt nur noch 25% der Zeit des alten Players.

Die Zeitspanne der Ereignisse in der Leistungszeitachse wurde verkürzt.

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.

Durch die Leistungsverbesserungen der YouTube-Webversion im letzten Jahr haben sich auch die Geschäftsmesswerte verbessert, darunter die Wiedergabezeit und die Anzahl der aktiven Nutzer pro Tag. Aufgrund des Erfolgs dieser Bemühungen planen wir, in Zukunft noch mehr Möglichkeiten zur Optimierung zu untersuchen.

Ein besonderer Dank geht an 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 an die YouTube- und Chrome-Teams für ihren Beitrag zu dieser Arbeit.