Bilder komprimieren für das Web
— der vollständige Leitfaden 2026

Wie du Bilder so komprimierst, dass deine Website schneller lädt, weniger Bandbreite frisst, in Google besser rankt — und trotzdem scharf bleibt. Mit konkreten Zahlen, Format-Empfehlungen, Tool-Vergleich und einem Schritt-für-Schritt-Workflow.

Von Jonathan Hedderich · Veröffentlicht: 1. Juni 2026 · Aktualisiert: 22. Juni 2026 · ~22 Minuten Lesezeit

Warum Bildkomprimierung 2026 wichtiger ist denn je

Bilder machen heute etwa 50% des durchschnittlichen Webseitengewichts aus — laut HTTP Archive Web Almanac im Median 880 KB pro Seite, und das ist nur der Median. Auf E-Commerce-Plattformen liegt der Wert oft bei zwei bis vier Megabyte allein für Produktfotos. Wer hier nicht aktiv komprimiert, verschenkt drei Dinge gleichzeitig: Geschwindigkeit, Geld und Sichtbarkeit.

Geschwindigkeit, weil das Bild die längste Strecke vom Server zum Endgerät ist. Auf einem 4G-Mobilanschluss mit 10 Mbit/s lädt ein 800-KB-Hero-Bild zwischen 600 und 1500 Millisekunden — und blockiert in dieser Zeit den Largest Contentful Paint (LCP), das wichtigste Core-Web-Vitals-Signal. Ein gleichwertig aussehendes WebP mit 180 KB ist in 130 ms da. Das ist nicht ein bisschen schneller. Das ist eine andere Liga.

Geld, weil Bandbreite Geld kostet. Auf Vercel, Cloudflare, AWS oder bei jedem CDN wird CDN-Egress pro Gigabyte abgerechnet. Eine Site mit 100.000 Pageviews pro Monat, jeweils 2 MB Bildgewicht, generiert 200 GB Traffic — das sind je nach Anbieter zwischen 8 und 40 Euro monatlich allein für Bilder. Eine sinnvolle Komprimierung schneidet das auf einen Bruchteil.

Sichtbarkeit, weil Google seit dem Page Experience Update (Mai 2021) und der vollständigen Migration auf Core Web Vitals (März 2024) Ladegeschwindigkeit als Ranking-Faktor offiziell einbezieht. Ein langsamer LCP wirft dich nicht aus dem Index, aber er drückt deine Position um Plätze nach unten — und in einem Wettbewerb, in dem die Top-3-Ergebnisse über 60% aller Klicks abbekommen, ist das relevant. Mehr Hintergrund in unserem Core-Web-Vitals-Beitrag.

Was passiert beim Komprimieren — die Mechanik in 4 Minuten

Um die richtigen Entscheidungen treffen zu können, lohnt sich ein kurzer Blick in die Theorie. Bildkomprimierung kommt in zwei Varianten: verlustfrei (lossless) und verlustbehaftet (lossy). Bei verlustfreier Komprimierung wird das Bild byte-exakt rekonstruiert; nur die Speicherung wird durch geschickte Algorithmen (Deflate, LZ77, Huffman) effizienter. PNG arbeitet so, ebenso WebP-Lossless und FLIF/JPEG-LS in spezialisierten Anwendungen.

Verlustbehaftete Komprimierung nutzt psychovisuelle Modelle: Sie verwirft gezielt Informationen, die das menschliche Auge ohnehin schlecht wahrnimmt. JPG, WebP-Lossy und AVIF teilen das Bild in 8×8-Pixel-Blöcke (DCT bei JPG, Transform-Blöcke bei AV1) und quantisieren die hohen Frequenz-Anteile, denen wir gegenüber unempfindlich sind. Wer schon einmal in ein stark komprimiertes JPG hineingezoomt hat, sieht das Ergebnis: die typischen 8×8-Blockgrenzen und die „mosquito noise" an scharfen Kanten.

