AVIF vs. WebP in einem CMS: Warum WebP die bessere Wahl ist

Jedes CMS – sei es Joomla, WordPress, Drupal oder ein anderes System, bei dem Nutzer Bilder über ein Admin-Panel hochladen können – muss irgendwann dieselbe Frage beantworten: Welches moderne Bildformat soll verwendet werden, um Miniaturansichten und Bilder in Webgröße zu generieren? AVIF und WebP sind die beiden Kandidaten, und AVIF wird oft als die Zukunft angepriesen, da es auf dem Papier eine stärkere Komprimierung ermöglicht als WebP. Bei einem CMS, das Bilder auf seinem eigenen Server generiert, hält dieses Versprechen in der Praxis jedoch nicht stand. Ausgehend von den unten aufgeführten Erkenntnissen scheint WebP derzeit die praktischere Wahl für CMS-generierte Bilder zu sein, während es sich noch nicht lohnt, AVIF in eine Standard-Bildpipeline zu integrieren.

AVIF stammt von einem Videocodec ab

AVIF ist kein Format, das von Grund auf für Standbilder entwickelt wurde. Es handelt sich um einen Container für Einzelbilder, der auf AV1 aufbaut, einem für das Streaming von Videos entwickelten Videokompressions-Codec. Dieser Hintergrund ist von Bedeutung, da Videocodecs für einen bestimmten Workflow entwickelt und optimiert werden: einmalige Offline-Kodierung auf dedizierter Hardware oder einer leistungsstarken Serverinfrastruktur und anschließende milliardenfache Dekodierung auf kostengünstigen Client-Geräten. Dieser Kompromiss ist für eine Streaming-Plattform sinnvoll, auf der Inhalte einmal kodiert und dann dauerhaft bereitgestellt werden.

Ein CMS funktioniert anders. Es muss Bilder fortlaufend auf dem Server kodieren – entweder in dem Moment, in dem ein Nutzer ein Foto hochlädt, oder immer dann, wenn ein Theme die Größe eines Vorschaubildes ändert, oder wenn eine Galerie neu generiert wird. Die Anwendung des Standbildmodus eines Videocodecs auf einen solchen Arbeitsablauf bedeutet, dass bei jedem einzelnen Upload Kosten im Stil der Videokodierung anfallen – unabhängig davon, auf welchem Shared- oder Mid-Tier-Hosting die Website gerade betrieben wird. Diese Diskrepanz sollte man im Hinterkopf behalten, wenn man die beiden Formate für den Einsatz in einem CMS vergleicht.

Was die Tests zeigen

Bei der Erstellung von Bildern auf dem Server mit der GD-Bibliothek bei einer Qualität von 100 % wurden für alle Formate folgende Werte gemessen:

Vergleich von Bildformaten

Zwei Dinge fallen hier besonders auf. Erstens konnte AVIF bei den Standard-Encoder-Einstellungen WebP nicht einmal hinsichtlich der Dateigröße übertreffen. Der Komprimierungsvorteil, für den AVIF bekannt ist, kommt erst zum Tragen, wenn die Encoder-Leistung deutlich erhöht wird, da ein Videocodec auf diese Weise zusätzliche Einsparungen erzielt: indem er deutlich mehr Rechenleistung für die Suche nach Redundanzen aufwendet. Zweitens verlängerte sich durch die Erhöhung dieser Leistung die Erstellungszeit für ein einzelnes Bild von einem Bruchteil einer Sekunde auf 46,7 Sekunden. Bei einer Galerie mit Hunderten von Fotos oder einem CMS, das Miniaturansichten bei jeder Änderung einer Vorlage oder einer Größeneinstellung neu generiert, summieren sich solche Kosten schnell und können zu stundenlangem Serveraufwand führen – oder dazu, dass eine Anfrage einfach abläuft.

Vergleich von Bildformaten

