siteway

// stack · media

WebM.

Video für die Website, ohne Ballast: WebM ist der offene, lizenzfreie Container mit den Codecs VP9 und AV1 — bei vergleichbarer Qualität spürbar kleiner als ein MP4 mit H.264. Bei siteway steht WebM als erste Quelle im <video>-Element, das MP4 folgt als zweite — und der Browser lädt genau eine Datei.

stack stack: webm · video/webm codecs: vp9 · av1 · opus format seit: 2010

// definition

Was ist WebM?

WebM ist ein offener, lizenzfreier Container für Video im Web, den Google 2010 veröffentlicht hat — nach der Übernahme des Codec-Entwicklers On2 Technologies. Er nimmt die Videocodecs VP8, VP9 und AV1 sowie die Audiocodecs Opus und Vorbis auf. Der MIME-Typ lautet video/webm, die Dateiendung .webm.

Technisch ist WebM eine bewusst schlanke Variante des Matroska-Containers: nur die Codecs, die frei nutzbar sind, nur die Strukturen, die ein Browser fürs Streaming braucht. Wichtig ist die Unterscheidung zwischen Container und Codec — .webm ist die Verpackung, die Kompressionsleistung bringt der Codec darin. Wie WebM im Zusammenspiel mit AVIF und WebP ausgeliefert wird, steht im Überblick Bild- & Videoformate.

// praxis

Wie wir WebM einsetzen.

erste quelle, mp4 dahinter

Wie beim Bild liefern wir auch beim Video mehrere Quellen in fester Reihenfolge aus. Im <video>-Element steht WebM als erste <source> mit type="video/webm", das MP4 mit H.264 als zweite. Der Browser prüft von oben nach unten und lädt genau eine Datei: aktuelle Geräte bekommen das kleinere WebM, ältere das MP4, das jedes Gerät seit Jahren in Hardware dekodiert und damit schonend für den Akku.

Für Hintergrund- und Teaser-Clips gilt bei uns ein festes Muster: autoplay muted playsinline loop. Stumm ist die Bedingung dafür, dass Browser das automatische Abspielen überhaupt erlauben, playsinline hält den Clip auf dem iPhone im Layout statt im Vollbild. Dazu immer ein poster-Bild als erster sichtbarer Frame — ausgeliefert als AVIF oder WebP über dieselbe Kette wie jedes andere Bild.

Geladen wird so wenig wie möglich: preload="metadata" für den sichtbaren Bereich, preload="none" für alles, was erst beim Scrollen erscheint — die Quelle setzt dann ein IntersectionObserver, wenn der Clip wirklich gebraucht wird. Die Dateien liegen auf unserer eigenen Auslieferung und gehen denselben Weg wie der Rest der Seite: über Git und GitHub Actions aufs Ziel. So bleiben Ladeverhalten, Caching-Regeln und Daten in deiner Hand — ein Punkt, der bei Datenschutz zählt und ganz nebenbei jede Anfrage an Dritte einspart. Längere Formate und ganze Mediatheken gehören dagegen in einen Streaming-Dienst, weil dort adaptives Streaming die Auslieferung übernimmt.

// datenpunkt · bitrate

Wie viel WebM spart.

der codec macht’s, nicht der container

Die Ersparnis kommt vom Codec, nicht von der Verpackung. VP9 braucht bei vergleichbarer Qualität je nach Material 20 bis 50 % weniger Bitrate als H.264 — in der Praxis liegt der Wert oft um ein Drittel. AV1 legt gegenüber VP9 noch einmal rund 30 % nach.

Der Preis dafür ist Rechenzeit beim Kodieren: AV1 dauert um ein Vielfaches länger als H.264. Für kurze Schleifen im Hintergrund ist VP9 deshalb meist der beste Kompromiss, AV1 nehmen wir dort, wo jedes Byte zählt. Wie stark das durchschlägt, zeigt sich direkt im Largest Contentful Paint — Video ist auf jeder Seite, die eins hat, der größte Einzelposten.