Der Trick ist, die Quantisierung gerade so weit zu treiben, dass die Datei klein wird, aber das Auge die Artefakte noch nicht sieht. Wo dieser Sweet-Spot liegt, hängt vom Format ab — und ist die wichtigste praktische Frage, die wir gleich beantworten.

Die Formate 2026 im direkten Vergleich

Sechs Formate sind 2026 für das Web relevant. Hier die wichtigste Faustregel auf einen Blick:

Detaillierte Format-Tiefen findest du in unseren spezialisierten Guides: AVIF erklärt, WebP-Guide, JPG vs PNG, PNG vs WebP und der große Bildformate-Vergleich.

Die Qualitäts-Sweet-Spots — Zahlen, die du dir merken kannst

Die Standard-Empfehlung „Qualität 80" stammt aus den 1990er-Jahren und galt für klassisches JPG. Heute, mit modernen Encodern und besseren Formaten, sind die Sweet-Spots fein justierter. Aus unzähligen A/B-Tests an Foto-, Grafik- und Screenshot-Material kristallisiert sich Folgendes heraus:

• JPG (Mozjpeg-Encoder) — Sweet-Spot zwischen 75 und 82. Unter 65 sichtbare Artefakte, über 88 nur noch marginal größere Datei ohne sichtbaren Qualitätsgewinn. Default-Empfehlung: 78 für Hero-Bilder, 72 für Thumbnails.
• WebP (lossy) — Sweet-Spot bei 70–80. WebP toleriert niedrigere Qualitätswerte besser als JPG, weil sein Quantisierungs-Layer feiner ist. Default: 75 für Web-Fotos.
• AVIF — Sweet-Spot bei 50–65. AVIF braucht überraschend niedrige Qualitätswerte für äquivalente Ergebnisse. Default: 55 für Standard-Fotos, 65 für Hauttöne und Gesichter (besonders empfindlich gegen Bandung-Artefakte).
• PNG (verlustfrei) — Qualität wird hier nicht skaliert; stattdessen Optimierung: durchlaufe Palette-Reduktion (256 → 64 Farben), entferne ungenutzte Chunks, nutze einen Encoder wie pngquant (verlustbehaftet) oder oxipng (verlustfrei).

Wer diese Werte sklavisch befolgt, macht in 95% der Fälle keine sichtbaren Fehler. Wenn du Hauttöne, Verläufe oder feine Schraffuren komprimierst, gehe in der Skala um 5 nach oben — diese Inhalte sind anfälliger für Quantisierungs-Artefakte.

Wie du Qualitäts-Sweet-Spots im Multi-Format-Vergleich findest

Statt zu raten, kannst du den Sweet-Spot empirisch ermitteln. Lade ein repräsentatives Bild im JNRT-Pixel-Multi-Format-Vergleich hoch — er rendert dasselbe Bild gleichzeitig in JPG, PNG, WebP und AVIF bei der gewählten Qualität. Daneben siehst du die resultierende Dateigröße in einer Mono-Font-Anzeige. So vergleichst du in einer Minute, was sonst zehn Tool-Wechsel braucht.

Im Detail-View kannst du dann pixelgenau vergleichen: Slider, Side-by-Side, 1:1-Zoom — und entscheiden, ob der Qualitäts-Wert noch passt oder ob du noch etwas reduzieren kannst. Wenn deine Augen den Unterschied bei Qualität 75 nicht sehen, ist Qualität 80 verschenkter Speicherplatz.

Tool-Vergleich: was die wichtigsten Komprimier-Dienste 2026 wirklich können

Es gibt grob drei Klassen von Online-Komprimierern. Ich vergleiche hier die fünf bekanntesten Vertreter unter den Aspekten Datenschutz, Format-Support, Qualität und Kosten.

