Bilder gelten als der klassische Ladezeit-Treiber - Video steht seltener im Verdacht, obwohl ein einziges Hero-Video oft schwerer wiegt als alle Bilder einer Seite zusammen. Der Anteil der Seiten mit Video wächst: 6,7 Prozent (HTTP Archive Web Almanac) der mobilen Seiten binden mindestens ein video-Element ein, ein relativer Zuwachs von 32 Prozent (HTTP Archive Web Almanac) gegenüber 2022. Gleichzeitig starten 23 Prozent (HTTP Archive Web Almanac) der Video-Elemente per Autoplay und beginnen sofort zu laden - auch außerhalb des sichtbaren Bereichs (web.dev). Dieser Beitrag zeigt, wie Video den Largest Contentful Paint beeinflusst, wie ein Poster-Bild mit Preload das erste sichtbare Bild beschleunigt, wie preload unnötige Bytes verhindert, welche Codecs und Container die Datei kleiner machen und wie Fassaden den Player-Overhead eingebetteter Videos erst beim Klick entstehen lassen. Als Media-Baustein gehört das in jede Frontend-Optimierung.
Warum Video ein unterschätzter Ladezeit-Treiber ist
Ein Video verhält sich anders als ein Bild. Ein Bild ist eine einzelne Datei, die geladen und gezeichnet wird; ein Video ist ein Container mit codierten Bilddaten, das der Browser in Häppchen lädt, dekodiert und abspielt. Solange ein Video nicht abgespielt wird, muss der Browser gar nicht die gesamte Datei holen - er kann mit einem Vorschaubild und wenigen Metadaten auskommen. Genau hier entscheidet sich, ob Video zum Ladezeit-Treiber wird: Wer den Browser die volle Datei sofort laden lässt, obwohl der Nutzer sie vielleicht nie ansieht, verschenkt Bandbreite auf dem kritischen Ladepfad.
Die Verbreitung nimmt zu. Der HTTP Archive Web Almanac zählt Video inzwischen auf 6,7 Prozent (HTTP Archive Web Almanac) der mobilen und 7,7 Prozent (HTTP Archive Web Almanac) der Desktop-Seiten, mit einem relativen Zuwachs von 32 Prozent (HTTP Archive Web Almanac) seit 2022. Dabei sind die meisten Clips kurz: über die Hälfte (HTTP Archive Web Almanac) der Videos ist kürzer als 30 Sekunden, fast ein Viertel sogar unter zehn Sekunden. Das sind typische Hero-Loops und Produktanimationen - oft dieselbe Rolle, die früher ein animiertes GIF spielte. Und solche GIFs sind schwer: web.dev beschreibt, dass animierte GIFs nicht selten mehrere Megabyte (web.dev) groß werden, obwohl sich derselbe Effekt als Video mit einem Bruchteil der Bytes erreichen lässt.
Video berührt mehrere Core Web Vitals gleichzeitig
Das Poster-Bild als LCP-Kandidat
Lange Zeit zählten Videos nicht zu den LCP-Kandidaten. Das hat sich geändert: Der erste gezeichnete Frame eines Videos gilt heute als Kandidat für den Largest Contentful Paint (web.dev). Bei einem Hero-Video ist damit genau das große, oben liegende Video das Element, an dem der LCP hängt. Da der erste Frame aber erst nach dem Laden und Dekodieren erscheint, wäre der LCP an das langsame Video gekoppelt - es sei denn, ein Poster-Bild springt ein. Das poster-Attribut zeigt ein statisches Bild, solange das Video lädt (MDN), und dieses Bild wird - da es schneller lädt als das Video - in der Regel zum eigentlichen LCP-Element. Ein Poster funktioniert damit wie ein Platzhalter, ähnlich dem progressiven Bildladen mit LQIP.
Der Effekt ist messbar. DebugBear zeigt an einer Demoseite, wie das Hinzufügen eines Poster-Bildes den LCP von 1,55 auf 1,23 Sekunden (DebugBear) senkte; das anschließende Vorladen des Posters mit hoher Priorität brachte ihn weiter auf 1,2 Sekunden (DebugBear). Wichtig dabei: Chrome unterstützt kein Vorladen der Videodatei selbst - vorladen lässt sich nur das Poster-Bild (DebugBear). Das Poster wird deshalb wie ein normales Bild behandelt: als modernes Format ausgeliefert und mit fetchpriority priorisiert. Wie dieser Priority Hint genau wirkt, vertieft der Beitrag zu fetchpriority und Priority Hints; die Formatwahl für das Poster selbst behandelt unsere Bilder-Optimierung.
<!-- Poster als schnelles LCP-Bild vorladen und hoch priorisieren -->
<link rel="preload" as="image" href="/media/hero-poster.webp"
fetchpriority="high">
<!-- Video mit Poster; ohne Autoplay reicht preload=none -->
<video poster="/media/hero-poster.webp" preload="none"
controls playsinline width="1280" height="720">
<source src="/media/hero.webm" type="video/webm">
<source src="/media/hero.mp4" type="video/mp4">
</video>Der Kern in einem Satz
Das Poster nur vorladen, wenn das Video wirklich das LCP-Element ist
preload steuern: none, metadata, auto
Das preload-Attribut sagt dem Browser, wie viel er vom Video im Voraus holen soll. preload=none bedeutet, dass keine Videodaten vorab geladen werden; preload=metadata holt nur die Metadaten wie die Dauer; preload=auto erlaubt, die ganze Datei zu laden, auch wenn der Nutzer sie vielleicht nie abspielt (MDN). Der Standard ist nicht einheitlich - die Spezifikation empfiehlt metadata, doch die Browser handhaben es unterschiedlich (MDN). Genutzt wird das Attribut ohnehin selten: Nur 16 Prozent (HTTP Archive Web Almanac) der Video-Elemente setzen preload überhaupt, sechs Prozentpunkte weniger als 2022.
In der Praxis ist preload=metadata tückisch: In vielen Browsern wird dabei über den Content-Range-Header bereits ein Stück des Videos geladen, sodass mehr Daten fließen als gewünscht (web.dev). Für ein Video, das nicht automatisch startet, ist deshalb preload=none in Kombination mit einem Poster-Bild meist die sparsamste Wahl - der Browser holt gar keine Videobytes, bis der Nutzer auf Wiedergabe klickt. Zu beachten ist die Rangfolge: autoplay hat Vorrang vor preload - ist Autoplay gesetzt, lädt der Browser das Video, unabhängig davon, was preload sagt (MDN).
| preload-Wert | Was der Browser lädt | Wann sinnvoll | Effekt |
|---|---|---|---|
| none | Keine Videodaten, nur das Poster | Video ohne Autoplay, Klick-Wiedergabe | Sparsamster Start |
| metadata | Nur Metadaten, oft schon ein Datenstück | Wenn Dauer/Abmessungen früh nötig sind | Kann mehr laden als gedacht |
| auto | Potenziell die ganze Datei | Nur bei sehr hoher Abspielwahrscheinlichkeit | Teuer auf dem Ladepfad |
| autoplay | Lädt sofort, Vorrang vor preload | Kurze, stumme Hero-Loops | Bytes sofort, Poster als Fallback |
Autoplay-Videos und ihre Kosten
Autoplay ist beliebt: 23 Prozent (HTTP Archive Web Almanac) der Video-Elemente starten automatisch, drei Prozentpunkte mehr als 2022. Der Preis ist selten sichtbar, aber real. Ein Autoplay-Video beginnt sofort zu laden, sobald die Seite geparst wird - auch dann, wenn es außerhalb des sichtbaren Bereichs liegt (web.dev). Damit konkurriert es genau in dem Moment um Bandbreite, in dem der Browser das erste sichtbare Bild aufbauen sollte. Ein Hero-Video, das autoplayt, lädt seine Bytes also parallel zum Rest der Seite und kann den LCP-Pfad ausbremsen, obwohl der Nutzer das Video noch gar nicht bewusst wahrgenommen hat.
Soll ein Video als Endlos-Loop laufen - die klassische GIF-Rolle -, braucht es die Attribute autoplay, muted, loop und playsinline zusammen (web.dev): stumm, damit der Browser den Start überhaupt erlaubt, und playsinline, damit es auf Mobilgeräten nicht in den Vollbildmodus springt. Wichtig ist, die Last zu begrenzen: loading=lazy verschiebt das Laden von Poster und Video, bis das Element in die Nähe des Viewports scrollt (MDN). Ein Hintergrund-Loop im unteren Seitendrittel muss so nicht beim ersten Byte konkurrieren. Dasselbe Denken in Ladeprioritäten steht hinter Lazy Loading und Code-Splitting.
Autoplay ist kein Gratis-Effekt. Jedes automatisch startende Video lädt seine Bytes genau dann, wenn die Seite ihre Aufmerksamkeit auf das erste sichtbare Bild richten sollte. Die Frage ist nicht, ob ein Video autoplayt, sondern ob es das im sichtbaren Bereich und mit begrenztem Gewicht tut.
Moderne Codecs und Container: kleinere Dateien
Der größte Hebel bei Videogewicht ist das Format. web.dev zeigt an einem konkreten Beispiel, wie stark der Unterschied ausfällt: Dieselbe Animation wiegt als GIF 3,7 MB, als MP4 (H.264) nur noch 551 KB und als WebM (VP9) sogar nur 341 KB (web.dev) - das WebM ist damit rund 91 Prozent (web.dev) kleiner als das ursprüngliche GIF. Der Container (MP4, WebM) und der Codec darin (H.264, VP9, AV1) bestimmen gemeinsam die Dateigröße. AV1 komprimiert dabei in der Regel noch stärker als VP9 (web.dev), erfordert aber wegen der Geräteunterstützung einen Fallback.
In der Praxis dominiert bislang ein einziges Format: 68 Prozent (HTTP Archive Web Almanac) der ausgelieferten Videodateien sind MP4, während WebM nur auf 1 Prozent (HTTP Archive Web Almanac) kommt. Der Grund liegt oft in der Einbindung: 42,5 Prozent (HTTP Archive Web Almanac) der Video-Elemente haben überhaupt kein source-Kind, weitere 48,9 Prozent (HTTP Archive Web Almanac) nur ein einziges - der modernere Fallback fehlt also fast überall. Dabei genügt eine Reihenfolge mehrerer source-Elemente: Der Browser wählt das erste Format, das er abspielen kann (web.dev). Wer AV1 oder WebM zuerst listet und MP4 als sichere Rückfalloption anhängt, liefert modernen Browsern die kleinere Datei, ohne ältere auszusperren. Die gleiche Format-vor-Fallback-Logik gilt bei Bildern, wie unser Beitrag zu WebP und AVIF zeigt.
<!-- Reihenfolge = Prioritaet: erst das kleinste Format, dann Fallback -->
<video poster="/media/loop-poster.webp" autoplay muted loop
playsinline preload="none" width="960" height="540">
<source src="/media/loop.av1.mp4"
type="video/mp4; codecs=av01.0.05M.08">
<source src="/media/loop.webm" type="video/webm">
<source src="/media/loop.mp4" type="video/mp4">
</video>Container bewusst wählen
MP4 ist die sichere Basis, WebM häufig kleiner. Mehrere source-Elemente liefern das kleinste abspielbare Format und behalten MP4 als Rückfalloption - ohne dass ältere Geräte leer ausgehen.
Codec nach Support staffeln
AV1 komprimiert stärker als VP9, VP9 stärker als H.264. Das effizienteste Format steht zuerst, das breit unterstützte H.264 zuletzt - so gewinnt jeder Browser die für ihn kleinste Datei.
Poster als modernes Bild
Das Poster ist ein normales Bild und gehört als WebP oder AVIF ausgeliefert. Klein, schnell und mit festen Abmessungen versehen trägt es den ersten Eindruck, bevor der erste Videoframe steht.
Adaptive Auflösungen: das richtige Video je Gerät
Ein einzelnes großes MP4 zwingt jedes Gerät, dieselbe Datei zu laden - das Smartphone im Mobilnetz ebenso wie den Desktop am Glasfaseranschluss. Adaptives Streaming löst das, indem es das Video in kurze Segmente in mehreren Auflösungen zerlegt und der Browser je nach verfügbarer Bandbreite die passende Stufe wählt. In den Felddaten zeigt sich dieser Ansatz deutlich: Rund 27 Prozent (HTTP Archive Web Almanac) der ausgelieferten Videoinhalte kommen bereits über adaptive Formate - sichtbar an Segmentdateien ohne klassische Endung sowie an .ts- und .m4s-Segmenten des adaptiven Streamings.
Nicht jedes Video braucht adaptives Streaming
Fassaden für eingebettete Player
Ein eingebetteter Video-Player eines externen Dienstes bringt sein eigenes JavaScript mit - und das ist teuer. Nach Daten von web.dev blockiert ein solcher Player-Embed den Main-Thread im Median um mehr als 1,7 Sekunden (web.dev), noch bevor ein einziger Frame läuft. Die Antwort ist das Fassaden-Muster: Statt des vollen Players zeigt die Seite zunächst nur ein leichtes, statisches Vorschaubild mit Abspielknopf, das dem echten Player ähnelt. Erst der Klick lädt das eigentliche Embed nach. So entsteht der Playerscript-Overhead genau dann, wenn der Nutzer ihn wirklich anfordert - und nicht bei jedem Seitenaufruf.
Die Einsparung ist erheblich. Nach Daten von web.dev lässt sich durch das verzögerte Laden eines Video-Embeds rund 500 Kilobyte (web.dev) auf dem initialen Ladepfad sparen, und Seiten mit Fassaden-Muster zeigen einen im Schnitt 800 Millisekunden (web.dev) schnelleren LCP als Seiten, die das Embed direkt laden. Da viele Videos nur von einem Bruchteil der Besucher gestartet werden, verschiebt die Fassade die Last vom Regelfall in den Ausnahmefall. Dasselbe Prinzip nutzt die Entschlackung von Third-Party-Skripten für Chat-Widgets und Karten.
Statisches Vorschaubild
Die Fassade zeigt das Thumbnail des Videos plus einen Abspielknopf. Sie sieht aus wie der echte Player, lädt aber kein Drittanbieter-JavaScript - nur ein Bild und etwas CSS.
Preconnect beim Hover
Berührt der Nutzer die Fassade mit der Maus, wird vorab eine Verbindung zum Video-Dienst aufgebaut. So sinkt die Latenz beim eigentlichen Klick, ohne vorher Daten zu laden.
Austausch beim Klick
Erst der Klick lädt den vollständigen Player und ersetzt die Fassade. Der Nutzer bekommt den vollen Funktionsumfang - aber nur, wenn er ihn tatsächlich anfordert.
Overhead nur auf Anforderung
Der Umsetzungspfad in der Praxis
Video-Performance ist kein einzelner Kniff, sondern eine Kette von Entscheidungen: das richtige erste Bild, die sparsame Ladehaltung, das kleinste Format und die entkoppelte Einbindung. Der verlässliche Weg beginnt mit der Messung - welches Element bestimmt den LCP, wie schwer ist jedes Video, welcher Player bringt wie viel Skript mit. Aus dieser Diagnose entsteht ein priorisierter Plan, der die größten Hebel zuerst zieht.
- Zuerst messen, welches Element den LCP bestimmt - Poster, Videoframe oder ein anderes Bild
- Hero-Videos ein Poster geben, es als WebP oder AVIF ausliefern und mit fetchpriority vorladen
- preload=none plus Poster für Videos ohne Autoplay - keine Videobytes vor dem Klick
- Autoplay-Loops stumm, mit playsinline und begrenztem Gewicht, außerhalb des Viewports per loading=lazy
- Mehrere source-Elemente listen: AV1 oder WebM zuerst, MP4 als sichere Rückfalloption
- Lange Videos adaptiv streamen, kurze Loops in zwei bis drei festen Auflösungen
- Eingebettete Player als Fassade laden - der Playerscript-Overhead entsteht erst beim Klick
- Feste Abmessungen setzen, damit kein Layout-Sprung den CLS verschlechtert
Genau diese Kette setzen wir in der Frontend-Optimierung um - von der Diagnose des LCP-Elements über Poster, preload und Codec bis zur Fassade für Player. Wie sich Media-Last in konkreten Systemen zeigt, vertiefen die Beiträge zur Shopware-Performance und zu den häufigen Bremsen in WordPress. Und welches Video auf Ihren Seiten tatsächlich am schwersten wiegt, zeigt eine strukturierte Performance-Analyse, bevor eine einzige Zeile geändert wird.
Quellen und Studien