Laptop mit bearbeitetem Adlerfoto zur Bildkomprimierung in WebP und AVIF
Detailreiche Motive zeigen besonders deutlich, wie gut WebP und AVIF Bildqualität und Dateigröße ausbalancieren. Foto: Pexels / Lizenz: Pexels

AVIF erzeugt bei vielen Fotos kleinere Dateien als WebP, während WebP durch schnelle Verarbeitung und breite Kompatibilität besonders unkompliziert einsetzbar ist. Die beste Lösung besteht häufig nicht in der Entscheidung für nur ein Format. Moderne Websites können AVIF bevorzugen, WebP als zweite Variante anbieten und JPEG oder PNG als Rückfalllösung behalten. Die Dateiendung allein macht eine Website jedoch nicht schnell. Bildabmessungen, Kompressionsstufe, responsive Varianten und die Position im Seitenaufbau beeinflussen die Ladezeit ebenso stark. Die technischen Grundlagen beschreibt auch web.dev zur Bildleistung. Für umfangreiche Portfolios lohnt sich zusätzlich ein abgestimmtes Konzept, mit dem sich Fotogalerien schneller laden lassen.

Inhaltsverzeichnis

WebP und AVIF im direkten Praxisvergleich

Ein AVIF mit unnötig großer Auflösung kann mehr Daten übertragen als ein passend skaliertes WebP. Deshalb sollte zuerst die benötigte Pixelgröße feststehen. Anschließend werden Format und Qualität anhand des tatsächlichen Motivs gewählt.

WebP beherrscht verlustbehaftete und verlustfreie Kompression. Das Format unterstützt Transparenz und Animationen. Es wird von aktuellen Versionen der großen Browser unterstützt und lässt sich mit zahlreichen CMS-Erweiterungen, Grafikprogrammen und Bilddiensten erzeugen.

AVIF basiert auf der Bildnutzung des AV1-Codecs. Das Format unterstützt ebenfalls verlustbehaftete und verlustfreie Dateien, Transparenz und Animationen. Hinzu kommen hohe Farbtiefen, Wide Color Gamut und HDR. Nach Angaben der Alliance for Open Media kann AVIF gegenüber JPEG und WebP deutliche Einsparungen erzielen. Der konkrete Vorteil hängt jedoch vom Motiv, Encoder und gewählten Qualitätsniveau ab.

AVIF gewinnt den Vergleich nur dann, wenn die kleinere Datei bei gleicher wahrgenommener Bildqualität entsteht. Ein direkter Vergleich gleicher Qualitätswerte ist nicht zuverlässig. Die Skalen unterschiedlicher Encoder und Formate sind nicht untereinander genormt. Ein Wert von 70 bei WebP entspricht deshalb nicht automatisch einem Wert von 70 bei AVIF.

WebP bleibt sinnvoll, wenn Bilder schnell beim Upload erzeugt werden müssen oder ein vorhandenes System AVIF nicht zuverlässig verarbeitet. AVIF spielt seine Stärke bei großen Titelbildern, Produktfotos, Reisefotografie und umfangreichen Galerien aus. Die aufwendigere Kodierung sollte bei vielen Dateien möglichst vorab erfolgen. Bereits erzeugte Varianten können anschließend im Cache oder auf einem CDN liegen.

FORMATVERGLEICH

WebP oder AVIF im Praxiseinsatz

Die passende Wahl hängt vom Motiv, vom Arbeitsablauf und von der gewünschten Auslieferung ab.

Kriterium AVIF WebP Praktische Wahl
Fotokompression Oft kleinere Dateien bei vergleichbarer sichtbarer Qualität Gute Kompression und unkomplizierte Verarbeitung Beide Versionen aus derselben Masterdatei testen
Kodierung Für große Bestände möglichst vorab erzeugen Für schnelle Uploadprozesse häufig praktischer Dateien speichern und über Cache oder CDN ausliefern
Transparenz Unterstützt Unterstützt Dateigröße und Kantenqualität vergleichen
Farbmöglichkeiten Geeignet für hohe Farbtiefen, HDR und Wide Color Gamut Solide Lösung für gewöhnliche Webbilder Farbmanagement des gesamten Workflows berücksichtigen
Auslieferung Als bevorzugte Quelle einsetzbar Geeignete zweite Quelle AVIF, WebP und JPEG über picture kombinieren

