Videos fürs Web optimieren: unsere ffmpeg-Pipeline

Warum ist Web-Video etwas anderes als ein Video komprimieren?

Ein Video für den Versand zu verkleinern und ein Video fürs Web zu optimieren sind zwei verschiedene Aufgaben. Beim Versand zählt nur die Dateigröße. Im Web zählt, wie schnell das Video zu spielen beginnt, ob es auf jedem Gerät läuft und ob es deine Ladezeit und damit deine Core Web Vitals kaputtmacht. Ein 200-MB-Hero-Video bremst deine Seite aus, egal wie schön es ist.

Es geht also nicht nur um Kompression, sondern um drei Dinge gleichzeitig: das richtige Format und den richtigen Codec, eine saubere Komprimierung mit den passenden Werten und eine Auslieferung, die progressiv lädt statt alles auf einmal. Genau diese drei Schichten gehen wir hier durch, mit konkreten ffmpeg-Befehlen aus unserer echten Pipeline. Wir bauen bei INSYNC viel Motion und Video ins Web ein, deshalb ist das keine Theorie, sondern der Weg, wie wir es täglich machen.

Welches Videoformat und welcher Codec fürs Web?

Zuerst die Begriffe sauber trennen, weil sie ständig verwechselt werden. Ein Container (MP4, WebM) ist die Verpackung: Er hält Bild, Ton, Untertitel und Metadaten zusammen. Ein Codec (H.264, VP9, AV1) ist das Verfahren, mit dem das Bild komprimiert wird. Ein MP4 ist also nicht automatisch H.264, und WebM nicht automatisch VP9, auch wenn das die üblichen Paarungen sind.

Fürs Web sind vier Codecs relevant. Die Wahl ist ein Kompromiss aus Kompressionseffizienz, Encoding-Tempo und Wiedergabe-Kompatibilität. Faustregel: H.264 als universelle Basis, VP9 oder AV1 als sparsame Variante mit H.264-Fallback.

MP4 mit H.264 (der sichere Default)

H.264, auch AVC genannt, ist der Quasi-Standard für Webvideo. Rund 84 bis 86 Prozent der Video-Industrie nutzen ihn, und er läuft auf über 99 Prozent aller Browser und Geräte, inklusive Hardware-Decoding. Encoder ist libx264. H.264 liefert bei geringer Dateigröße eine sehr gute Qualität und ist immer die Basis, wenn wirklich jeder das Video sehen soll. Wenn du nur ein einziges Format ausliefern kannst, dann dieses.

H.265/HEVC

H.265 (HEVC, Encoder libx265) komprimiert bei gleicher Qualität rund 35 bis 45 Prozent kleiner als H.264. Der Haken: Es ist lizenzpflichtig, das Encoding dauert 3 bis 5 mal so lange, und die Browser-Unterstützung ist gespalten. Safari und die Apple-Welt spielen es nativ, Chrome und Firefox lange nicht zuverlässig. Fürs offene Web ist HEVC deshalb selten die erste Wahl, im reinen Apple-Umfeld dagegen stark.

WebM mit VP9

VP9 (Encoder libvpx-vp9) ist Googles lizenzfreie Antwort auf H.265: ebenfalls rund 35 bis 45 Prozent kleiner als H.264, dafür ohne Lizenzgebühren. Chrome, Firefox und Edge unterstützen es gut, Safari nur eingeschränkt. Es sitzt üblicherweise im WebM-Container mit Opus als Audio-Codec. Für Web-First-Projekte, in denen Chrome und Firefox dominieren, ist VP9 die naheliegende Sparvariante als Ergänzung zu H.264.

AV1 (die beste Kompression)

AV1 (Encoder libaom-av1 oder das deutlich schnellere libsvtav1) ist der lizenzfreie Codec der Alliance for Open Media und komprimiert rund 50 bis 60 Prozent kleiner als H.264. 2026 ist AV1 für die Auslieferung produktionsreif: Chrome, Firefox, Edge und Safari ab Version 17 unterstützen es, Hardware-Decode deckt rund 80 Prozent der Streaming-Geräte ab. Über 75 Prozent der YouTube-Wiedergabe läuft inzwischen über AV1. Der Haken bleibt das Encoding: Mit libaom ist es extrem langsam (20 bis 50 mal H.264), mit SVT-AV1 praktikabel (3 bis 8 mal). Ältere Geräte brauchen weiter einen H.264-Fallback. Kombiniert man AV1 und HEVC, deckt man über 99 Prozent der Sessions ab.

Wie komprimierst du ein Video mit ffmpeg richtig?