Dies deckt sich mit den Ergebnissen umfassenderer Benchmark-Berichte zu Bildformaten aus dem Jahr 2026: Die AVIF-Kodierung ist in der Regel etwa 5- bis 50-mal langsamer als WebP und kann bei der Upload-Verarbeitung pro Bild mehrere Sekunden, manchmal sogar deutlich mehr, zusätzlich in Anspruch nehmen. Dies ist einer der Gründe, warum leistungsorientierte CDNs die AVIF-Kodierung in der Regel als Hintergrundauftrag ausführen, anstatt sie innerhalb einer Live-Anfrage durchzuführen. Ein CDN kann auf einer solchen Infrastruktur aufbauen. Eine typische CMS-Installation auf Shared Hosting in der Regel nicht.

Warum dies in einem CMS eine größere Rolle spielt

Bei einem allgemeinen Vergleich zwischen AVIF und WebP wird oft von einer Build-Pipeline ausgegangen: Bilder werden einmal konvertiert, auf ein CDN hochgeladen und danach nie wieder bearbeitet. Ein CMS funktioniert in der Regel nicht so, und daraus ergeben sich mehrere praktische Aspekte:

• Miniaturansichten werden häufig neu generiert. Wenn man in Joomla, WordPress oder Drupal das Layout einer Galerie, ein Theme, eine Zuschneideeinstellung oder die Bildabmessungen eines Plugins ändert, werden in der Regel alle vorhandenen Miniaturansichten neu erstellt. Ein langsamerer Encoder in Videoqualität, der auf eine große Medienbibliothek angewendet wird, führt zu einer erheblichen Belastung.
• Das Generieren von Bildern bei der ersten Anfrage eines Besuchers wird mit AVIF riskanter. Bei manchen Konfigurationen wird ein Vorschaubild erst dann generiert, wenn ein Besucher es zum ersten Mal anfordert, anstatt es bereits im Voraus im Admin-Backend zu erstellen. Dies ist aus Leistungsgründen generell schon ein umstrittener Ansatz, und bei AVIF bedeutet dies, dass ein Besucher unter Umständen mehrere Sekunden – oder bei höherer Komprimierung sogar mehrere Minuten – auf die Kodierung warten muss.
• Die Unterstützung durch Server-Bibliotheken ist uneinheitlich. Sowohl GD als auch ImageMagick können Probleme mit AVIF haben. GD-Builds werden manchmal mit nicht passenden oder fehlenden AVIF-Abhängigkeiten ausgeliefert, und ImageMagick benötigt Version 7, während eine Reihe von Linux-Distributionen standardmäßig noch die ältere Version 6 verwenden. Bei Shared-Hosting- oder Budget-Hosting-Angeboten, auf denen ein großer Teil der Joomla-, WordPress- und Drupal-Websites betrieben wird, handelt es sich dabei um ein echtes, immer wieder auftretendes Problem und nicht um ein hypothetisches.
• Fehler sind nicht immer sichtbar. Wenn die erforderliche Bibliothek fehlt oder falsch konfiguriert ist, schlagen manche Setups nicht sofort fehl. Eine Datei kann die Endung .avif erhalten, während sie intern weiterhin im PNG-Format oder einem anderen Format vorliegt. Solche unauffälligen Abweichungen lassen sich beim Testen schwerer erkennen als ein Bild, das offensichtlich fehlerhaft ist.
• Die sichere Bereitstellung erfordert in der Regel zusätzliche Infrastruktur. Da AVIF nach wie vor einen Fallback für Browser und Tools benötigt, die das Format nicht dekodieren können, bedeutet die sinnvolle Nutzung in der Regel, dass mehrere Varianten jedes Bildes generiert und gespeichert, diese synchron gehalten und durch ein `picture`-Element zusätzlicher Markup-Aufwand verursacht werden. Diese Fallback-Konfiguration deckt zudem nur `img`- und `picture`-Markup ab, das direkt gesteuert wird. Hintergrundbilder in CSS, von Widgets von Drittanbietern eingebundene Bilder, RSS-Feeds und E-Mail-Vorlagen profitieren nicht davon und benötigen unabhängig davon weiterhin ein herkömmliches Format. In der Praxis bedeutet dies, dass AVIF zusätzlich zu einem Fallback-Format wie WebP einen weiteren Schritt erfordert, anstatt dessen Notwendigkeit zu ersetzen.