Das richtige Format für Fotos und Grafiken

Nicht jedes Motiv reagiert gleich auf Kompression. Fotos enthalten viele Farben, Strukturen und weiche Übergänge. Dort lassen sich kleine Detailverluste häufig verbergen. Schrift, Logos und feine Linien zeigen dagegen schnell störende Ränder oder Farbsäume.

  • Fotos und realistische Motive eignen sich meist für verlustbehaftetes AVIF oder WebP.
  • Logos und einfache Symbole sollten nach Möglichkeit als SVG vorliegen.
  • Screenshots mit kleiner Schrift benötigen eine vorsichtige Kompression oder eine verlustfreie Variante.
  • Bilder mit Transparenz können als WebP oder AVIF gespeichert werden.
  • Grafiken mit wenigen Farben müssen einzeln geprüft werden, da PNG oder SVG manchmal besser abschneiden.
  • Animationen sollten mit Videoformaten verglichen werden, weil lange Bildanimationen unnötig groß werden können.

Die Webdatei sollte aus einer möglichst hochwertigen Ausgangsdatei erstellt werden. Wiederholtes Umwandeln von JPEG in WebP und anschließend in AVIF kann bereits vorhandene Kompressionsfehler verstärken. Wer den geeigneten Ausgangspunkt bestimmen möchte, findet im Vergleich RAW oder JPEG für unterschiedliche Arbeitsabläufe weitere praktische Hinweise.

Die originale Aufnahme bleibt als Masterdatei erhalten. Davon werden die benötigten Webgrößen neu exportiert. Dieses Vorgehen verhindert, dass eine kleine oder bereits stark komprimierte Datei später künstlich vergrößert werden muss.

INTERAKTIVER FORMAT-FINDER

Welches Bildformat passt zu Ihrem Motiv?

Wählen Sie drei Merkmale aus. Das Ergebnis zeigt eine passende Ausgangsstrategie.

Komprimierung ohne sichtbaren Qualitätsverlust

Ohne sichtbaren Qualitätsverlust bedeutet nicht zwingend verlustfrei. Bei einer verlustbehafteten Kompression werden Bildinformationen entfernt. Die Änderung kann trotzdem unauffällig bleiben, wenn sie bei der vorgesehenen Darstellungsgröße nicht erkennbar ist.

 Person vergleicht Fotografien am Laptop vor der Komprimierung für eine Website
Vor der Komprimierung sollten Farben, feine Strukturen und wichtige Bilddetails sorgfältig geprüft werden. Foto: Pexels / Lizenz: Pexels

Es gibt keine universelle Qualitätsstufe, die für jedes Foto, jeden Encoder und jede Website funktioniert. Ausgangswerte eines Werkzeugs dienen lediglich als Startpunkt. Entscheidend ist eine Sichtprüfung des konkreten Bildes.

  1. Zuerst wird das Bild auf die größte tatsächlich benötigte Darstellungsgröße zugeschnitten und skaliert.
  2. Danach werden eine AVIF- und eine WebP-Version aus derselben hochwertigen Quelle erzeugt.
  3. Beide Dateien werden bei der vorgesehenen Anzeigegröße und zusätzlich in einer vergrößerten Ansicht geprüft.
  4. Die Qualität wird schrittweise reduziert, bis erste störende Veränderungen sichtbar werden.
  5. Anschließend wird die letzte unauffällige Einstellung gewählt und die Dateigröße verglichen.
  6. Zum Schluss werden Smartphone, Desktopmonitor und mindestens zwei Browser getestet.