// relative bitrate bei vergleichbarer qualität
H.264 · MP4 100 % VP9 · WebM −20…50 % AV1 · WebM −30 % vs. vp9 0 H.264 = 100 %

quelle: Google (WebM-Projekt) und veröffentlichte Codec-Vergleiche; balken = typische Größenordnung, nicht ein einzelner Messwert

// bausteine · 6 details

Was WebM ausmacht.

container, codecs, auslieferung

WebM ist eine Verpackung mit klaren Regeln: nur offene Codecs, nur das, was ein Browser zum Abspielen braucht. Das sind die Bausteine, die in unseren Projekten tatsächlich zum Tragen kommen.

// d-01container

Offener Container.

Ein schlankes Matroska-Profil, gebührenfrei nutzbar und auf Streaming ausgelegt. Keine Lizenzfrage, keine Sonderrechte — der Grund, warum WebM überall dort auftaucht, wo offene Web-Standards zählen.

basis: matroska

// d-02codec

VP9.

Der Arbeitscodec: breit unterstützt, in vielen Geräten hardwarebeschleunigt und je nach Material 20 bis 50 % sparsamer als H.264. Für kurze Schleifen und Teaser der beste Kompromiss aus Größe und Kodierzeit.

standard: seit 2013

// d-03codec

AV1.

Die nächste Stufe aus derselben Familie wie AVIF: noch einmal rund 30 % unter VP9, dafür deutlich teurer beim Kodieren. Passt, wenn eine Datei sehr oft ausgeliefert wird.

stärke: maximale kompression

// d-04audio

Opus & Vorbis.

Die Tonspuren im Container. Opus ist der modernere der beiden und liefert bei niedrigen Bitraten hörbar bessere Qualität als MP3 oder AAC — relevant überall dort, wo Sprache verständlich bleiben muss.

ton: opus · vorbis

// d-05auslieferung

video-Element.

Mehrere source-Angaben untereinander, WebM zuerst, MP4 danach. Der Browser wählt selbst und lädt genau eine Datei — dieselbe Mechanik wie beim picture-Element für Bilder, ohne eine Zeile JavaScript.

zweck: fallback-kette

// d-06ladeverhalten

poster & preload.

Das poster-Bild ist der erste sichtbare Frame und zugleich der Hebel fürs LCP. preload steuert, wie viel vorab geholt wird: metadata im Sichtbereich, none für Clips weiter unten auf der Seite.

zweck: früher erster frame

// support

Browser-Support.

safari ist dabei

Lange war WebM das Format, das überall lief — außer bei Apple. Das hat sich erledigt: Safari auf dem Mac spielt WebM seit Version 16 ab, auf dem iPhone ist es flächendeckend seit iOS 17.4 dabei. Chrome, Firefox, Edge und Opera liefern es seit vielen Jahren. Nach den Zahlen von caniuse.com liegt die weltweite Abdeckung damit bei rund 96 %.

Die verbleibenden Prozent sind im Wesentlichen ältere iOS-Geräte ohne Update-Pfad — dazu kommen Randfälle wie VP9 mit ungewöhnlicher Farbunterabtastung, die Safari nicht in jeder Variante annimmt. Genau deshalb steht bei siteway nie ein WebM allein: Das MP4 mit H.264 als zweite Quelle kostet in der Auslieferung nichts, weil der Browser ohnehin nur eine Datei lädt — und es dekodiert auf praktisch jedem Gerät in Hardware, was auf Mobilgeräten Akku spart.

// messwerte

Video und Core Web Vitals.

das poster entscheidet über lcp

Ein Video im sichtbaren Bereich ist fast immer das größte Element der Seite — und damit direkt an den Messwerten beteiligt, die Google auswertet. Drei Stellschrauben entscheiden, ob es hilft oder bremst.

// cwv-01lcp

Largest Contentful Paint.

Bei einem video-Element zählt Chrome das poster-Bild oder den ersten gezeichneten Frame als LCP-Kandidat — je nachdem, was früher da ist. Ein schlankes poster als AVIF oder WebP ist deshalb der wirksamste Hebel.

hebel: poster zuerst

// cwv-02cls