Das soll keineswegs eine pauschale Ablehnung von AVIF als Technologie bedeuten. Es ist einfach das, was in der Regel passiert, wenn ein Codec, der für die Offline-Videokodierung entwickelt wurde, auf eine Live-Bild-Pipeline angewendet wird, die pro Upload auf einem gewöhnlichen Webhosting-Server läuft.

Wo WebP im Vergleich gut abschneidet

WebP wurde von Anfang an als Web-Bildformat konzipiert und nicht aus einem Videocodec abgeleitet, was sich in seinem Verhalten in den oben genannten Tests und im allgemeinen Einsatz zeigt: Die Kodierung bleibt schnell und relativ vorhersehbar, unabhängig davon, wie stark die Komprimierungseinstellungen angezogen werden; die Unterstützung in GD, ImageMagick und den CMS-Plugin-Ökosystemen ist umfassend und ausgereift, Transparenz wird gut genug unterstützt, um PNG zu ersetzen, Animationen werden gut genug unterstützt, um GIF zu ersetzen, und die Browserunterstützung liegt bei rund 97 % oder mehr des weltweiten Datenverkehrs und ist weitgehend stabil, seit Safari im Jahr 2020 die Unterstützung hinzugefügt hat. Es gibt kein Äquivalent zum „Silent Mismatch“-Fehlermodus von AVIF, es muss nicht geprüft werden, ob die ImageMagick-Version eines bestimmten Hosts aktuell genug ist, und es gibt kein realistisches Szenario, in dem das Hochladen eines einzelnen Fotos eine Anfrage um mehrere zehn Sekunden verzögert.

Praktische Tipps zu den Standardwerten des CMS

Ob Joomla, WordPress oder Drupal – die Fakten deuten alle in dieselbe Richtung:

1. WebP ist ein sinnvolles Standardformat für Miniaturansichten und von einem CMS generierte Bilder in angepasster Größe. Es ist ein guter Ersatz für PNG (behält die Transparenz bei und ist deutlich kleiner) und eignet sich für die meisten Fotos gut als Alternative zu JPEG, während es schnell kodiert wird und weitgehend ohne zusätzlichen Aufwand funktioniert.
2. AVIF eignet sich derzeit noch nicht als Standard-Bildpipeline. Der Kodierungsaufwand, die uneinheitliche Unterstützung durch serverseitige Bibliotheken und die zusätzliche Fallback-Infrastruktur, die dadurch in der Regel erforderlich wird, überwiegen den Komprimierungsgewinn bei einem System, das Bilder in Echtzeit generiert und auf einer Hosting-Umgebung läuft, die nicht immer vollständig kontrolliert werden kann.
3. Das Erstellen von Miniaturansichten ausschließlich bei der ersten Anfrage eines Besuchers sollte generell vermieden werden, insbesondere bei einem Format, das mit Kosten für die Videokodierung verbunden ist.

Zusammenfassend

Die Komprimierungswerte von AVIF sehen für sich genommen vielversprechend aus, stammen jedoch von einem Codec, der für einen anderen Arbeitsablauf entwickelt wurde: einmalige Offline-Kodierung, anschließende unbegrenzte Dekodierung. Ein CMS arbeitet eher nach dem gegenteiligen Muster: Es kodiert fortlaufend und live in Hosting-Umgebungen, die sich hinsichtlich ihrer Unterstützung stark unterscheiden. Dieser Unterschied ist ein wesentlicher Grund dafür, dass AVIF genau in der Umgebung, in der ein CMS betrieben wird, mit langsamer Kodierung, uneinheitlicher Unterstützung durch Serverbibliotheken und stillen Fehlern zu kämpfen hat, während WebP, das von Anfang an für das Web entwickelt wurde, in der Regel einfach funktioniert. Nach dem derzeitigen Stand der Dinge ist WebP die praktischere Wahl für von CMS generierte Bilder.