Warum die Wahl des Bildformats wichtig ist
Bilder machen durchschnittlich 50 % der Datengröße einer Webseite aus. Laut HTTP Archive sind Bilder der größte einzelne Faktor für die Seitengröße – vor JavaScript, CSS und Schriften. Das richtige Format kann Ladezeiten halbieren, SEO-Rankings verbessern, den Bounce-Rate-Schwellenwert unter Core Web Vitals halten und Serverkosten senken.
Google hat 2021 mit der Page Experience Update-Komponente klar gemacht: Ladeperformance ist ein Ranking-Faktor. Bilder sind der Hebel mit dem größten Hebelarm – und gleichzeitig der am häufigsten vernachlässigte.
Echte Testergebnisse: Dateigrößen im Vergleich
Wir haben drei verschiedene Bildtypen konvertiert und die Dateigrößen gemessen:
Fotografie (4000 × 3000 Pixel, 12 MP)
| Format | Qualität | Dateigröße | Einsparung vs. JPG |
|---|---|---|---|
| PNG (verlustfrei) | – | 44,1 MB | – |
| JPG | 85 | 372 KB | Baseline |
| JPG | 90 | 746 KB | +100 % |
| WebP | 85 | 162 KB | −56 % |
| WebP | 90 | 238 KB | −68 % vs. JPG 90 |
Kleineres Foto (800 × 600 Pixel)
| Format | Qualität | Dateigröße | Einsparung vs. JPG |
|---|---|---|---|
| PNG (verlustfrei) | – | 1,9 MB | – |
| JPG | 85 | 28 KB | Baseline |
| WebP | 85 | 14 KB | −50 % |
Screenshot / UI (1920 × 1080 Pixel)
| Format | Qualität | Dateigröße | Einsparung vs. JPG |
|---|---|---|---|
| PNG (verlustfrei) | – | 668 KB | – |
| JPG | 85 | 14 KB | Baseline |
| WebP | 85 | 4 KB | −71 % |
Das Ergebnis ist eindeutig: WebP spart bei Fotos 50–56 % und bei Screenshots sogar 71 % gegenüber JPG bei gleicher Qualität. Das sind keine theoretischen Werte – das sind echte Konvertierungen mit ImageMagick und cwebp auf einem durchschnittlichen Server.
AVIF würde noch mehr sparen – Studien zeigen typisch 20–30 % zusätzlich gegenüber WebP – aber die Kodierzeit ist 2- bis 5-mal länger (je nach Encoder: SVT-AV1 schneller, libaom langsamer), und der Browser-Support ist noch nicht flächendeckend. Für Seiten mit tausenden Bildern kann die AVIF-Kodierzeit im CI/CD-Pipeline Minuten statt Sekunden kosten.
Verlustbehaftet vs. Verlustfrei: Was bedeutet das in der Praxis?
JPG und WebP (im verlustbehafteten Modus) arbeiten mit psychovisueller Kompression: sie entfernen Bildinformationen, die das menschliche Auge kaum wahrnimmt. Feine Farbnuancen, hochfrequente Details und Rauschen werden reduziert. Bei Qualität 85–90 ist das Ergebnis für Fotos praktisch nicht vom Original unterscheidbar.
Bei Screenshots, Logos und Textgrafiken ist die Sache anders: Hier sind scharfe Kanten wichtig, und verlustbehaftete Kompression erzeugt sichtbare Artefakte an Textkanten. Für diese Fälle ist PNG oder WebP Lossless die bessere Wahl – die Kompressionsraten sind bei solchen Motiven sogar besser als bei JPG, weil die gleichmäßigen Farbflächen effizient komprimiert werden.
Typische Entscheidungshilfe:
- Fotos → WebP Lossy Q85 (oder AVIF)
- Screenshots mit Text → WebP Lossless oder PNG
- Logos / Icons → SVG (Vektor, nicht Raster)
- Animationen → WebP Animated oder GIF (aber WebP ist 90 % kleiner)
Browser-Support
| Browser | JPG | WebP | AVIF |
|---|---|---|---|
| Chrome | ✅ | ✅ (seit 2012) | ✅ (seit 2020) |
| Firefox | ✅ | ✅ (seit 2019) | ✅ (seit 2021) |
| Safari | ✅ | ✅ (seit 2020) | ✅ (seit 2022) |
| Edge | ✅ | ✅ (seit 2020) | ✅ (seit 2024) |
| Internet Explorer | ✅ | ❌ | ❌ |
Seit 2021 unterstützen alle modernen Browser WebP – das Format ist production-ready. AVIF hat ebenfalls breite Unterstützung, ist aber bei Safari erst ab Version 16 (macOS Ventura, iOS 16) verfügbar. Nutzer mit älteren Apple-Geräten sehen AVIF-Bilder nicht.
Die Marktdurchdringung sieht so aus: Laut Can I Use nutzt Stand Mai 2026 über 97 % der globalen Browser-User WebP, und etwa 93 % unterstützen AVIF. Der verbleibende Unterschied ist primär Safari auf älteren macOS- und iOS-Versionen.
JPG bleibt als universelles Fallback unverzichtbar – nicht weil es besser wäre, sondern weil es das einzige Format ist, das wirklich jeder Browser seit 1993 versteht.
Empfehlung: Die Fallback-Kette
Die beste Strategie für moderne Websites ist eine gestaffelte Fallback-Kette mit dem <picture>-Element:
<picture>
<source srcset="bild.avif" type="image/avif">
<source srcset="bild.webp" type="image/webp">
<img src="bild.jpg" alt="Beschreibung" width="800" height="600">
</picture>Der Browser lädt das erste Format, das er unterstützt. So bekommt jeder Nutzer die bestmögliche Qualität bei minimaler Dateigröße – ohne dass du verschiedene Seiten für verschiedene Browser pflegen musst.
Praxis-Tipps
- JPG als Fallback – jeder Browser kann es, jeder Server cached es
- WebP als Standard – beste Balance aus Kompression und Kompatibilität
- AVIF für Vorreiter – noch kleinere Dateien, aber längere Kodierzeit
- PNG für Grafiken – Screenshots, Logos, Icons mit scharfen Kanten
- Niemals BMP – unkomprimiert und riesig, kein Grund es jemals zu nutzen
Core Web Vitals und Bildformate
Googles Core Web Vitals messen drei Metriken: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift). Bilder beeinflussen direkt LCP – das ist die Zeit, bis das größte sichtbare Element geladen ist. Bei einer Hero-Image-Website ist das fast immer ein Bild.
Ein 372 KB JPG-Hero-Image vs. 162 KB WebP: bei einer 3G-Verbindung (typisch 1,6 Mbps) spart WebP etwa 1 Sekunde Ladezeit. Auf 4G sind es immer noch ~200 ms. Das klingt wenig – aber bei Google ist der Unterschied zwischen „gut" (unter 2,5 s LCP) und „verbesserungsbedürftig" (2,5–4 s) oft genau diese Spanne.
Praktische Empfehlung für Webentwickler:
- Konvertiere alle Bilder zu WebP im Build-Prozess (SvelteKit, Next.js, Webpack – alle haben Plugins)
- Setze Breite und Höhe auf
<img>um CLS zu vermeiden - Nutze
loading="lazy"für Bilder unter dem Fold - Nutze
fetchpriority="high"für das LCP-Bild
Bildformate konvertieren mit wandlio
Wenn du deine Bilder schnell und ohne Upload konvertieren willst, probiere die wandlio-Browser-Konverter:
- JPG → WebP – Bilder fürs Web optimieren
- PNG → WebP – Grafiken verkleinern
- WebP → JPG – Fallback-Versionen erstellen
- HEIC → JPG – iPhone-Fotos kompatibel machen
- AVIF → JPG – AVIF für ältere Browser wandeln
- JPG → AVIF – Maximale Kompression für Vorreiter
Alle Bild-Konvertierungen laufen lokal in deinem Browser – deine Dateien werden nie hochgeladen. Kein Account, kein Upload, kein Warten.
Fazit
Für das Web von heute ist WebP der beste Kompromiss aus Kompression und Browser-Support. JPG bleibt das universelle Austauschformat. AVIF ist die Zukunft – bis zu 50 % kleiner als JPG bei gleicher Qualität (in Extremfällen mehr), lizenzfrei, HDR-fähig – und mit 93 % Browser-Support bereit für den produktiven Einsatz mit picture-Element-Fallback. Wer heute noch ausschließlich JPG ausliefert, verschenkt Leistungsreserven. Starte mit WebP, plane AVIF – und nutze wandlio.de für die Konvertierung.
Praktischer Workflow: Schritt-für-Schritt
Wie geht man die Umstellung in der Praxis an? Hier ein bewährter Workflow für Web-Projekte:
- Audit: Prüfe mit Lighthouse oder WebPageTest, wie viel Potenzial in der Bild-Optimierung steckt. Oft sind 30-50 % der Seitengröße rein auf unoptimierte Bilder zurückzuführen
- Build-Pipeline: Richte sharp oder squoosh im Build-Prozess ein. SvelteKit und Next.js haben eingebaute Image-Optimierung
- Formate: Liefere AVIF für moderne Browser (93 % Support) und WebP als Zwischenschritt (97 % Support). JPG bleibt der universelle Fallback
- Qualität: AVIF Q55-65, WebP Q80-85, JPG Q82-85. Diese Werte bieten die beste Größen-Qualitäts-Balance
- Lazy Loading: Nutze loading="lazy" für Bilder unter dem Fold. Kombiniert mit AVIF/WebP bringt das den größten Performance-Schub
- CDN: Cloudflare und Fastly bieten automatische Format-Konvertierung. Der Client sendet Accept-Header, das CDN liefert das beste Format
Mit diesem Workflow erreichst du typisch 50-70 % Reduktion der Bild-Übertragungsgröße – bei besserer oder gleicher visueller Qualität. Die Auswirkungen auf die Core Web Vitals sind messbar: Largest Contentful Paint (LCP) verbessert sich typisch um 1-2 Sekunden, Cumulative Layout Shift (CLS) bleibt bei width/height-Attributen stabil, und Interaction to Next Paint (INP) wird durch weniger Bandbreitenkonkurrenz indirekt verbessert. Google bestätigt: Seiten mit guten Core Web Vitals ranken im Durchschnitt 5-15 Plätze höher in den Suchergebnissen. Nutze zusätzlich das srcset-Attribut für responsive Bilder – kleine Bildschirme bekommen kleinere Dateien, was die Ladezeit auf Mobilgeräten weiter verbessert. Kombiniert mit AVIF/WebP und Lazy Loading erreichst du so LCP-Werte unter 2,5 Sekunden auf Mobilgeräten – der Schwellenwert für gutes Core Web Vitals Rating