Cumulative Layout Shift.

Feste width- und height-Attribute am video-Element geben dem Browser das Seitenverhältnis, bevor eine Datei da ist. Der Platz steht sofort — das Layout springt nicht, wenn der Clip einsetzt.

hebel: feste maße

// cwv-03bandbreite

Bandbreite & preload.

Ein Video, das im Hintergrund lädt, konkurriert mit Schrift, CSS und LCP-Bild um dieselbe Leitung. Deshalb: preload sparsam setzen, Clips unterhalb des Sichtbereichs erst beim Heranscrollen anfordern.

hebel: später laden

vitals lcp-kandidat: poster · erster frame cls: width/height gesetzt performance im stack →

// barrierefreiheit

Video für alle.

bewegung auf wunsch

Bewegtbild ist der Ort, an dem Barrierefreiheit am schnellsten sichtbar wird. Wer im Betriebssystem reduzierte Bewegung eingestellt hat, bekommt bei uns über die Media-Query prefers-reduced-motion das poster-Bild statt der laufenden Schleife — dieselbe Aussage, ohne Bewegung. Automatisch startende Clips laufen grundsätzlich stumm, und alles, was länger als fünf Sekunden läuft, lässt sich anhalten. So verlangt es die WCAG in Erfolgskriterium 2.2.2.

Sobald Sprache im Spiel ist, kommt Text dazu: eine WebVTT-Datei über <track kind="captions"> für Untertitel, dazu ein Transkript im Seitentext — das hilft nicht nur beim Zuhören, sondern macht den Inhalt auch für Suchmaschinen und Sprachmodelle lesbar. Inhaltliche Videos bekommen sichtbare controls, damit sie sich mit der Tastatur bedienen lassen. Der ganze Rahmen dazu steht unter Barrierefreiheit im Stack.

// entscheidung

MP4 oder WebM?

im web: beides

Auf einer Website stellt sich die Frage nicht — dort liegen beide Dateien im <video>-Element, und der Browser wählt. Eine echte Entscheidung wird daraus erst, wenn nur eine Datei möglich ist: in einem Newsletter, in einem Export, in einer App-Vorschau. So gehen wir dann vor.

// e-01webm

WebM zuerst.

Für alles, was im Browser läuft: kurze Hintergrundschleifen, Teaser, Produktdemos, UI-Aufnahmen. Kleinere Datei bei gleicher Qualität, offener Codec, keine Lizenzfrage — und der Löwenanteil der Besucher bekommt genau diese Variante.

stärke: weniger bytes

// e-02mp4

MP4 dahinter.

H.264 im MP4 ist die Universalsprache für Bewegtbild: Jedes Gerät dekodiert es in Hardware, jedes Werkzeug öffnet es. Als zweite Quelle sichert es ältere iPhones ab — und ist die richtige Wahl, wenn nur eine einzige Datei möglich ist.

stärke: läuft überall

// e-03andere wege

Andere Wege.

Sekundenkurze UI-Schleifen liegen oft besser als animiertes WebP. Lange Formate und ganze Mediatheken gehören in einen Streaming-Dienst mit adaptiver Bitrate — dort spielt Technik ihre Stärke aus, die eine einzelne Datei nicht hat.

passt: webp · streaming

weiche im browser: webm + mp4 nur eine datei: mp4 alle formate im überblick →

// faq

Häufige Fragen.

Was ist WebM?

WebM ist ein offener, lizenzfreier Container für Video im Web, den Google 2010 veröffentlicht hat — nach der Übernahme des Codec-Entwicklers On2 Technologies. Der Container ist eine schlanke Variante von Matroska und nimmt die Videocodecs VP8, VP9 und AV1 sowie die Audiocodecs Opus und Vorbis auf. Der MIME-Typ lautet video/webm, die Dateiendung .webm. Praktisch heißt das: dieselbe Szene in einer deutlich kleineren Datei als beim klassischen MP4 mit H.264, ohne Lizenzgebühren und ohne externen Player. siteway liefert WebM als erste Quelle im video-Element aus, MP4 folgt als zweite.

