12k
All articles

So ersetzen Sie animierte GIFs durch MP4-Videos

Ersetzen Sie animierte GIFs durch MP4- oder WebM-Video mit autoplay muted loop playsinline sowie ffmpeg-Konvertierung und LCP-Tipps.

OpenReplay Team
OpenReplay Team
So ersetzen Sie animierte GIFs durch MP4-Videos

Um ein animiertes GIF durch Video zu ersetzen, konvertieren Sie den Clip in ein H.264-MP4 und ein VP9-WebM und binden dann beide mit <video autoplay muted loop playsinline> ein, wobei die WebM-<source> zuerst aufgeführt wird.

Wenn Lighthouse Ihre Produktseite oder Dokumentation wegen animierter Inhalte markiert hat, liegt die Ursache meist in einem Screen-Recording-GIF mit mehreren Megabyte. Dieser Artikel erläutert, warum GIF bei der Dateigröße den Kürzeren zieht, wie die Konvertierung abläuft (Browser-Tool oder ffmpeg, ganz nach Wahl), wie das genaue Markup aussieht, welche Auswirkungen der Wechsel auf den LCP hat und wo GIF weiterhin die richtige Wahl ist.

Die wichtigsten Erkenntnisse

  • Ein animiertes GIF speichert jeden Frame als nahezu vollständiges Bild mit maximal 256 Farben und profitiert dadurch überhaupt nicht von der Interframe-Kompression, auf der Video-Codecs aufbauen.
  • muted ist der Grund, warum Browser Autoplay überhaupt zulassen, und playsinline verhindert, dass iOS das Video in den Vollbildmodus zwingt.
  • Browser spielen die erste <source> ab, die sie dekodieren können, nicht die kleinste – die WebM-Quelle muss also vor dem MP4-Fallback stehen.
  • Seit Chrome 116 kann ein <video> ohne poster als LCP-Element gelten; erfasst wird der Zeitpunkt, an dem der erste Frame auf dem Bildschirm erscheint.
  • Die Größeneinsparung hängt vollständig vom jeweiligen Clip ab; messen Sie Ihre eigenen Werte vor und nach der Konvertierung, statt sich auf angegebene Prozentwerte zu verlassen.

Warum ist GIF der falsche Container für Bewegtbild?

Ein animiertes GIF speichert jeden Frame als nahezu vollständiges Bild mit einer Palette von maximal 256 Farben pro Frame. Dadurch profitiert es überhaupt nicht von der Interframe-Kompression, für die Videoformate konzipiert wurden, und es wird in Software dekodiert, während H.264 und VP9 auf den meisten Geräten Hardware-Dekodierpfade nutzen. Die GIF89a-Spezifikation stellt klar, dass das Format nicht für Animationen gedacht war und diese nur in eingeschränkter Form erlaubt; das Looping kam erst später hinzu, ergänzt durch die Browser. Mehr Geschichtsunterricht brauchen Sie nicht.

Die praktische Konsequenz: Wenige Sekunden Screen Recording landen als GIF regelmäßig im Mehr-Megabyte-Bereich, als Video hingegen bei einigen hundert Kilobyte. Lighthouse weist darauf hin: Der Hinweis zur GIF-zu-Video-Konvertierung findet sich ab Lighthouse 13 innerhalb des Insights Improve image delivery.

Eine echte Konvertierung mit echten Zahlen

Googles web.dev-Leitfaden zu diesem Thema veröffentlicht ein ehrliches Beispiel, konvertiert mit denselben Befehlen, die unten gezeigt werden: Aus einem 3,7 MB großen Quell-GIF wurde ein 551 KB großes MP4 und ein 341 KB großes WebM. Die Einsparung hängt vollständig von Inhalt, Framerate und Abmessungen des Clips ab – ein an einer Datei gemessener Prozentwert lässt sich also nicht auf Ihre übertragen.

DateiGröße
Quell-GIF3,7 MB
MP4 (H.264, CRF 25)551 KB
WebM (VP9, CRF 41)341 KB

Betrachten Sie diese Zahlen als einzelnen Datenpunkt, nicht als Regel. Material mit viel Bewegung komprimiert sich anders als eine überwiegend statische Terminal-Aufzeichnung. Schicken Sie Ihren eigenen Clip durch die folgenden Schritte und vergleichen Sie die Byte-Werte, bevor Sie sich festlegen.

So ersetzen Sie ein GIF durch Video: Die Dateien erzeugen

Sie benötigen zwei Dateien: ein MP4 für die universelle Wiedergabe und ein WebM, das in der Regel kleiner ist. Für jeden Schritt gibt es ein Browser-Tool und einen äquivalenten ffmpeg-Befehl.