Die strukturelle Unterscheidung: Lokale Tools (JNRT Pixel, Squoosh) verarbeiten das Bild in deinem Browser und schicken nichts hoch — DSGVO-freundlich, schnell, geeignet auch für vertrauliche Inhalte wie Familienfotos, Patientenaufnahmen, Produktrenderings. Cloud-Tools (TinyPNG, ShortPixel, iLoveIMG) brauchen einen Upload — meist schneller bei sehr großen Stapelverarbeitungen, dafür mit Privatsphäre-Trade-off und Account-Mechanik.

Wer regelmäßig große Mengen identisch komprimieren will (etwa ein Newsletter-Versand), kann den lokalen Ansatz mit Browser-PWA-Installation kombinieren. Dazu unten mehr.

Schritt-für-Schritt: Bilder für eine WordPress-Site komprimieren

Beispiel-Workflow für eine realistische Aufgabe: Du betreibst einen Reiseblog und hast 30 Urlaubsfotos, die im neuen Beitrag eingebettet werden sollen. Das Ziel: Web-optimiert in unter zehn Minuten.

1. Auswahl filtern. Lieber 12 gute Fotos als 30 mittelmäßige — Komprimierung ersetzt keine Bildauswahl.
2. Originale sichern. Lege eine Kopie der Originale in einen Cloud-Ordner. Komprimierung ist verlustbehaftet — du willst die Quelle behalten.
3. Maximale Ausgabebreite festlegen. Auf einer Standard-WordPress-Site mit Container-Breite 1100 px brauchst du keine Hero-Bilder größer als 2200 px (Retina-Faktor 2). Skaliere im Resizer alles über diesem Wert.
4. Multi-Format öffnen. Im Multi-Format-Vergleich alle 12 Bilder per Drag-and-Drop hineinziehen.
5. Qualität setzen. Auf 75 (für JPG/WebP), die Sticky-Settings-Leiste am unteren Bildschirmrand übernimmt das für alle Bilder gleichzeitig.
6. Bestes Format pro Bild wählen. Die "Optimal-Summary" zeigt automatisch das kleinste Format pro Datei. Bei Hauttönen ist es meist AVIF; bei wenigen Farben und harten Kanten WebP; bei Logos PNG.
7. Filename-Affix setzen. Mit Prefix 2026-italien- und Suffix -web bekommen alle Downloads konsistente Namen.
8. ZIP herunterladen. Ein Klick, alle 12 Bilder als WebP oder AVIF gebündelt.
9. In WordPress hochladen. WordPress 6+ erkennt WebP automatisch; AVIF braucht aktuell noch das WebP Express oder EWWW-Plugin als Fallback. Tipp: parallel ein JPG-Fallback für Browser ohne AVIF-Support, idealerweise per <picture>-Tag.

Mehr Detail-Tipps zu WordPress-Bildern haben wir in einem eigenen Beitrag: Bilder für WordPress optimieren.

Responsive Images — srcset & <picture>

Komprimieren ist die eine Hälfte. Die andere Hälfte ist Ausliefern in der richtigen Größe an das richtige Endgerät. Ein 2400-px-Hero auf einem 360-px-iPhone-Display ist verschwendete Bandbreite, egal wie gut komprimiert. Die Lösung ist srcset:

<img
  src="/img/hero-1200.jpg"
  srcset="
    /img/hero-480.webp  480w,
    /img/hero-800.webp  800w,
    /img/hero-1200.webp 1200w,
    /img/hero-1800.webp 1800w
  "
  sizes="(max-width: 600px) 90vw, 1100px"
  alt="..."
  loading="lazy"
  decoding="async"
/>

Der Browser pickt das passende Bild basierend auf Display-Pixel-Dichte und Viewport-Breite. Wer noch einen Schritt weiter geht, kombiniert das mit <picture> und liefert AVIF für moderne Browser plus WebP- und JPG-Fallback:

<picture>
  <source type="image/avif" srcset="/img/hero-1200.avif 1200w, ..." />
  <source type="image/webp" srcset="/img/hero-1200.webp 1200w, ..." />
  <img src="/img/hero-1200.jpg" alt="..." loading="lazy" />
</picture>