KOMPRESSION IN 7 SCHRITTEN

Ihr Fahrplan für sichtbar saubere Webbilder

Haken Sie jeden erledigten Schritt ab. Der Fortschrittsbalken zeigt, ob das Bild bereit für die Veröffentlichung ist.

0 von 7 Schritten erledigt

Besondere Aufmerksamkeit benötigen Hauttöne, Haare, Blätter, feine Stoffmuster, Schatten und gleichmäßige Farbverläufe. In diesen Bereichen erscheinen Blockbildung, Banding und unscharfe Konturen häufig zuerst. Bei Screenshots sind kleine Buchstaben, Icons und farbige Kanten die wichtigsten Prüfpunkte.

Für die Sichtkontrolle eignen sich Werkzeuge mit geteilter Vorher-Nachher-Ansicht. Squoosh verarbeitet Bilder lokal im Browser und zeigt Dateigröße sowie visuelle Veränderungen direkt an. Für regelmäßige Veröffentlichungen sind automatisierte Werkzeuge wie Sharp, ImageMagick oder ein Bild-CDN besser geeignet.

Überflüssige EXIF-Daten, Vorschaubilder und Standortinformationen können entfernt werden. Farbprofile sollten nicht gedankenlos gelöscht werden. Eine kontrollierte Konvertierung nach sRGB ist für gewöhnliche Webbilder oft sinnvoll. Bei HDR- oder Wide-Color-Gamut-Inhalten muss das Farbmanagement dagegen Teil des gesamten Workflows bleiben.

Responsive Bilder mit picture und srcset

Ein modernes Dateiformat verhindert nicht, dass ein Smartphone eine viel zu große Desktopdatei erhält. Responsive Bilder stellen mehrere Breiten bereit. Der Browser wählt anhand von Viewport, Pixeldichte und Layout eine passende Version.

Das Element picture kann mehrere Formate in einer festen Reihenfolge anbieten. Der Browser prüft die Quellen von oben nach unten. Unterstützt er AVIF, lädt er die erste Variante. Andernfalls folgt WebP und danach das klassische Rückfallbild.

<picture>
  <source
    type="image/avif" srcset="/foto-640.avif 640w, /foto-1280.avif 1280w"
    sizes="(min-width: 900px) 800px, 100vw">
  <source
    type="image/webp" srcset="/foto-640.webp 640w, /foto-1280.webp 1280w"
    sizes="(min-width: 900px) 800px, 100vw">
  <img
    src="/foto-1280.jpg" srcset="/foto-640.jpg 640w, /foto-1280.jpg 1280w"
    sizes="(min-width: 900px) 800px, 100vw"
    width="1280"
    height="800"
    alt="Fotografin bearbeitet eine Aufnahme für eine Website">
</picture>

Die Reihenfolge ist wichtig. AVIF steht vor WebP, wenn der Browser bevorzugt AVIF laden soll. Das abschließende img bleibt obligatorisch. Dort stehen auch Alternativtext, Breite und Höhe. Diese Angaben gelten unabhängig von der ausgewählten Quelle.

Mehrere Formate und mehrere Bildbreiten lösen zwei unterschiedliche Probleme. Die Formate reduzieren die Dateigröße durch bessere Kompression. Die Breiten verhindern, dass mehr Pixel als nötig übertragen werden.

Klare Dateinamen erleichtern die Verwaltung der Varianten. Ein konsistentes Schema kann Motiv, Breite und Format enthalten. Weitere Grundlagen bietet der Beitrag über das richtige Benennen von Fotodateien.

LCP und Lazy Loading richtig behandeln