ffmpeg ist das Werkzeug, mit dem sich Format, Codec und Kompression präzise steuern lassen, ohne Cloud, ohne Upload, ohne Lizenzsoftware. Wenn du lieber grafisch arbeitest, macht HandBrake im Prinzip dasselbe. Komprimieren läuft dabei auf drei Regler hinaus: CRF für die Qualität, Preset für das Encoding-Tempo und den Codec für die Effizienz. Wer diese drei versteht, kommt mit fast jeder Anforderung zurecht.

CRF statt fester Bitrate

CRF (Constant Rate Factor) ist die wichtigste Einstellung. Statt einer festen Bitrate gibst du eine Zielqualität vor, und der Encoder verteilt die Bits, wo sie gebraucht werden: mehr für komplexe Szenen, weniger für ruhige. Niedriger CRF heißt bessere Qualität und größere Datei. Bei H.264 reicht die Skala von 0 (verlustfrei) bis 51. Der Sweet Spot fürs Web liegt bei CRF 18 bis 28, CRF 23 ist der solide Default. Bei H.265 und AV1 ist die Skala verschoben: CRF 28 in H.265 entspricht etwa CRF 23 in H.264.

Eine feste Bitrate brauchst du nur, wenn du eine harte Dateigröße treffen musst. Dann nutzt du Two-Pass-Encoding: Im ersten Durchlauf analysiert ffmpeg das Video, im zweiten encodet es mit optimaler Bitverteilung. Fürs Web ist CRF fast immer die bessere Wahl.

Auflösung, Framerate und Preset

Für die meisten Websites reicht Full HD (1920x1080). 4K sieht auf großen Screens edel aus, vervielfacht aber die Dateigröße, oft ohne sichtbaren Gewinn. Bei kleiner eingebundenen Videos tun es 720p oder weniger. Skaliere nie hoch, das verbrennt nur Bandbreite. Beim Herunterskalieren liefert der Lanczos-Filter die beste Qualität.

Die Framerate lässt du meist bei 24 bis 30 fps, mehr lohnt selten. Das Preset steuert, wie viel Rechenzeit ffmpeg ins Optimieren steckt: medium ist der Default und Sweet Spot, slow spart nur wenige Prozent bei stark längerer Encoding-Zeit. Grobe Bitrate-Orientierung für H.264: 1080p rund 4 bis 8 Mbit/s, 720p rund 2 bis 4 Mbit/s. Bei H.265 und AV1 etwa die Hälfte.

Die konkreten ffmpeg-Befehle

Hier sind die Befehle, die bei uns tatsächlich im Einsatz sind. Der erste ist der Standard fürs Web: H.264, CRF 23, faststart für progressives Laden.

Standard-Web-Video (H.264, universell): ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -vf "scale=1920:-2:flags=lanczos" -c:a aac -b:a 128k -movflags +faststart output.mp4

Sparvariante VP9 (WebM, lizenzfrei): ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -row-mt 1 -c:a libopus -b:a 128k output.webm

Beste Kompression AV1 (moderne Geräte, mit H.264-Fallback ausliefern): ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

Stummes Hintergrund-Video ohne Ton (Hero, Autoplay): ffmpeg -i input.mp4 -an -c:v libx264 -crf 24 -preset medium -vf "scale=1920:-2:flags=lanczos" -movflags +faststart hero.mp4

Poster-Frame als Standbild extrahieren: ffmpeg -i input.mp4 -ss 00:00:01 -frames:v 1 -q:v 2 poster.jpg

Das -movflags +faststart schiebt die Metadaten an den Dateianfang. Ohne diese Flag beginnt das Video erst zu spielen, wenn die gesamte Datei geladen ist. Sie ist fürs Web nicht optional.

Wie lieferst du Video aus, ohne die Ladezeit zu killen?

Das beste Encoding hilft nichts, wenn das Video falsch eingebunden ist. Vier Hebel entscheiden, ob dein Video die Seite bremst oder unsichtbar schnell lädt. Sie kosten kaum Aufwand und wirken direkt auf deine Core Web Vitals.

Lazy-Loading und das preload-Attribut

Ein Video, das erst weit unten auf der Seite steht, muss nicht sofort mitgeladen werden. Setz preload="none" oder preload="metadata", damit der Browser nicht die ganze Datei vorab zieht. Videos, die erst beim Scrollen sichtbar werden, lädst du per IntersectionObserver nach. So blockiert das Video nicht den initialen Seitenaufbau, und dein Largest Contentful Paint bleibt schnell.

Autoplay, muted und playsinline

Wenn ein Hintergrund-Video automatisch spielen soll, muss es stumm sein. Browser blockieren Autoplay mit Ton grundsätzlich. Die Kombination lautet autoplay muted playsinline loop. playsinline verhindert, dass iOS das Video in den Vollbildmodus zwingt. Und weil das Video ohnehin stumm läuft, encodest du es am besten ganz ohne Audiospur (-an spart die Tonspur komplett). Ein Hero-Video ist ein Design-Element, kein Medienplayer.