Schritt 1: GIF zu MP4. Nutzen Sie den GIF to MP4 converter, der lokal in Ihrem Browser läuft, oder ffmpeg:

ffmpeg -i input.gif -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2" \
  -vcodec libx264 -pix_fmt yuv420p -b:v 0 -crf 25 -f mp4 output.mp4

-pix_fmt yuv420p sorgt dafür, dass die Datei überall abspielbar bleibt, und CRF reicht von 0 bis 51, wobei niedrigere Werte höhere Qualität bedeuten; -b:v 0 deaktiviert dabei die Bitratenbegrenzung im CRF-Modus. Der Crop-Filter ist der Workaround von web.dev dafür, dass libx264 ungerade Pixelabmessungen ablehnt.

Schritt 2: die WebM-Datei für die zweite <source>. Im Browser übergeben Sie das gerade erzeugte MP4 an den MP4 to WebM converter. Mit ffmpeg encodieren Sie stattdessen direkt aus dem Original-GIF, damit der Clip nicht zweimal komprimiert wird:

ffmpeg -i input.gif -c:v libvpx-vp9 -b:v 0 -crf 41 output.webm

Die CRF-Skala von VP9 unterscheidet sich von der von x264 – deshalb ist 41 hier ein sinnvoller Standardwert und keine Einstellung für niedrige Qualität.

Schritt 3: Optionales Feintuning. Ist das Ergebnis noch zu schwer, verkleinern Sie es über Auflösung und Qualität mit dem video compressor oder mit ffmpeg:

ffmpeg -i output.mp4 -vf scale=640:-2 -crf 28 -movflags faststart smaller.mp4

-movflags faststart verschiebt die MP4-Metadaten an den Dateianfang, sodass die Wiedergabe starten kann, bevor der Download abgeschlossen ist.

Das Markup, das sich wie ein GIF verhält

Damit sich ein Video wie ein GIF verhält, verwenden Sie <video autoplay muted loop playsinline>: muted ist der Grund, warum Browser Autoplay überhaupt zulassen, und playsinline verhindert, dass iOS das Video in den Vollbildmodus zwingt.

<video autoplay muted loop playsinline width="640" height="360">
  <source src="clip.webm" type="video/webm">
  <source src="clip.mp4" type="video/mp4">
</video>

Chromes Autoplay-Richtlinie erlaubt einem stummgeschalteten Video den selbstständigen Start und blockiert Autoplay mit Ton, bis der Besucher mit der Seite interagiert hat. WebKits Video-Richtlinie für iOS lässt Autoplay ohne Nutzergeste nur zu, wenn die Videos stummgeschaltet sind oder keine Audiospur enthalten; auf dem iPhone ist playsinline erforderlich, damit der Clip an seiner Position abgespielt wird. Die Reihenfolge der Quellen ist entscheidend, denn Browser wählen nicht die beste <source>, sondern spielen die erste ab, die sie dekodieren können – das kleinere WebM steht also zuerst. Diese Reihenfolge ist überall unbedenklich: die WebM-Tabelle von caniuse zeigt vollständige Unterstützung in Safari 16 unter macOS und in Safari unter iOS ab 17.4 – Warnungen aus dem Jahr 2018 zu Apple und WebM sind damit hinfällig. Die Attribute width und height reservieren Layout-Platz – dieselbe CLS-Höflichkeit, die Sie einem Bild auch zugestehen würden.

Fehlt eines dieser Attribute, bleibt der Fehler stumm: keine Konsolenmeldung, kein Symbol für ein defektes Bild, nur ein eingefrorener erster Frame. Session Replay zeigt die Seite so, wie jeder Nutzer sie tatsächlich gesehen hat – die einzige verlässliche Möglichkeit, ein Autoplay-Video zu erkennen, das in der Produktion nie gestartet ist.

Welche Auswirkungen hat der Wechsel auf den Largest Contentful Paint?

Der Wechsel von <img> zu <video> verändert, welches Element als LCP-Kandidat infrage kommt. Ältere Empfehlungen besagten, ein <video> ohne poster sei für LCP unsichtbar – das hat sich mit Chrome 116 geändert: Das Chromium Metrics Changelog dokumentiert, dass ein Video-Element nun genauso berücksichtigt wird wie ein Bild, wobei der Zeitstempel dem Moment entspricht, in dem der erste Frame auf dem Bildschirm erscheint. Fügen Sie also kein poster hinzu, nur um die Metrik zu beeinflussen; ein automatisch startendes Video zeichnet seinen ersten Frame sofort, und das Poster-Bild würde niemals zu sehen sein. Ist Ihre Hero-Animation das größte Element, hängt ihr LCP-Timing nun davon ab, wie schnell dieser erste Frame eintrifft – ein weiterer Grund, die Dateien klein zu halten.