Das größte sichtbare Bild im ersten Bildschirmbereich kann das Largest Contentful Paint beeinflussen. Eine kleinere Datei verkürzt häufig die Übertragungszeit. Das Titelbild darf aber nicht durch unpassendes Lazy Loading verzögert werden.

  • Das zentrale Titelbild wird normal und ohne loading="lazy" geladen.
  • fetchpriority="high" kann gezielt für das wichtigste LCP-Bild verwendet werden.
  • Bilder unterhalb des ersten sichtbaren Bereichs können loading="lazy" erhalten.
  • width und height reservieren Platz und reduzieren Layoutverschiebungen.
  • srcset und sizes liefern eine zur Darstellung passende Auflösung.
  • Preloading sollte nur für die tatsächlich bevorzugte Variante eingesetzt werden.

Das gleichzeitige Vorladen von AVIF und WebP ist keine gute Standardlösung. Ein Browser kann dadurch beide Dateien anfordern, obwohl er nur eine davon zeigt. Für ein wichtiges Titelbild wird höchstens die wahrscheinlich verwendete Variante vorgeladen.

Kompression darf außerdem keine langsame Serververarbeitung bei jedem Seitenaufruf auslösen. Wird AVIF erst während der Anfrage erzeugt, kann die Rechenzeit einen Teil des Vorteils wieder aufheben. Vorab generierte Dateien oder dauerhaft gespeicherte CDN-Varianten vermeiden diese Verzögerung.

Bildoptimierung im CMS automatisieren

Bei wenigen Bildern reicht ein manueller Vergleich. Ein Fotoblog oder Magazin benötigt einen wiederholbaren Prozess. Die Redaktion lädt eine hochwertige Datei hoch. Das System erzeugt daraus mehrere Breiten und Formate, entfernt nicht benötigte Metadaten und speichert die Ergebnisse im Cache.

Eine praxistaugliche Automatisierung umfasst folgende Aufgaben.

  • Erzeugung von AVIF, WebP und einer kompatiblen Rückfallversion
  • Bereitstellung mehrerer Auflösungen für srcset
  • Begrenzung der maximalen Pixelgröße beim Upload
  • Erhaltung korrekter Bildausrichtung und relevanter Farbinformationen
  • Ausgabe der MIME-Typen image/avif und image/webp
  • Cache-Schlüssel mit Berücksichtigung von Format und Bildbreite
  • Getrennte Behandlung des Titelbildes und nachgelagerter Galerieaufnahmen

Bei dynamischer Formatauswahl über den HTTP-Header Accept muss der Cache die ausgelieferte Variante korrekt unterscheiden. Andernfalls kann ein nicht unterstütztes Format an den falschen Browser gelangen. Die Verwendung von picture ist für redaktionelle Seiten häufig leichter zu kontrollieren.

Vor der vollständigen Umstellung empfiehlt sich ein Test mit typischen Motiven aus dem eigenen Archiv. Landschaften, Porträts, Nachtaufnahmen und Screenshots sollten getrennt bewertet werden. Ein Workflow für einen professionell genutzten Fotoblog als Vertriebskanal muss zudem stabil bleiben, wenn viele neue Dateien gleichzeitig verarbeitet werden.

Häufige Fehler bei WebP und AVIF

Der häufigste Fehler ist die pauschale Konvertierung aller Bilder mit derselben Qualitätsstufe. Ein Porträt, eine Architekturaufnahme und ein Screenshot reagieren unterschiedlich. Auch verschiedene Encoder liefern bei identischen Reglerwerten keine identischen Resultate.

Problematisch ist außerdem der Vergleich allein anhand der Dateigröße. Eine extrem kleine AVIF-Datei ist kein Erfolg, wenn Hauttöne fleckig wirken oder feine Strukturen verschwinden. Dateien müssen bei einer vergleichbaren visuellen Qualität beurteilt werden.

Weitere Fehler entstehen durch zu große Pixelmaße, fehlende responsive Varianten und eine unnötige Neukodierung bereits komprimierter Dateien. Auch ein falscher MIME-Typ kann verhindern, dass Browser das Bild korrekt verarbeiten.