Poster-Frame als sofortiges Standbild

Das poster-Attribut zeigt sofort ein Standbild, während das Video im Hintergrund lädt. Ohne Poster sieht der Nutzer eine leere Fläche, was den wahrgenommenen Ladevorgang schlechter macht und ein Layout-Sprung-Risiko schafft. Extrahiere den Poster-Frame direkt aus dem Video (siehe ffmpeg-Befehl oben) und liefere ihn als optimiertes JPG oder WebP aus. Auf schwachen Verbindungen ist der Poster oft alles, was der Nutzer in den ersten Sekunden sieht.

Adaptives Streaming und CDN

Eine einzige Videodatei funktioniert nie für alle gleich gut: Auf schwachem Netz lädt eine 1080p-Datei nicht, auf schnellem Anschluss ärgert ein zu stark komprimiertes Bild. Adaptives Streaming über HLS oder MPEG-DASH liefert automatisch die passende Qualitätsstufe je nach Verbindung und Bildschirm. Für kurze Hero-Loops ist das Overkill, für längere Inhaltsvideos lohnt es sich. Unabhängig davon gilt: Liefere Video über ein CDN aus, nicht direkt vom eigenen Server. Das verteilt die Last, verkürzt die Wege zum Nutzer und hält deinen Origin-Server frei.

Solltest du selbst hosten oder YouTube und Vimeo nutzen?

Die Entscheidung hängt vom Zweck ab. Selbst gehostetes Video gibt dir volle Kontrolle über Aussehen, Ladeverhalten und Datenschutz: kein fremdes Branding, keine Cookie-Banner, keine externen Tracking-Abfragen, saubere Integration ins Design. Der Preis ist Aufwand: Du kümmerst dich um Encoding, mehrere Versionen und Auslieferung selbst. Für Hero-Loops, kurze stumme Design-Videos und alles, was nahtlos zur Marke gehören soll, ist Self-Hosting fast immer richtig.

YouTube und Vimeo lohnen sich für lange Inhaltsvideos, Tutorials oder Reichweite über die Plattform selbst. Sie übernehmen adaptives Streaming und globale Auslieferung, bringen aber fremdes Branding, Empfehlungen zu Wettbewerbern und in der DSGVO-Welt Consent-Pflichten mit. Ein Kompromiss sind spezialisierte, DSGVO-konforme Hosting-Dienste, die das Encoding automatisieren, ohne Cookie-Banner. Für eine Premium-B2B-Seite, bei der jedes Detail sitzen soll, wählen wir in der Regel Self-Hosting mit sauberer eigener Pipeline.

Muss Web-Video barrierefrei sein?

Ja, und seit dem Barrierefreiheitsstärkungsgesetz (BFSG) ist das für viele Unternehmen ab 2025 Pflicht, nicht Kür. Praktisch heißt das dreierlei. Erstens: Untertitel gehören nicht ins Video eingebrannt, sondern als separate Spur (etwa WebVTT), die sich ein- und ausschalten lässt. Zweitens: Wo Ton Information trägt, braucht es ein Transkript oder eine Audiodeskription. Drittens: Der Player selbst muss per Tastatur bedienbar sein und darf nichts automatisch mit Ton abspielen.

Für stumme Hintergrund-Loops ist der Aufwand gering, weil sie keine Information transportieren. Sobald ein Video aber Inhalt vermittelt, plane Untertitel und Transkript von Anfang an mit ein, nicht als Nachtrag. Mehr dazu in unserem Leitfaden zur barrierefreien Website.

Was bringt das für deine Website?

Richtig optimiertes Web-Video ist der Unterschied zwischen einer Seite, die mit Motion beeindruckt, und einer, die daran erstickt. Ein sauber encodetes, faststart-fähiges, lazy geladenes Hero-Video mit Poster fühlt sich sofort an, obwohl im Hintergrund Megabytes fließen. Dasselbe Video, unkomprimiert und blockierend eingebunden, ruiniert deinen Largest Contentful Paint und schickt Nutzer wieder weg, bevor sie überhaupt etwas gesehen haben.

Genau hier arbeiten wir bei INSYNC: Wir bauen B2B-Websites mit viel Motion und Video, ohne dass die Performance darunter leidet. Encoding-Pipeline, Auslieferung und Design entstehen zusammen, nicht nacheinander. So bekommst du den visuellen Eindruck einer High-End-Seite und trotzdem Ladezeiten, die deine Core Web Vitals grün halten.

Häufige Fragen