Bildkomprimierung im Detail: JPG, PNG oder WebP richtig wählen

Veröffentlicht am 2026-04-13 8 Min. Lesezeit

Zusammenfassung (TL;DR)

Letztes Wochenende habe ich ein 4,2 MB großes Katzenfoto in Squoosh mit WebP-Qualität 80 konvertiert. Heraus kamen 380 KB – also eine Reduktion um 91 % – und ich kann es bei keiner realistischen Bildschirmgröße vom Original unterscheiden. Genau das soll verlustbehaftete Komprimierung leisten. Jedes Mal, wenn ich diese Lektion vergesse, öffne ich einen Blog und warte über LTE drei Sekunden auf ein 2 MB schweres Hero-JPG, woraufhin sich die Erkenntnis von ganz allein wieder einstellt.

Die Wahl eines Bildformats ist weniger eine Suche nach „dem Besten” als vielmehr die Zuordnung von Format und Zweck. Für Fotografien mit kontinuierlichen Tonwerten halten verlustbehaftete Formate wie JPEG, verlustbehaftetes WebP und AVIF die Dateien klein und perceptuell kaum unterscheidbar; bei vergleichbarer Bildqualität liefert WebP üblicherweise rund 25–35 % kleinere Dateien als JPEG, und AVIF landet je nach Encoder-Einstellungen häufig 40–50 % unter JPEG. Für Logos, Icons, Screenshots und alles, wo scharfe Kanten oder Lesbarkeit von Text zählen, sind verlustfreie Formate wie PNG, verlustfreies WebP und TIFF die sicherere Wahl. Wenn du Transparenz und Animation gleichzeitig brauchst, sind WebP, APNG und AVIF die Hauptkandidaten. Die Browserunterstützung ist Anfang 2026 sehr breit: WebP läuft seit Chrome 32 (2014), Firefox 65 und Safari 14 (Ende 2020); AVIF funktioniert in Chrome 85 (August 2020), Firefox 93 (Oktober 2021) und Safari 16 (September 2022) sowie neuer. Eine vernünftige Grundregel lautet „SVG für Vektorlogos, WebP oder AVIF für Fotos, PNG für Screenshots”, ergänzt um ein <picture>-Fallback auf JPEG, falls ältere Umgebungen unterstützt werden müssen.

Hintergrund und Konzepte

Verlustbehaftete Formate (JPEG, lossy WebP, AVIF) reduzieren die Dateigröße, indem sie Information verwerfen, gegen die das menschliche Sehsystem weniger empfindlich ist. Zwei Kerntechniken treiben das an: Quantisierung, die Frequenzkoeffizienten umso aggressiver rundet, je höher die Ortsfrequenz ist, und Chroma-Subsampling, bei dem Farbkanäle in geringerer Auflösung als die Luminanz gespeichert werden. 4:4:4 erhält die Chrominanz in voller Auflösung, das verbreitetere 4:2:0 halbiert sie in beide Richtungen. Diese Voreinstellung ist für die meisten Fotos in Ordnung, kann aber farbige Textkanten verschwimmen lassen – besonders rote und blaue Schrift auf dunklem Hintergrund.

JPEG, 1992 standardisiert, nutzt eine blockbasierte diskrete Kosinustransformation (DCT) auf 8x8-Pixel-Blöcken. WebP baut auf den Intra-Frame-Techniken des VP8-Videocodecs auf, AVIF auf dem Intra-Frame-Werkzeugkasten von AV1. Beide sind damit deutlich moderner als JPEG, was Vorhersage, Transformation und Quantisierung angeht – mit größeren Blockgrößen, gerichteter Prädiktion und besserer Entropiecodierung. PNG ist ein anderes Tier: ein verlustfreies Format aus der Deflate-Familie mit eingebautem Alphakanal und Palettenfarben. PNG verwirft niemals Daten, doch bei Fotos kostet diese Reinheit erheblich mehr Dateigröße.

Ein verwandtes Konzept ist progressives Decoding. Progressive JPEGs und interlaced PNGs erlauben es Betrachtern, sofort eine niedrigaufgelöste Version zu sehen, die mit weiteren Bytes verfeinert wird. WebP und AVIF werden heute meist in einem Durchgang decodiert, was vor allem bei sehr großen Bildern oder langsamen Verbindungen ins Gewicht fällt. SVG schließlich ist überhaupt kein komprimiertes Rasterformat, sondern eine Vektorbeschreibung; die Dateigröße hängt von der Anzahl der Formen und der Komprimierung des Quelltexts ab (gzip und brotli sind auf SVG-Quellen sehr effektiv).

