WebP und AVIF: schnellere Website durch moderne Bildformate

WebP und AVIF sind moderne Bildformate, die Fotos und Grafiken bei gleicher Qualität deutlich kleiner machen als das alte JPG oder PNG. Kleinere Dateien bedeuten kürzere Ladezeiten - und genau darum dreht sich alles, wenn du eine schnelle Website willst.

WebP wurde 2010 von Google entwickelt. Es kann sowohl verlustbehaftet (wie JPG) als auch verlustfrei (wie PNG) komprimieren, beherrscht Transparenz und sogar Animationen. Gegenüber einem JPG sparst du bei vergleichbarer Qualität grob 25 bis 35 Prozent Dateigröße.

AVIF ist der jüngere Nachfolger, basiert auf dem Videocodec AV1 und wird von der Alliance for Open Media getragen (unter anderem Google, Netflix, Mozilla). AVIF komprimiert noch stärker: gegenüber JPG sind oft 50 Prozent und mehr drin, dazu kommt eine bessere Wiedergabe von Farbverläufen und HDR.

Kurz gesagt: Beide Formate liefern die gleiche optische Qualität mit weniger Bytes. AVIF gewinnt bei der Kompression, WebP punktet beim breiteren Browser-Support und schnelleren Encoding. In der Praxis nutzt du beide zusammen und lieferst dem Browser jeweils das beste Format, das er versteht. Wie das technisch sauber geht, zeigen wir weiter unten mit dem <picture>-Element.

Bilder sind auf den meisten Websites der größte Datenposten - oft 50 Prozent und mehr des gesamten Seitengewichts. Wer sie auf WebP oder AVIF umstellt, reduziert genau diesen Brocken und macht die Seite spürbar schneller, ohne am Design etwas zu ändern.

Schnellere Bilder zahlen direkt auf die Core Web Vitals ein, Googles Messwerte für Nutzererlebnis:

• LCP (Largest Contentful Paint): Das größte sichtbare Element ist häufig ein Bild (Hero, Produktfoto). Ein leichteres Bild lädt früher, der LCP-Wert sinkt.
• CLS (Cumulative Layout Shift): Indirekt profitierst du, wenn Bilder schneller stehen und nicht nachträglich Layout verschieben.

Die Core Web Vitals sind ein bestätigter Ranking-Faktor. Eine schnellere Seite ranked nicht automatisch auf Platz eins, aber sie verbessert die Ausgangslage und senkt die Absprungrate. Deine konkreten Werte siehst du im Bericht zu den Core Web Vitals, dazu lohnt sich unser Ratgeber zur Google Search Console.

Ein Beispiel aus der Praxis: Wir haben für einen Kunden eine Startseite mit acht Produktfotos von JPG auf AVIF mit Fallback umgestellt. Die Bilder schrumpften von 2,4 MB auf rund 0,9 MB, der LCP fiel im Schnitt von 3,1 auf 1,8 Sekunden - ohne sichtbaren Qualitätsverlust. Das ist der typische Effekt: weniger Bytes, gleiches Bild, bessere Werte.

Faustregel: AVIF für maximale Kompression, WebP als breit unterstützte Allzweckwaffe, JPG und PNG nur noch als Fallback oder für Spezialfälle. Die folgende Tabelle zeigt die wichtigsten Unterschiede auf einen Blick.

KriteriumAVIFWebPJPGPNGKompression (Foto)Sehr starkStarkMittelSchwachTransparenz (Alpha)JaJaNeinJaAnimationJaJaNeinNeinBrowser-SupportSehr gut (ab 2024 breit)Praktisch überallÜberallÜberallEncoding-TempoLangsamSchnellSehr schnellSchnellTypischer EinsatzHero, Fotos, VerläufeAllzweck, Logos mit AlphaFallbackPixelgenaue Grafik, Fallback

Was heißt das für die Praxis?

• Fotos und großflächige Bilder: AVIF zuerst, WebP als zweite Option, JPG als Fallback.
• Grafiken mit Transparenz (Logos, Icons): WebP oder AVIF statt PNG, das spart oft die Hälfte.
• Scharfe Liniengrafiken und Logos in einer Farbe: Hier ist SVG häufig besser als jedes Pixelformat.

Wichtig: AVIF braucht beim Erzeugen mehr Rechenzeit. Das spielt beim einmaligen Export oder im Build keine Rolle, kann aber bei Echtzeit-Bildverarbeitung relevant werden. Für die meisten Websites ist die Kombination AVIF plus WebP plus JPG-Fallback die robusteste Wahl.

Du brauchst keine teure Software, um JPG oder PNG in WebP und AVIF umzuwandeln - es reicht ein Converter, ein Build-Tool oder dein CMS. Wichtig ist nur, dass du vor der Umwandlung die Maße stimmst und die Originaldateien behältst.

Bewährter Workflow in drei Schritten:

1. Skalieren: Bring das Bild zuerst auf die maximale Anzeigegröße. Ein Foto, das nur 800 Pixel breit dargestellt wird, braucht keine 4000 Pixel. Das ist der größte Hebel überhaupt.
2. Komprimieren: Exportiere nach WebP und AVIF, Qualitätsstufe rund 75 bis 80 reicht für Fotos meist völlig.
3. Mehrere Größen erzeugen für Responsive Webdesign, damit Handy und Desktop jeweils die passende Auflösung bekommen.

Geeignete Werkzeuge:

• Squoosh.app (von Google, im Browser): ideal für einzelne Bilder, mit Live-Vorschau und Größenvergleich.
• cwebp und avifenc (Kommandozeile): für Batch-Verarbeitung, etwa cwebp -q 80 bild.jpg -o bild.webp.
• Sharp (Node.js): die Engine hinter vielen Build-Tools, perfekt zum Automatisieren.
• Online-Converter wie CloudConvert oder Convertio: praktisch, wenn du schnell ein einzelnes Format brauchst (auch der häufig gesuchte Weg webp to jpg zurück).

Für eine professionelle Website lohnt sich Automatisierung: Bilder einmal hochladen, das System erzeugt alle Formate und Größen selbst. Genau das übernimmt zum Beispiel Astro, dazu gleich mehr.

Mit dem <picture>-Element lieferst du jedem Browser das beste Format, das er versteht, und behältst immer ein sicheres Fallback. Der Browser geht die Quellen von oben nach unten durch und nimmt die erste, die er unterstützt.

Ein vollständiges Beispiel mit AVIF, WebP und JPG-Fallback:

<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Team bei der Arbeit" width="1200" height="800" loading="lazy">
</picture>

Wichtige Details, die oft vergessen werden:

• Das <img> am Ende ist Pflicht. Es ist gleichzeitig Fallback und trägt alt, width und height.
• width und height angeben: So reserviert der Browser den Platz und vermeidet Layout-Sprünge (besserer CLS-Wert).
• loading="lazy" für Bilder unterhalb des sichtbaren Bereichs. Das Hero-Bild bekommt stattdessen fetchpriority="high" und kein Lazy Loading.

Für verschiedene Auflösungen kombinierst du das mit srcset und sizes, etwa srcset="hero-800.avif 800w, hero-1600.avif 1600w". Der Browser wählt dann selbst die passende Größe je nach Display. Wenn du das Layout zusätzlich per CSS steuerst, achte darauf, dass die Bilder mit max-width: 100% flexibel bleiben. So spielen Format, Größe und responsive Layout sauber zusammen.

Wenn du mit Astro arbeitest, musst du WebP und AVIF nicht von Hand erzeugen - die eingebauten Komponenten <Image> und <Picture> übernehmen das im Build automatisch. Astro nutzt dafür im Hintergrund die Bild-Engine Sharp.

Für ein einzelnes optimiertes Bild reicht die <Image>-Komponente:

---
import { Image } from 'astro:assets';
import hero from '../assets/hero.jpg';
---
<Image src={hero} alt="Team bei der Arbeit" width={1200} format="avif" />

Willst du echtes Format-Switching mit Fallback, nimmst du <Picture>. Astro erzeugt dann automatisch ein vollständiges <picture>-Markup:

---
import { Picture } from 'astro:assets';
import hero from '../assets/hero.jpg';
---
<Picture src={hero} formats={['avif', 'webp']} alt="Team bei der Arbeit" />

Was Astro dir dabei abnimmt:

• Erzeugt AVIF und WebP plus ein JPG-Fallback im Build.
• Setzt width und height automatisch, das beugt Layout-Sprüngen vor.
• Generiert mit widths mehrere Auflösungen samt passendem srcset.

So sieht unser Standard für ravnmedia-Projekte aus: Bilder kommen als hochauflösendes Original ins Repo, Astro baut daraus alle Formate und Größen. Das hält den Workflow simpel und die Seiten schnell. Ähnliche Mechanismen gibt es übrigens in Next.js (next/image) oder über Plugins in den meisten CMS - das Prinzip bleibt gleich.

Die meisten Probleme entstehen nicht durch das Format selbst, sondern durch falsche Einbindung. Diese Fehler sehen wir in Audits immer wieder - und sie kosten dich Ladezeit und Rankingpunkte.

• Riesige Bilder skaliert per CSS: Ein 4000-Pixel-Bild, das nur 600 Pixel breit angezeigt wird, bleibt auch als AVIF unnötig groß. Erst auf die echte Anzeigegröße bringen, dann konvertieren.
• Kein Fallback: Wer nur <source> ohne abschließendes <img> setzt, riskiert leere Stellen in alten Browsern. Das <img> gehört immer dazu.
• Fehlendes Lazy Loading: Ohne loading="lazy" lädt der Browser alle Bilder sofort, auch die ganz unten. Umgekehrt darf das Hero-Bild kein Lazy Loading haben, sonst leidet der LCP.
• width und height vergessen: Ohne feste Maße springt das Layout beim Laden, der CLS-Wert verschlechtert sich.
• Überkompression: AVIF mit zu niedriger Qualität erzeugt matschige Flächen und Artefakte. Qualität 75 bis 80 ist meist der gute Mittelweg.
• Alles in ein Format zwingen: Ein scharfes Logo oder Icon ist als SVG besser aufgehoben als als AVIF.

Konkreter Praxisfall: Bei einem Relaunch hatte das Team zwar auf WebP umgestellt, aber alle Bilder in Originalauflösung ausgespielt. Die Seite war kaum schneller. Erst das Skalieren auf die Anzeigegröße plus Lazy Loading brachte den LCP unter zwei Sekunden. Die Reihenfolge ist also: erst Größe, dann Format, dann Einbindung.

Die wichtigsten Unterschiede der Formate auf einen Blick:

Für Detailfragen zu Formaten und Browser-Support lohnen sich diese Referenzen (beide werden laufend aktualisiert):

• MDN Web Docs: Bildformate für das Web - technische Referenz zu allen Formaten.
• caniuse.com: AVIF-Browser-Support - tagesaktuelle Support-Tabelle.