So bekommen iOS-Safari-Nutzer AVIF, Android-Chrome ebenfalls AVIF, ein Firefox-Nutzer auf einem 8 Jahre alten Laptop bekommt das WebP, und ein theoretischer Internet-Explorer-User (es gibt ihn nicht mehr) bekäme das JPG. Die art direction wird elegant gelöst, weil der Browser den optimalen Match selbst aussucht.

Lazy Loading — der oft vergessene Multiplikator

Selbst die beste Komprimierung hilft nichts, wenn alle 30 Bilder beim ersten Seitenaufruf parallel geladen werden. Das Attribut loading="lazy" sorgt dafür, dass nur die im Viewport sichtbaren Bilder sofort heruntergeladen werden — alles unter dem ersten Bildschirmrand wird erst beim Scrollen nachgeladen. Das ist heute Browser-nativ unterstützt; eine Polyfill braucht es nicht mehr.

Wichtig: Das Hero-Bild über dem Fold sollte explizit nicht lazy geladen werden — das wäre kontraproduktiv für den LCP. Stattdessen: loading="eager" auf das Hero, loading="lazy" auf alles, was unter den ersten Pixel kommt.

Häufige Anfänger-Fehler — und wie du sie vermeidest

Aus mehreren Audits typischer Mittelstandsseiten kristallisieren sich fünf Fehler heraus, die in Kombination 80% der Bildgewicht-Probleme erklären:

1. 4000×3000-px-Original im 600-px-Slot. Das CMS zeigt das Bild „nur 600 px breit" an, lädt aber das Original. Lösung: Beim Upload immer auf realistische Maximal-Maße skalieren.
2. PNG für Fotos. PNG ist genial für Logos und Pixel-Grafiken — für Fotos ist es 4–8× größer als JPG bei identischer Wahrnehmung. Faustregel: PNG nur bei Transparenz oder < 16 Farben.
3. Qualität 95+. Die zusätzlichen Bytes ab Qualität 90 sind unsichtbar, aber teuer. 78 reicht für 99% der Use-Cases.
4. EXIF/XMP-Metadaten. Eine moderne Smartphone-Kamera packt 50–200 KB Metadaten in jedes Foto — GPS, Linsen-Modell, Bearbeitungs-Historie. Im Web-Output haben die nichts verloren. Der EXIF-Editor entfernt sie in einem Klick.
5. Keine modernen Formate. „WebP funktioniert nicht in alten Browsern" — stimmt nicht mehr. WebP wird seit 2020 von allen Evergreen-Browsern unterstützt, AVIF seit 2023. Wer 2026 noch reines JPG ausliefert, lässt 30% Performance auf der Straße liegen.

Best Practices nach Use-Case

E-Commerce Produktfotos

Hier ist die Wahrnehmung von Details kritisch — niemand kauft einen Stoff, dessen Textur unscharf aussieht. Empfehlung: WebP bei Qualität 80, mit srcset-Varianten von 320, 640, 960, 1280 px Breite, plus einer 2400-px-Variante für Zoom. AVIF zusätzlich anbieten, wenn das Shop-System es unterstützt. Mehr im E-Commerce-Bilder-Guide.

Blog-Artikel

Inline-Bilder im Fließtext sind selten geschäftskritisch in der Detail-Wahrnehmung. Hier kannst du aggressiver komprimieren: WebP bei 72, AVIF bei 55, maximale Ausgabebreite 1200 px für ein typisches Content-Layout. Hero-Bilder behandelst du wie Produktfotos.

Landing-Pages

Hier zählt der erste Eindruck — und damit der LCP. Hero-Bild als AVIF + WebP-Fallback, vorab in zwei Größen für Mobile und Desktop. fetchpriority="high" auf das Hero setzen, damit der Browser es priorisiert lädt. Background-Bilder per CSS lazy laden mit IntersectionObserver, wenn sie nicht direkt nach oben sichtbar sind.

Social-Media-Vorschauen (Open Graph)