Wann ist ein GIF weiterhin die bessere Wahl?

Ein GIF gewinnt weiterhin dort, wo Sie das Markup nicht kontrollieren können: Chat-Nachrichten, E-Mail-Clients und GitHub-READMEs stellen ein GIF inline dar, binden aber kein automatisch startendes Video ein. In diesen Umgebungen zählt Portabilität mehr als Seitengewicht, und der richtige Schritt ist verlustbehaftete GIF-Kompression statt Konvertierung. Die Option --lossy von gifsicle (früher das separate Projekt giflossy) tauscht Artefakte gegen Dateigröße:

gifsicle -O3 --lossy=80 -o smaller.gif input.gif

Höhere Lossy-Werte erlauben mehr Artefakte und kleinere Dateien; justieren Sie so lange, bis das Ergebnis nicht mehr akzeptabel aussieht, und gehen Sie dann einen Schritt zurück.

Fazit

Auf jeder Seite, deren Markup Sie kontrollieren, gehört Bewegtbild in ein <video>-Element mit zwei Quellen und nicht in ein GIF. Nehmen Sie das schwerste GIF Ihrer Website, führen Sie es durch die oben beschriebenen Konvertierungsschritte und vergleichen Sie die Byte-Werte selbst; anschließend deployen Sie das Markup mit den vier Attributen und WebM an erster Stelle und prüfen das Replay einer echten Session, um zu bestätigen, dass es tatsächlich abgespielt wird.

FAQs

Kann ich nur ein MP4 ausliefern und die WebM-Datei weglassen?

Ja. Ein H.264-MP4 im Pixelformat yuv420p läuft in jedem modernen Browser, sodass ein Video-Element mit einer einzigen Quelle überall funktioniert und nichts kaputtgeht. Die WebM-Variante ist eine Größenoptimierung, keine Kompatibilitätsanforderung: VP9 erzeugt bei vergleichbarer Qualität meist eine kleinere Datei. Liefern Sie zunächst das MP4 aus und ergänzen Sie die WebM-Quelle später darüber, falls das Seitengewicht Sie weiterhin stört.

Warum startet mein Video trotz gesetzter Attribute autoplay, muted, loop und playsinline nicht automatisch?

Eine Richtlinie des User Agents blockiert die Wiedergabe, nicht Ihr Markup. iOS Safari unterbindet Autoplay, wenn sich das Gerät im Energiesparmodus befindet, und zeigt stattdessen einen Play-Button an; Akku- oder Datensparmodi in anderen Browsern können sich ähnlich verhalten. Erkennen Sie dies in JavaScript: video.play() gibt ein Promise zurück – behandeln Sie die Ablehnung, indem Sie Steuerelemente oder ein statisches Fallback-Bild anzeigen, anstatt einen eingefrorenen Frame.

Funktioniert loading='lazy' beim Video-Element?

In Chromium-basierten Browsern ja. Chrome, Edge und Opera verzögern bei einem Lazy-Video den Download, das Laden des Posters und den Autoplay-Start, bis sich das Element dem Viewport nähert; MDN dokumentiert das Attribut. Eine entsprechende Ergänzung der HTML-Spezifikation ist in Arbeit, und Firefox sowie WebKit haben dem Feature beide eine positive Standards-Position gegeben, ausgeliefert hat es aber noch keiner von beiden. Browser ohne Unterstützung ignorieren das Attribut einfach und laden sofort – es ist also heute schon unbedenklich, es bei GIF-Ersatzvideos außerhalb des sichtbaren Bereichs zu setzen.

Ist animiertes WebP ein guter Mittelweg zwischen GIF und Video?

Manchmal. Animiertes WebP funktioniert innerhalb eines einfachen img-Elements, unterstützt 24-Bit-Farbe anstelle der 256-Farben-Palette von GIF und erzeugt in der Regel kleinere Dateien als das äquivalente GIF. An einen echten Video-Codec reicht es aber nicht heran: H.264 oder VP9 komprimieren eine Screen-Aufzeichnung deutlich besser. Verwenden Sie animiertes WebP dort, wo die Umgebung ein img-Tag verlangt, aber moderne Formate akzeptiert – und Video überall dort, wo Sie das Markup kontrollieren.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — self-hosted, with full data ownership.

Star on GitHub

We use cookies to improve your experience. By using our site, you accept cookies.