MP4 oder WebM — was soll ich nehmen?

Beides, und zwar in einem Zug. Im video-Element stehen mehrere source-Angaben untereinander: WebM zuerst, MP4 mit H.264 danach. Der Browser nimmt die erste Quelle, die er abspielen kann, und lädt genau eine Datei. So bekommen aktuelle Browser die kleinere WebM-Datei, ältere Geräte bleiben beim MP4, das praktisch jedes Gerät in Hardware dekodiert. Die Frage MP4 oder WebM stellt sich damit nur dort, wo wirklich nur eine einzige Datei möglich ist — etwa in einem Newsletter oder in einer App-Vorschau. Dann ist MP4 die sichere Wahl.

Welche Browser unterstützen WebM?

Chrome, Firefox, Edge und Opera seit vielen Jahren, Safari auf dem Mac seit Version 16 und auf dem iPhone flächendeckend seit iOS 17.4. Nach den Zahlen von caniuse.com liegt die weltweite Abdeckung damit bei rund 96 Prozent. Die letzten Prozent sind vor allem ältere iOS-Geräte, die kein Update mehr bekommen. Genau dafür liegt das MP4 als zweite Quelle im video-Element — es kostet in der Auslieferung nichts, weil der Browser ohnehin nur eine der beiden Dateien lädt.

Wie viel kleiner ist WebM als MP4?

Das hängt am Codec, nicht am Container. VP9 in einer WebM-Datei braucht bei vergleichbarer Qualität je nach Material 20 bis 50 Prozent weniger Bitrate als H.264 in einem MP4, in der Praxis liegt der Wert oft um ein Drittel. AV1 legt gegenüber VP9 noch einmal rund 30 Prozent nach, kostet aber deutlich mehr Rechenzeit beim Kodieren. Für kurze Hintergrund- und Teaser-Clips setzt siteway deshalb meist auf VP9 und hebt AV1 für die Fälle auf, in denen jedes Byte zählt.

Wie bindet siteway ein Hintergrundvideo ein?

Als stummes Video im video-Element, mit autoplay, muted, playsinline und loop. Stumm ist dabei die Bedingung dafür, dass Browser das automatische Abspielen überhaupt erlauben, und playsinline hält den Clip auf dem iPhone im Layout statt im Vollbild. Dazu kommt immer ein poster-Bild als erster sichtbarer Frame, feste Werte für width und height gegen springendes Layout und ein preload, das zum Ort auf der Seite passt: metadata oben im Sichtbereich, none für alles, was erst beim Scrollen erscheint. Das Video liegt auf unserer eigenen Auslieferung, sodass Ladeverhalten und Daten in deiner Hand bleiben.

Was bedeutet Video für die Core Web Vitals?

Vor allem etwas für das Largest Contentful Paint. Bei einem video-Element zählt Chrome das poster-Bild oder den ersten gezeichneten Videoframe als LCP-Kandidat — je nachdem, was früher da ist. Ein schlankes poster-Bild als AVIF oder WebP ist deshalb der wirksamste Hebel: Es erscheint lange vor dem ersten Frame und setzt den LCP-Zeitpunkt. Feste Abmessungen halten das Cumulative Layout Shift bei null, und ein sparsames preload sorgt dafür, dass der Clip keine Bandbreite von den wichtigen Ressourcen abzieht.

Wie wird ein Video barrierefrei?

Über drei Dinge. Erstens Untertitel: Für Videos mit Sprache hinterlegen wir eine WebVTT-Datei über ein track-Element mit kind=captions, dazu ein Transkript im Text der Seite. Zweitens Bewegung auf Wunsch: Wer im Betriebssystem reduzierte Bewegung eingestellt hat, bekommt über prefers-reduced-motion das poster-Bild statt der laufenden Schleife. Drittens Ton und Kontrolle: Automatisch startende Videos laufen stumm, und alles, was länger als fünf Sekunden läuft, lässt sich anhalten — so verlangt es die WCAG. Mehr dazu unter Barrierefreiheit.

// Video, das die Seite nicht ausbremst?

Projekt anfragen