Videos fürs Web optimieren: unsere ffmpeg-Pipeline
Wie du Videos fürs Web komprimierst, ohne die Ladezeit zu killen. Codecs, konkrete ffmpeg-Befehle, Lazy-Loading und Autoplay-Attribute aus unserer echten Pipeline.
Ein 40-MB-Hero-Video sieht im Editor toll aus und macht deine Seite auf dem Handy unbenutzbar. Die üblichen Online-Tools verkleinern die Datei zwar, aber sie wissen nichts von deiner Website: nichts über den richtigen Codec, nichts über Autoplay, nichts über die Ladezeit auf mobilen Verbindungen.
Dieser Artikel zeigt, wie wir Videos wirklich fürs Web optimieren. Das ist dieselbe ffmpeg-Pipeline, mit der wir video-lastige High-End-Sites wie FRAMEN auf grüne PageSpeed-Werte bekommen. Codec-Wahl, konkrete Befehle, Auslieferung. Kein Marketing, sondern die Flags, die wir tatsächlich nutzen.
Das Wichtigste in Kürze
- Der beste Codec fürs Web ist H.264 (MP4) als kompatible Basis, plus WebM/VP9 oder AV1 als kleinere Alternative für moderne Browser.
- Komprimieren geht am saubersten mit ffmpeg über CRF statt fester Bitrate: -crf 23 für H.264, -crf 30 für VP9. Niedriger heißt bessere Qualität und größere Datei.
- Ein Web-Video sollte selten über 1080p und 30 fps liegen. Auflösung und Framerate runterzusetzen spart mehr als jeder Codec-Trick.
- Ohne Poster-Frame, Lazy-Loading und die Attribute muted, autoplay, playsinline spielt Autoplay auf iOS nicht und der erste Frame kommt zu spät.
- So bringen wir FRAMEN mit schweren Hero-Videos auf grüne Core Web Vitals: kleine Dateien, sofortiger Poster, spätes Laden, Auslieferung über ein CDN.
Warum Web-Video anders ist als ein Video komprimieren
Ein Video fürs Web zu optimieren ist nicht dasselbe wie es zu komprimieren. Komprimieren macht die Datei kleiner. Optimieren heißt, sie so aufzubauen, dass ein Browser sie schnell startet, flüssig abspielt und auf dem Handy nicht das Datenvolumen frisst.
Die Online-Tools in den Suchergebnissen (clideo, freeconvert, video-verkleinern.online) lösen nur den ersten Teil. Sie kennen deine Seite nicht. Sie wissen nicht, dass iOS ein Autoplay-Video ohne das Attribut muted blockiert, dass ein fehlender Poster-Frame deinen Largest Contentful Paint ruiniert, oder dass ein Video ohne die richtige Container-Struktur erst komplett geladen wird, bevor es startet.
Web-Video-Optimierung hat also drei Ebenen: den richtigen Codec wählen, sauber komprimieren, und dann so ausliefern, dass die Ladezeit nicht leidet. Genau diese drei Ebenen gehen wir durch.
Welches Videoformat und welcher Codec fürs Web?
Fürs Web zählen zwei Dinge: das Container-Format (die Dateiendung wie MP4 oder WebM) und der Codec darin (H.264, H.265, VP9, AV1). Der Codec bestimmt Kompression und Kompatibilität, das Format ist nur die Verpackung. Hier die vier, die praktisch relevant sind.
MP4 mit H.264
MP4 mit H.264 (auch AVC genannt) ist die sichere Basis. Es läuft in jedem Browser, auf jedem Gerät, seit über einem Jahrzehnt. Die Kompression ist nicht die effizienteste, aber die Kompatibilität ist perfekt. H.264 gehört als Fallback in jede Web-Video-Auslieferung, damit wirklich jeder Besucher etwas sieht.
H.265/HEVC
H.265, auch HEVC, komprimiert bei gleicher Qualität rund 40 bis 50 % kleiner als H.264. Der Haken: Lizenzkosten und lückenhafte Browser-Unterstützung. Safari spielt es, Chrome und Firefox lange nicht zuverlässig. Fürs offene Web ist HEVC deshalb kein guter Standard. Wir setzen es nur in geschlossenen Umgebungen ein, nicht auf öffentlichen Sites.
WebM mit VP9
WebM mit VP9 ist der lizenzfreie Standard von Google und komprimiert etwa 30 bis 50 % effizienter als H.264. Chrome, Firefox und Edge unterstützen es voll, Safari inzwischen ebenfalls. In der Praxis liefern wir VP9 als moderne Variante aus und H.264 als Fallback. Der Browser nimmt automatisch die kleinere Datei, die er versteht.
AV1
AV1 ist der derzeit effizienteste offene Codec und schlägt VP9 nochmal um rund 30 %. Der Preis ist die Encoding-Zeit: AV1 zu kodieren dauert um ein Vielfaches länger als H.264. Für ein kurzes Hero-Loop, das einmal enkodiert und tausendfach ausgeliefert wird, lohnt sich das. Für große Mengen Video eher nicht. Browser-Support ist 2026 breit, aber noch nicht überall, deshalb bleibt H.264 der Fallback.
Codecs fürs Web im Vergleich
| Codec | Effizienz | Support | Einsatz |
|---|---|---|---|
| H.264 (MP4) | Basis | Überall | Pflicht-Fallback |
| H.265/HEVC | +40–50 % | Lückenhaft | Nur geschlossen |
| VP9 (WebM) | +30–50 % | Breit | Moderne Variante |
| AV1 | +50–60 % | Wachsend | Kurze Hero-Loops |
Videos mit ffmpeg komprimieren (unsere Pipeline)
ffmpeg ist das Werkzeug, mit dem wir jedes Web-Video verarbeiten. Es ist ein Kommandozeilen-Tool, kostenlos, und gibt dir volle Kontrolle über jeden Parameter. Anders als ein Online-Tool rätst du nicht, was passiert, sondern setzt genau die Flags, die du brauchst. Die folgenden Bausteine sind die, die wir in echten Projekten einsetzen.
Bitrate oder CRF
Für Web-Video nutzt du fast immer CRF (Constant Rate Factor) statt einer festen Bitrate. CRF hält die Qualität konstant und lässt die Dateigröße je nach Bewegung im Bild variieren. Das ist genau richtig, wenn Qualität das Ziel ist und die Datei so klein wie möglich sein soll.
Der Wert -crf 23 ist der Standard für H.264. Niedriger (etwa 18) heißt bessere Qualität und größere Datei, höher (etwa 28) heißt mehr Kompression und sichtbarere Artefakte. Für VP9 liegt der vergleichbare Bereich bei -crf 30 bis 34. Fange bei 23 an, geh hoch, bis du den Qualitätsverlust siehst, dann einen Schritt zurück.
Auflösung und Framerate
Der größte Hebel ist nicht der Codec, sondern die Größe des Bildes. Ein Web-Video braucht selten mehr als 1080p (1920 Pixel breit), oft reicht 720p. Skaliere mit dem Flag -vf scale=1920:-2 herunter (die -2 hält das Seitenverhältnis und sorgt für gerade Pixelmaße). Bei einem stimmungsvollen Hintergrund-Loop reichen 24 oder 30 fps, kein Grund für 60 fps. Setze das mit -r 30. Auflösung und Framerate zusammen sparen oft mehr als jede Codec-Umstellung.
Zwei-Pass-Encoding
Wenn du eine feste Zieldateigröße brauchst, etwa für ein Budget an Ladezeit, nutzt du Zwei-Pass statt CRF. ffmpeg analysiert das Video im ersten Durchlauf und verteilt die Bitrate im zweiten optimal über die Szenen. Das ergibt bei fester Bitrate die beste Qualität. Für die meisten Hero-Loops reicht CRF, aber für lange Videos mit hartem Größen-Limit ist Zwei-Pass das sauberere Werkzeug.
Poster-Frame extrahieren
Der Poster-Frame ist das Standbild, das der Browser sofort zeigt, bevor das Video lädt. Er ist der eigentliche Trick für gute Core Web Vitals: Das Bild ist in Millisekunden da, das Video kommt danach im Hintergrund. Ohne Poster starrt der Nutzer auf eine leere Fläche, und dein Largest Contentful Paint wartet auf das ganze Video.
Mit ffmpeg ziehst du den Frame direkt aus dem Video, zum Beispiel bei Sekunde eins, und lieferst ihn als schlankes WebP oder JPEG aus. Ein Poster von wenigen Kilobyte ersetzt Megabyte an gefühlter Wartezeit.
Die konkreten ffmpeg-Befehle
Hier sind die Befehle, die wir tatsächlich verwenden. Erst H.264 als Fallback mit CRF 23, skaliert auf 1080p und 30 fps, mit -movflags +faststart, damit der Browser sofort starten kann statt auf die ganze Datei zu warten:
ffmpeg -i input.mov -c:v libx264 -crf 23 -preset slow -vf scale=1920:-2 -r 30 -movflags +faststart -c:a aac -b:a 128k output.mp4
Dann dieselbe Quelle als WebM/VP9 für moderne Browser:
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 30 -b:v 0 -vf scale=1920:-2 -r 30 -c:a libopus output.webm
Und der Poster-Frame bei Sekunde eins:
ffmpeg -i input.mov -ss 00:00:01 -frames:v 1 poster.webp
Das Flag -preset slow bei H.264 steuert, wie viel Rechenzeit ffmpeg in die Kompression steckt. Langsamer heißt kleinere Datei bei gleicher Qualität. Bei -b:v 0 für VP9 arbeitet der Codec rein qualitätsbasiert über den CRF-Wert. Diese drei Befehle sind die Basis unserer Pipeline.
Ausliefern ohne Ladezeit-Tod
Ein kleines Video ist die halbe Miete. Die andere Hälfte ist, wie du es in die Seite einbaust. Ein perfekt komprimiertes Video, das der Browser sofort und komplett lädt, kann deine Seite trotzdem langsam machen. Vier Dinge entscheiden.
Lazy-Loading
Videos, die nicht im ersten Bildschirm liegen, sollen erst laden, wenn der Nutzer in die Nähe scrollt. Über einen Intersection Observer lädst du die Quelle erst dann, wenn das Video kurz vor dem Sichtbarwerden ist. So blockiert kein Video weiter unten den ersten Seitenaufbau. Für das Hero-Video oben nutzt du kein Lazy-Loading, dafür den Poster-Frame als sofortiges Standbild.
Autoplay, muted und playsinline
Ein Autoplay-Hintergrundvideo braucht drei Attribute, sonst spielt es nicht, vor allem auf iOS. Es muss muted sein (Browser blockieren Autoplay mit Ton), autoplay tragen und playsinline, damit iOS es inline abspielt statt in den Vollbild-Player zu springen. Dazu loop für die Wiederholung und preload="none" oder "metadata", damit nicht sofort die ganze Datei gezogen wird. In der Praxis: <video autoplay muted loop playsinline preload="none" poster="poster.webp">.
Poster als sofortiges Standbild
Das poster-Attribut im <video>-Tag zeigt dein extrahiertes Standbild, bis das Video bereit ist. Das ist der Grund, warum ein Video-Hero überhaupt einen guten Largest Contentful Paint bekommen kann: Der Browser rendert das leichte Poster in Millisekunden, während das schwere Video im Hintergrund nachlädt. Ohne Poster wartet die Messung auf das Video und dein LCP-Wert kippt ins Rote.
Auslieferung über ein CDN
Ein Video-Datei sollte nicht von deinem Ursprungsserver kommen, sondern von einem CDN, das die Datei nah beim Nutzer zwischenspeichert und Byte-Range-Requests unterstützt. So lädt der Browser nur die Teile des Videos, die er gerade braucht, statt die komplette Datei am Stück. Zusammen mit +faststart im MP4 startet das Video fast sofort, egal wie groß es insgesamt ist.
Was das für deine Website bringt
Der Punkt hinter dem ganzen Aufwand sind nicht kleinere Dateien an sich, sondern die Core Web Vitals und damit ein Ranking und eine Nutzererfahrung, die halten. Ein schweres Hero-Video ohne Optimierung zerstört den Largest Contentful Paint und lässt mobile Nutzer abspringen, bevor sie etwas sehen. Genau dieselbe Pipeline aus kleinem Codec, Poster-Frame, spätem Laden und CDN ist der Grund, warum eine video-lastige Site wie FRAMEN grüne PageSpeed-Werte hält.
Wie Core Web Vitals genau gemessen werden und welche Schwellen zählen, steht in unserem Artikel Core Web Vitals verstehen. Wenn du sehen willst, wie diese Video-Pipeline in einem echten Enterprise-Projekt aussieht, lies das Making-of der FRAMEN-Website.
Häufige Fragen
Am saubersten mit ffmpeg über CRF. Skaliere auf 1080p oder 720p, setze 30 fps, kodiere H.264 mit -crf 23 als Fallback und zusätzlich WebM/VP9 mit -crf 30 als kleinere Variante. Extrahiere einen Poster-Frame und liefere alles über ein CDN aus. Das ergibt kleine Dateien ohne sichtbaren Qualitätsverlust.
H.264 (MP4) als kompatible Basis, weil es überall läuft, plus WebM/VP9 oder AV1 als moderne, kleinere Variante. Der Browser wählt automatisch die effizienteste Datei, die er versteht. HEVC/H.265 ist wegen Lizenz und lückenhaftem Browser-Support fürs offene Web nicht empfehlenswert.
Für die meisten Web-Videos ist CRF besser, weil es die Qualität konstant hält und die Dateigröße mit der Bewegung im Bild variiert. Eine feste Bitrate oder Zwei-Pass-Encoding nutzt du nur, wenn du eine harte Zieldateigröße brauchst, etwa wegen eines festen Ladezeit-Budgets.
Weil iOS Autoplay nur erlaubt, wenn das Video stummgeschaltet und inline abspielbar ist. Es braucht die Attribute muted, autoplay und playsinline. Fehlt eines davon, blockiert der Browser die automatische Wiedergabe oder springt in den Vollbild-Player.
So klein wie möglich, als Richtwert unter ein paar Megabyte für ein kurzes Loop. Setze die Auflösung auf 1080p oder darunter, die Framerate auf 24 bis 30 fps, kürze das Loop und nutze CRF. Wichtiger als eine feste MB-Grenze ist, dass ein Poster-Frame sofort erscheint und das Video im Hintergrund nachlädt.
Für ernsthafte Web-Performance ja. Online-Tools verkleinern die Datei, geben dir aber keine Kontrolle über Codec, CRF, faststart, Poster-Frame oder das Doppelformat aus MP4 und WebM. ffmpeg ist kostenlos, skriptbar und liefert reproduzierbare Ergebnisse, weshalb wir jede Web-Video-Pipeline damit fahren.
Weitere Artikel
Lass uns über euer Projekt sprechen!
20-Minuten Gespräch, ohne Verkaufsdruck. Ihr beschreibt, was ihr vorhabt und wir sagen, ob und wie wir helfen können.