Vergleich und Daten

Format	Verlustbehaftet	Verlustfrei	Transparenz	Animation	Typische Foto-Komprimierung	Browser-Unterstützung 2025
JPEG	Ja	Nein	Nein	Nein	Etwa 10:1	Alle Browser
PNG	Nein	Ja	Ja	APNG-Erweiterung	Etwa 2–3:1	Alle Browser
WebP	Ja	Ja	Ja	Ja	25–35 % kleiner als JPEG	Safari 14 (2020) und neuer, faktisch universell
AVIF	Ja	Ja	Ja	Ja	40–50 % kleiner als JPEG	Chrome 85+, Firefox 93+, Safari 16+
GIF	Ja (Palette, 256 Farben)	Nein	Nur 1-Bit	Ja	Schlecht für Fotos	Alle Browser

Behandle diese Zahlen als grobe Tendenzen. Reale Komprimierung hängt stark von Quellinhalt, Encoder, Preset und Zielqualität ab. Dasselbe JPEG bei Qualität 85 und Qualität 60 kann sich in der Größe um den Faktor 3–4 unterscheiden, und der Effizienzvorsprung von AVIF schmilzt mit schnellen Presets. Benchmarks von Google und Mozilla zwischen 2019 und 2023 berichteten WebP-Einsparungen von rund 26 % bis 34 % gegenüber JPEG bei gleichem SSIM und AVIF-Einsparungen von 40 % bis 50 % gegenüber JPEG – diese Bereiche setzen jedoch langsame Encoder-Presets und sauber abgestimmte Qualitätsziele voraus, nicht die Ein-Klick-Voreinstellungen üblicher Bildbearbeitungs-Apps.

Eine weitere Dimension sind Encode- und Decode-Kosten. JPEG decodiert auf jedem Gerät in Bruchteilen einer Millisekunde. WebP liegt nah dran. AVIF-Decoding ist CPU-intensiver, und AVIF-Encoding bei hohen Qualitätspresets kann Sekunden pro Bild kosten. Dieses Kostenprofil passt gut zu einer Build-Time-Asset-Pipeline, ist aber unangenehm, wenn ein Server jeden Upload nutzergenerierter Inhalte auf dem Hot Path neu encodieren soll.

Praxisszenarien

Szenario 1 – Blog-Thumbnails und Hero-Bilder. Ich habe kürzlich meine eigene Site auditiert und ein Hero-Bild mit 1,8 MB gefunden. Ein erneuter Export als WebP mit Qualität 82 brachte es auf 210 KB, und der Largest Contentful Paint der Seite fiel im Lighthouse-Test bei gedrosseltem 4G-Profil von 2,4 s auf 1,1 s. Nutze WebP standardmäßig als primäres Format und lasse ein <picture>-Element JPEG als Fallback für sehr alte Umgebungen ausliefern. Skaliere das exportierte Bild immer auf die tatsächliche CSS-Anzeigebreite; ein 3000 Pixel breites Foto in einen 600 Pixel breiten Container zu schicken, verschwendet unabhängig vom Format Bandbreite.

Szenario 2 – Logos und Icons. Wenn eine Vektorquelle existiert, exportiere zuerst SVG. Einmal habe ich eine Landingpage geprüft, auf der ein rotes Markenlogo als JPEG mit Qualität 75 exportiert war; die roten Kanten verliefen zu einem rosa Halo um jede Glyphe. Chroma-Subsampling 4:2:0 zerstört rote Kanten auf dunklem Grund schneller als fast alles andere. Liegt nur Rasterkunst vor, wähle PNG oder verlustfreies WebP. Behandle verlustbehaftete Komprimierung von Logos eher als Warnsignal denn als Optimierung.

Szenario 3 – Screenshots und UI-Aufnahmen. Screenshots gehören standardmäßig in PNG. Browser-Chrome, Code-Snippets und CJK-Schriften zeigen JPEG-Artefakte besonders deutlich – ich habe das gelernt, nachdem ein Doku-Reviewer in zwei aufeinanderfolgenden PRs „verschwommene Monospace-Schrift” markiert hatte. Wenn die Datei kleiner werden muss, greife zu pngquant (auf macOS brew install pngquant), um die Palette auf 256 Farben zu reduzieren; bei UI-Screenshots ist das Ergebnis fast nie sichtbar, und die Datei schrumpft oft um den Faktor 4–6. Für Doku-Sites lohnt es sich, PNG mit responsivem Image-Markup zu kombinieren, sodass Retina-Displays 2x-Assets erhalten und ältere Bildschirme die 1x-Variante laden – das spart meist mehr Bytes als ein Formatwechsel.

