- Schon ein einziges Standard-YouTube-``-Embed auf einer leeren Seite verursacht 32 Anfragen und 1,3 MB übertragene Daten und ist damit für eine kleine Video-UI unverhältnismäßig schwer
- Fügt man mehrere Videos ein, werden Ressourcen nicht gemeinsam genutzt, sodass das Gewicht linear ansteigt; in Messungen von Zach Leatherman stieg es bei 2 Embeds auf 2,4 MB und bei 3 Embeds auf 3,6 MB
- Die anfangs sichtbaren Funktionen sind im Wesentlichen Posterbild, Titel und ein großer Play-Button, sodass sich dieselbe Erfahrung mit einem Web Component wie `` deutlich leichter nachbilden lässt
lite-youtube-embed liegt bei etwa 100 KB und teilt Ressourcen über mehrere Embeds hinweg, wodurch Geschwindigkeit und Effizienz ohne Funktionsverlust verbessert werden- Da YouTube-Einbettungen weit verbreitet sind, ist es eine praktische Optimierung mit realem Effekt, pro Embed Datenmengen im Megabyte-Bereich einzusparen – bis hin zu geringerem Stromverbrauch und CO2-Emissionen
Die Kosten des Standard-``-Embeds
- Wählt man im YouTube-Teilen-Menü
Embed, wird HTML auf Basis von `` bereitgestellt
- Im Standard-Code fehlt
loading="lazy", sodass auch Videos außerhalb des sichtbaren Bereichs sofort geladen werden können
- Schon wenn YouTube dem Standard-iframe nur Lazy Loading hinzufügen würde, wären sofortige Performance-Verbesserungen möglich
- Um das iframe responsiv zu machen und das ursprüngliche Seitenverhältnis zu erhalten, kann man das YouTube-Embed-iframe direkt per CSS ansprechen
iframe[src^="https://www.youtube.com/embed/";] {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16 / 9;
}
Reale Messwerte und lineares Wachstum
- Selbst wenn man nur ein einziges YouTube-Embed auf einer leeren Seite platziert, fallen die Ladekosten hoch aus
-
32 Anfragen
- 1,3 MB Datenübertragung
- 2,76 Sekunden Ladezeit im WLAN des Autors
- Zach Leatherman dokumentierte, dass das Gewicht mit steigender Anzahl von Embeds linear zunimmt, weil Ressourcen nicht geteilt werden
- 2 Embeds: 2,4 MB
- 3 Embeds: 3,6 MB
- Der Umfang scheint inzwischen noch größer zu sein als zu dem Zeitpunkt, als Zach das überprüfte
Die UI, die Nutzer zuerst sehen, ist simpel
- In einem YouTube-Embed begegnen Nutzern anfangs nur wenige Elemente
- das Posterbild des Videos
- der Titel des Videos
- ein großer Play-Button, der bei Klick die Wiedergabe startet
- Diese UI und dieses Verhalten lassen sich auch umsetzen, ohne vorab die kompletten Ressourcen des YouTube-Players zu laden
- Ob leichtere Embeds die Interaktion senken, lässt sich ohne offengelegte Methodik und Daten schwer beurteilen
- In der Vergangenheit gab es sogar einen Fall, in dem ein YouTube-Ingenieur eine leichtere Videoseite testete und die durchschnittliche Ladezeit dennoch anstieg
- Die leichtere Seite erreichte dadurch auch Nutzer mit schwächeren Geräten und langsamerer Internetverbindung
- Die Nutzung durch diese neu erreichten Nutzer könnte die Kennzahl zur durchschnittlichen Ladezeit verschlechtert haben
- Betrachtet man nur die durchschnittliche Ladezeit, übersieht man leicht tatsächliche Geschwindigkeitsverbesserungen pro Nutzer
Alternative: das ``-Web-Component
- lite-youtube-embed von Paul Irish, einer bekannten Figur im Google-Performance-Umfeld, ist ein Web Component, das das Standard-Embed-Erlebnis leichter nachbildet
- Laut Projektbeschreibung rendert es wie ein echtes Embed und ist dabei etwa 224-mal schneller
- Die Nutzererfahrung ist fast identisch mit dem Standard-YouTube-Embed
- Anzeige des Posterbilds
- Anzeige des Titels
- Anzeige eines großen Play-Buttons
- Videowiedergabe per Klick
- Der Unterschied liegt in Ressourcenverbrauch und gemeinsamer Nutzung
- Standard-YouTube-Embed: etwa 1,3 MB
- ``: etwa 100 KB
- Ressourcen können über mehrere Embeds hinweg gemeinsam genutzt werden
- Ohne Funktionsverlust gewinnt man Geschwindigkeit, Effizienz und grundlegenden Datenschutz
Nutzung und verwandte Implementierungen
- Verwendet wird es, indem man das Web Component per JavaScript registriert und anschließend das Element `` nutzt
- Möglich sind Installation per npm, direktes Kopieren oder ein CDN-Link
import "https://esm.sh/lite-youtube-embed";;
- Die im README empfohlene Methode setzt zuerst das HTML und lädt das Skript asynchron nach, um progressive enhancement anzuwenden
- Damit es schon vor dem Laden von JavaScript korrekt aussieht, kann
background-image direkt im HTML gesetzt werden
[Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)
- Es gibt auch verwandte Implementierungen und Alternativen
2 Kommentare
lite-youtube-embed – schnelleres YouTube-Embed
Meinungen auf Hacker News
Auf einer Community-Forum-Plattform werden YouTube-Embeds erkannt und durch Proxy-Thumbnails ersetzt, die vor dem Klick nicht geladen werden.
Nur weil eine Person in einem Thread ein YouTube-Video teilt, müssen nicht alle, die diese Seite öffnen, 1 MB+ JavaScript herunterladen und sich von Google auch noch per IP tracken lassen.
Tracking ist mir nicht so wichtig, deshalb verwende ich einfach die von YouTube bereitgestellten Thumbnails.
Der SoundCloud-Player ist ebenfalls unglaublich schwergewichtig.
Wenn man Thumbnails hotlinkt, kann Google auch darüber tracken.
Der Autor sagt zwar, er glaube nicht an Belege dafür, dass eine leichtere Version das Engagement senkt, aber ich halte das durchaus für plausibel.
In der Demo des empfohlenen Projekts lite-youtube-embed gibt es sowohl den Lite-Player als auch den normalen Player, und die Lite-Version braucht merklich länger, bis die Videowiedergabe startet.
Mit jeder zusätzlichen Millisekunde Ladezeit sinkt das Engagement, und hier wirkt der Unterschied wie mehrere Hundert Millisekunden oder mehr.
https://paulirish.github.io/lite-youtube-embed/
Das Argument, dass jede Millisekunde zählt, gilt auch für Webseiten. Wenn Nutzer die Seite verlassen, kommen sie gar nicht erst zum Video.
Außerdem kann es völlig in Ordnung sein, wenn Nutzer das Video nicht ansehen wollen. Persönlich finde ich es gut, wenn es auf einer Webseite eine Zusammenfassung gibt, sodass ich das Video vermeiden kann.
Auch mit der Desktop-Überarbeitung von YouTube bin ich unzufrieden: Es wird viel zu viel Bildschirmfläche dafür verwendet, andere Videos zu bewerben, statt das Video zu zeigen, wegen dem ich eigentlich gekommen bin. Ich hätte gern weniger Ablenkung.
Auf Ampeln übertragen: Mir ist lieber, die Ampel, auf die ich zufahre, ist grün, als dass alle Ampeln kurz rot sind.
Das tatsächliche Verhalten großer Unternehmen zeigt klar, dass sie sich darum nicht kümmern; und wenn es ihnen nicht wichtig ist, gibt es keinen Grund, dass wir stattdessen für sie optimieren.
In diesem Anwendungsfall ist das kein großes Problem, aber im restlichen Stack sollte man auf Performance achten.
Ich weiß nicht, wie es zu diesem Rückschritt kommen konnte, und Google scheint Dinge, die eigentlich gut funktionierten, nach und nach kaputtzumachen.
Das kann je nach Umgebung variieren: Firefox, ein etwa zwei Jahre alter i7-1185G7-Laptop, Windows 11, Edge im 32-Bit-Modus aktualisiert sich weiter, und seit ein paar Wochen wurde nicht neu gestartet.
Der Eindruck von Langsamkeit entsteht vor allem durch die drehende Ladeanzeige. Sie bewirbt sich gewissermaßen selbst als langsam.
Die Verzögerung vom Klick bis zur Wiedergabe dürfte zwar eine Rolle spielen, aber um das sauber zu messen, bräuchte es einen Akteur in der Größenordnung von YouTube.
Zu dem Gerücht, dass leichtere Embeds das Engagement senken, und zu dem vorgeschlagenen lite-youtube-embed: Nutzer können schon dann misstrauisch oder irritiert reagieren, wenn ein Player nur ein wenig anders aussieht oder sich anders verhält.
Beim lite-youtube-embed in der Demo gibt es zwar einen Titel, aber keinen Link zur eigentlichen YouTube-Seite; das wirkt sogar feindselig, als wolle es den Zugang zum ursprünglichen „Content“ verhindern.
Natürlich ließe sich diese Funktion leicht ergänzen, aber es zeigt ein größeres Problem.
Ich spiele eingebettete Videos fast nie ab, aber wenn, dann reicht mir einfach das normale YouTube-Erlebnis. Wenn noch eine weitere unbekannte Schicht darumgelegt wird, sinkt die Wahrscheinlichkeit, dass ich klicke.
Die Formulierung im Artikel, dass „nichts geopfert wird“, ist ein Beispiel dafür, dass Entwickler glauben zu wissen, wie Nutzer ihre Software verwenden. In Wirklichkeit ist es immer nur eine Vermutung.
Ich hoffe auf weniger Videos und weniger Google-Abhängigkeit sowie weniger JavaScript-Klumpen überall. Für ein besseres Web sollten YouTube-Videos nicht überall eingebettet werden.
https://paulirish.github.io/lite-youtube-embed/
Jetzt, da ich das weiß, wäre es gut, wenn solche Lite-Player diesen Button ebenfalls hätten. Trotzdem blockiert diese Implementierung nicht vollständig einen einfachen Weg, an den Link zu kommen.
Wenn man das Video abspielt, kommt man zwar daran, aber das widerspricht dem Zweck. Ich will das Video nicht abspielen und auch nicht warten, bis es geladen ist, es dann pausieren und anschließend auf Speichern klicken.
Jetzt müsste man Blogger nur noch davon abhalten, GitHub-Gist-Embeds zu verwenden
Hugo und vermutlich auch andere statische Site-Generatoren unterstützen Code-Snippets mit Syntax-Highlighting standardmäßig, und auch dynamischere Sites können mit highlight.js die Abhängigkeit von Drittanbieterdiensten loswerden
Für kleine Code-Schnipsel ein schwergewichtiges iframe zu verwenden, ist wirklich seltsam
https://gohugo.io/content-management/syntax-highlighting/
https://highlightjs.org
Selbst wenn es mir nicht gefällt, ergibt es keinen Sinn, sie zu „zwingen“, ihre Website nach meinem Geschmack zu ändern
Es wurde innerhalb weniger Wochen behoben, aber ich war erstaunt, dass es jahrelang so gewesen war
Wenn man auf der Seite eine Content Security Policy nutzen kann, lassen sich Anzeigen blockieren, wodurch das Gesamtgewicht des Embeds sinkt und sich auch die User Experience verbessert
Weitere Informationen: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Content-Security-PolicyaufnehmenDenn damit schaltet man den Schutz von CSP gegen Injection-Angriffe aus. Wenn es unbedingt nötig ist, gibt es sicherere Methoden, Inline-Skripte zu erlauben
https://content-security-policy.com/
Bei der Aussage „leichtere Embeds haben die Interaktion verringert“ scheint ein großer Teil der Geschichte zu fehlen
Eigentlich sollte eine schnellere Ladezeit die Interaktion verbessern. Wenn die Interaktion bei einem leichteren Embed aber gesunken ist, heißt das, dass irgendeine Funktion oder ein bestimmtes Verhalten geopfert wurde
Der Artikel sagt jedoch, dass nichts geopfert wurde – also fehlt irgendwo ein Teil der Geschichte
Hier könnte es ähnlich sein. Dank des leichteren Embeds konnten viele Menschen das Video erstmals laden, sind aber wegen langsamer Geräte oder Verbindungen beim Abspielen abgesprungen
Dann würden Menschen, die zuvor den Player gar nicht vollständig laden konnten und deshalb keinerlei Daten hinterließen, nun so erscheinen, als erhöhten sie die Quote der „abgebrochenen Videowiedergaben“
Nutzer haben je nach Ziel unterschiedliche Erwartungen und Toleranzen bei Ladezeiten, und eine Seite und das darin enthaltene Video sind unterschiedliche Ziele
Die Ladezeit der gesamten Seite ist auch nicht immer an die Ladezeit des Embeds gekoppelt, und das Laden der Gesamtseite kann die Ladezeit des Inhalts verdecken
Die wichtigere Kennzahl ist möglicherweise nicht die Ladezeit des Embeds, sondern die Verzögerung vom Klick bis zur Wiedergabe
Als nutzerseitige Lösung für uBlock-Nutzer kann man click2load-Filter verwenden
Allerdings könnte es wegen Chromes Umstellung auf Manifest V3 nicht funktionieren. Als Referenz eignen sich die Filter von yokoffing/filterlists
https://raw.githubusercontent.com/yokoffing/filterlists/main...
Der Autor ist der Entwickler von Betterfox und hat auf GitHub auch andere nützliche Filter
Was ich will, ist einfach ein normaler Link; deshalb habe ich früher ein kurzes Userscript gebaut, das YouTube-iframes auf Seiten durch Links ersetzt
Für eine simple Implementierung funktioniert es erstaunlich gut. Es findet iframes mit
youtube.com/embedundyoutube-nocookie.com/embed, ersetzt sie durchwatch?v=-Links, kann dabei Zeitstempel erhalten und auf Wunsch auch ein Thumbnail-Bild hinzufügenDie Stelle „Je mehr Embeds, desto linearer steigt auch das Gewicht. Zwei sind 2,4 MB, drei sind 3,6 MB“ wirkt seltsam
Ich frage mich, warum diese Ressourcen nicht aus dem Cache geholt werden. Wenn alle von
www.youtube.comgeladen werden, sollten sie nach der Same-Origin-Policy doch gecachte Ressourcen verwenden könnenDer beste Teil des Artikels war für mich die Stelle, an der eine Umstellung auf eine leichtere Seite die durchschnittliche Seitenladezeit sogar erhöht hat
Bei genauerem Hinsehen zeigte sich, dass Nutzer mit schwachen Geräten und langsamen Internetverbindungen YouTube dadurch erstmals tatsächlich nutzen konnten, und weil sie es viel nutzten, wirkte der Durchschnitt langsamer
Die tatsächliche Nutzungsgeschwindigkeit wurde für alle relativ schneller, und die Kennzahl durchschnittliche Seitenladezeit erwies sich letztlich als bedeutungsloser Köder – das fand ich beeindruckend
Früher habe ich eine Firefox-Erweiterung gebaut, die alle YouTube-Embeds durch Thumbnails ersetzt und beim Anklicken YouTube öffnet
Ursprünglich entstand sie, weil Handys kein Flash hatten, Flash-Embeds aber verbreitet waren; später habe ich sie erweitert, sodass sie auch iframe-Embeds verarbeitet
In den meisten Fällen war es auch für die User Experience besser, die vollständige YouTube-Website oder -App zu öffnen, statt ein kleines Embed-Fenster zu verwenden
Ich hatte sie damals schon für die neue High-Level-Extension-API geschrieben, aber die Unterstützung über Browser-Versionen hinweg blieb nicht so zuverlässig wie erwartet, was mich genervt hat; deshalb habe ich sie nicht auf WebExtension portiert. Dieser Artikel macht mir Lust, sie wieder zu portieren