Hier brauchst du JPG (Facebook), nicht WebP — Meta-Tools können WebP noch nicht durchgängig lesen. Empfehlung: 1200×630 px, JPG bei Qualität 85, ohne Komprimierungs-Artefakte. Mehr im Social-Media-Bildgrößen-Guide.

Build-Automatisierung — wenn du wirklich skalieren willst

Browser-Tools wie JNRT Pixel sind perfekt für Ad-hoc-Komprimierungen oder kleinere Stapel. Wer eine Site mit hunderten Bildern pflegt, will das automatisieren. Drei bewährte Wege:

• Next.js / Astro / SvelteKit Image-Komponenten. Generieren AVIF/WebP automatisch beim Build, mit responsive srcset out of the box. Empfohlen für moderne Static-Site-Stacks.
• Sharp / libvips in Node.js. Die Bibliothek hinter den meisten Build-Tools. Direkt in einem Build-Script ansprechbar, sehr performant — ein Foto-Verarbeitungs-Pipeline-Standard.
• Cloud-CDNs mit On-the-fly Transformation. Cloudflare Images, Imgix, Cloudinary, Vercel Image Optimization — schicken das Originalbild einmal hin, der CDN macht den Rest. Praktisch für CMS-getriebene Sites, aber kostenpflichtig.

Kontrolle: ist meine Komprimierung erfolgreich?

Drei kostenlose Werkzeuge zur Validierung:

• Google PageSpeed Insights — testet deinen LCP, gibt eine Bewertung und konkrete Empfehlungen. Mobil und Desktop getrennt.
• Lighthouse in Chrome DevTools — der gleiche Audit lokal, ohne dass deine URL öffentlich erreichbar sein muss. Praktisch für Staging-Tests.
• WebPageTest.org — der Klassiker, mit Filmstrip-Visualisierung der Ladezeit. Zeigt dir Frame für Frame, wie deine Seite aufbaut. Pflichtwerkzeug, wenn du eine konkrete Optimierungs-Aktion belegen willst.

Wenn dein LCP unter 2,5 Sekunden liegt, bist du im grünen Bereich. Zwischen 2,5 und 4,0 Sekunden „needs improvement", über 4 Sekunden „poor" — und Google straft das im Ranking ab.

Praktische Workflow-Empfehlung

Wenn du nach diesem Artikel direkt anfangen willst, ist das hier der schnellste Weg in eine spürbar schnellere Site:

1. Identifiziere die 5 größten Bilder auf deiner Startseite (DevTools → Network → sort by size).
2. Lade alle 5 im JNRT-Pixel-Multi-Format-Vergleich hoch.
3. Wähle pro Bild das beste Format aus der Optimal-Summary.
4. Lade das ZIP, ersetze die Originale auf der Site.
5. Miss den LCP vorher und nachher mit Lighthouse — die Differenz ist meist beeindruckend.

Diese fünf Schritte schaffen erfahrungsgemäß zwischen 30 und 70 Prozent Gewichtsreduktion auf der durchschnittlichen Mittelstandssite. Das ist ein halber Werktag Arbeit für eine Performance-Verbesserung, die sonst nur ein größerer Hosting-Wechsel oder ein Theme-Refactor bringen würde.

Fazit & nächste Schritte

Bildkomprimierung 2026 ist kein Hexenwerk. Mit den drei Werkzeugen aus diesem Artikel — modernen Formaten (WebP, AVIF), klugen Qualitäts-Sweet-Spots (75, 55) und der Browser-lokalen Verarbeitung — schaffst du in einem halben Tag, was vor zehn Jahren ein dedizierter Build-Server in einer Woche bewältigt hätte. Und alles ohne Upload, ohne Cloud-Account, ohne Abo.

Lies als nächstes: unsere Anleitung zur Bildgrößen-Reduktion, der AVIF-Deepdive, oder der Spezial-Vergleich Generatoren vs. KI. Wenn du gleich loslegen willst, starte direkt mit dem Multi-Format-Vergleich.