Szenario 4 – Archivierung von Quellmaterial. Für Originale, die du später erneut verarbeiten könntest (Fotomaster, Roh-Scans, Produktshots), bewahrst du eine verlustfreie Kopie als TIFF oder verlustfreies WebP im Cold Storage auf und leitest verlustbehaftete Auslieferungsvarianten on demand ab. Wiederholtes Re-Komprimieren eines verlustbehafteten JPEGs verschlechtert die Qualität bei jedem Zyklus („Generation Loss”), du willst also eine saubere Quelle haben, zu der du zurückkehren kannst.

Häufige Missverständnisse

„PNG ist immer die höchste Qualität.” Verlustfrei bedeutet perfekte Reproduktion, doch für Fotos übersetzt sich diese Reinheit in Dateien, die mehrfach so groß sind wie nötig. Auf mobilen Geräten schädigen mehrere Megabyte schwere Fotos die wahrgenommene Ladezeit und die Core Web Vitals.

„WebP funktioniert nicht in allen Browsern.” Seit Safari 14 Ende 2020 wird WebP von jedem Mainstream-Browser unterstützt. Ist Legacy-Support tatsächlich notwendig, ist ein <picture>-Element mit JPEG-Fallback eine saubere Lösung.

„AVIF ist magisch.” Die Kompressionseffizienz ist exzellent, doch das Encoding ist deutlich langsamer als bei JPEG oder WebP. Auf meinem M2 MacBook Air braucht avifenc --speed 4 für ein einzelnes 2400×1600-Foto 5–9 Sekunden; bei --speed 0 rechne mit 30 s oder mehr. Auch das Decoding auf älteren Mobilgeräten kann ein Thema sein. AVIF passt besser in Batch-Pipelines und Build-Time-Optimierung als in das Re-Encoding jedes Nutzer-Uploads auf dem Hot Path.

„Nimm einfach JPEG.” Das war bis etwa 2015 vernünftig, doch modernes WebP und AVIF liefern heute kleinere Dateien bei vergleichbarer Qualität mit universeller oder nahezu universeller Unterstützung. Neue Pipelines sollten WebP als Baseline behandeln, nicht JPEG.

„Höhere Qualitätsstufen sind immer den Aufwand wert.” Oberhalb von etwa Qualität 85 für JPEG oder WebP wächst die Dateigröße schneller als die wahrgenommene Qualität. Betrachter erkennen den Unterschied zwischen Qualität 85 und 95 selten, doch die Datei kann doppelt so groß sein. Miss mit einer perceptuellen Metrik (SSIM, butteraugli), statt dem Qualitätsregler eine lineare Skala zu unterstellen.

„Skalieren spielt keine Rolle, wenn ich gut komprimiere.” Die größten Einzelgewinne in der Bildauslieferung kommen meist daher, passend dimensionierte Bilder zu senden, und nicht aus Feinabstimmung der Komprimierung. Ein 800 Pixel breites WebP ist fast immer leichter als ein 3000 Pixel breites WebP, unabhängig vom Qualitätswert, weil du Pixel entfernst statt sie zu approximieren.

Checkliste

Ist die Quelle vektorbasiert? Wenn ja, speichere als SVG.
Brauchst du Transparenz?
- Ja und der Inhalt ist fotografisch: lossy WebP mit Alpha oder AVIF.
- Ja und der Inhalt ist ein Logo oder Icon: PNG oder verlustfreies WebP.
Brauchst du Animation? Animiertes WebP, APNG oder AVIF. Die 256-Farben-Palette von GIF ist für Fotos schwach.
Ist der Inhalt fotografisch oder gradientenlastig? Standard ist lossy WebP, dazu AVIF, wenn Bandbreite zählt.
Ist der Inhalt ein Screenshot oder textlastige UI? Bevorzuge PNG oder verlustfreies WebP.
Brauchst du maximale Kompatibilität? Verwende ein <picture>-Element mit AVIF → WebP → JPEG-Quellen in dieser Reihenfolge.

Quellen

MDN, „Image file type and format guide” — https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
web.dev, „Serve images in modern formats (WebP)” — https://web.dev/articles/serve-images-webp
AOMedia, „AV1 Image File Format (AVIF)“-Spezifikation — https://aomediacodec.github.io/av1-avif/
W3C, „Portable Network Graphics (PNG) Specification” — https://www.w3.org/TR/png/