AVIF und WebP sind nicht automatisch die beste Wahl für jedes Element. SVG bleibt bei skalierbaren Logos und einfachen Grafiken meist überlegen. PNG kann bei bestimmten verlustfreien Screenshots sinnvoll sein. Text sollte nach Möglichkeit als echtes HTML erscheinen, weil er dann lesbar, durchsuchbar und barriereärmer bleibt.

Für die meisten redaktionellen Websites ist AVIF als bevorzugtes Format, WebP als zweite Quelle und JPEG oder PNG als Rückfalllösung die flexibelste Auslieferung. WebP allein bleibt eine solide Lösung, wenn das CMS oder der Hostingdienst AVIF noch nicht zuverlässig erzeugt. Die sichtbare Qualität entscheidet immer am konkreten Motiv.

Wichtigste Punkte zum Merken

  • AVIF ist bei vielen Fotos effizienter als WebP.
  • WebP lässt sich häufig schneller und einfacher verarbeiten.
  • Qualitätswerte verschiedener Formate sind nicht direkt vergleichbar.
  • Das Bild muss vor der Kompression passend skaliert werden.
  • AVIF, WebP und JPEG können gemeinsam über picture ausgeliefert werden.
  • srcset und sizes verhindern unnötig große Downloads.
  • Das LCP-Bild darf nicht verzögert geladen werden.
  • Bilder außerhalb des ersten Sichtbereichs können Lazy Loading nutzen.
  • Die Sichtprüfung bleibt auch bei automatisierter Kompression notwendig.

FAQ

Ist AVIF immer besser als WebP?

Nein. AVIF erzeugt bei vielen Fotos kleinere Dateien, kann aber länger für die Kodierung benötigen. WebP ist bei schnellen Uploadprozessen und vorhandenen CMS-Workflows häufig praktischer. Das Ergebnis muss am jeweiligen Motiv verglichen werden.

Welche Kompressionsstufe verhindert sichtbare Qualitätsverluste?

Eine allgemein gültige Stufe gibt es nicht. Encoder verwenden unterschiedliche Skalen. Die Qualität sollte schrittweise reduziert und bei der vorgesehenen Darstellungsgröße kontrolliert werden.

Braucht eine Website noch JPEG als Rückfallformat?

Aktuelle große Browser unterstützen WebP und AVIF. Eine JPEG- oder PNG-Variante bleibt dennoch sinnvoll, wenn ältere Browser, spezielle WebViews, externe Programme oder nicht vollständig bekannte Nutzerumgebungen berücksichtigt werden müssen.

Soll das Titelbild mit Lazy Loading geladen werden?

Nein. Ein sofort sichtbares Titelbild und besonders ein mögliches LCP-Bild sollten normal geladen werden. Lazy Loading ist für Bilder gedacht, die erst nach dem Scrollen sichtbar werden.

Kann eine JPEG-Datei direkt in AVIF umgewandelt werden?

Ja. Besser ist jedoch der Export aus einer hochwertigen Masterdatei. Eine bereits stark komprimierte JPEG-Datei kann sichtbare Fehler enthalten, die bei einer weiteren Umwandlung bestehen bleiben oder deutlicher werden.

Reicht ein einziges AVIF für Smartphone und Desktop?

Technisch kann ein Bild auf beiden Geräten erscheinen. Effizient ist das nicht. Mehrere Breiten mit srcset sorgen dafür, dass ein Smartphone keine unnötig große Desktopdatei laden muss.

WebP und AVIF reduzieren die Bildgröße besonders wirksam, wenn Formatwahl, Pixelmaße und responsive Auslieferung gemeinsam geplant werden. AVIF eignet sich häufig als bevorzugte Variante. WebP bietet eine robuste zweite Ebene. Eine klassische Rückfallversion schützt zusätzlich vor Problemen in älteren oder speziellen Umgebungen.

Quelle: MDN Web Docs, web.dev, Chrome for Developers, Alliance for Open Media und GoogleChromeLabs Squoosh.