Bilder fürs Web optimieren ohne sichtbaren Qualitätsverlust

Von Manuel Hack, ihp media · Aktualisiert am 21. Juni 2026

Wer eine Website auf Ladegeschwindigkeit optimiert, landet schnell beim Thema Bilder. Nicht weil Bildoptimierung besonders komplex wäre, sondern weil Bilder auf den meisten Seiten schlicht die größte Einzelmaßnahme sind. Dieser Ratgeber zeigt den kompletten Prozess: von der richtigen Bildgröße über Komprimierung und Formatwahl bis zu responsiven Varianten und Lazy Loading.

Warum Bilder die häufigste Bremse sind

Ein unkomprimiertes Foto aus einer modernen Digitalkamera bringt schnell 8 bis 15 Megabyte mit. Selbst nach einem einfachen Speichern als JPEG aus dem Bearbeitungsprogramm bleiben oft 2 bis 4 Megabyte übrig. Auf einer Startseite mit zehn solcher Bilder summiert sich das zu einer Datenmenge, für die ein Mobilnutzer mit mittlerer Verbindung mehrere Sekunden wartet.

Google misst diese Verzögerung über die Core Web Vitals. Der Largest Contentful Paint (LCP) erfasst, wie lange es dauert, bis das größte sichtbare Element vollständig geladen ist. In den meisten Fällen ist dieses Element ein Bild. Liegt der LCP-Wert über 2,5 Sekunden, wertet Google das als schlechte Nutzererfahrung. Wie man diesen Wert gezielt verbessert, erklärt der Artikel Largest Contentful Paint verbessern.

Der häufigste Grund, warum Websites langsam sind, ist kein mangelhafter Server und kein schlechtes Hosting. Es sind unkomprimierte, falsch dimensionierte Bilder. Das ist die gute Nachricht: Das Problem lässt sich beheben, ohne die Infrastruktur anzufassen.

Schritt 1: Richtige Bildgröße und Dimensionierung

Lighthouse prüft genau diese Diskrepanz: Ist das ausgelieferte Bild mindestens 4 Kilobyte größer als die gerenderte Version, schlägt die Prüfung „Bilder richtig dimensionieren“ fehl. In der Praxis liegen die Einsparungen meist deutlich höher.

Die Regel ist einfach: Bilder werden in der maximalen Anzeigebreite exportiert, die sie auf der Seite jemals einnehmen werden, multipliziert mit dem höchsten Pixeldichtefaktor der Zielgeräte. Für ein Bild, das im Layout maximal 800 Pixel breit wird und auch auf Retina-Displays (2x) scharf aussehen soll, ist die Exportgröße 1.600 Pixel Breite.

Für die Höhe gilt entsprechendes. Seitenverhältnis und absolute Pixelzahl sollten vor dem Export feststehen. Ein Bild, das man später im CSS beschneidet, trägt die abgeschnittenen Pixel trotzdem mit jedem Seitenaufruf aus.

Praktische Werkzeuge für den Mac: Das eingebaute sips Kommandozeilenwerkzeug skaliert Bilder per Skript ohne Qualitätsverlust im Exportprozess. Für den grafischen Weg eignet sich ImageOptim zur verlustfreien Komprimierung; für die Skalierung vorher einen Schritt mit Vorschau oder sips einbauen.

Schritt 2: Komprimierung einstellen

Es gibt zwei grundlegend verschiedene Komprimierungsansätze, die unterschiedliche Einsatzbereiche haben.

Verlustfreie Komprimierung

Verlustfreie Komprimierung entfernt redundante Daten in der Dateistruktur, ohne irgendeinen Pixel zu verändern. Statt jedes Pixel einzeln zu kodieren, fasst sie Wiederholungen zusammen: Eine reihe von 50 gleichfarbigen Pixeln wird als „50 mal Farbe X“ gespeichert. Das Ergebnis ist bit-identisch mit dem Original, aber die Datei ist kleiner. Diese Methode eignet sich für PNG-Dateien, bei denen Schärfe und Exaktheit wichtiger sind als maximale Verkleinerung, etwa für Screenshots mit Text, Logos oder Grafiken mit klaren Kanten.

Verlustbehaftete Komprimierung

Verlustbehaftete Komprimierung geht einen Schritt weiter: Sie verwirft Bildinformationen, die das menschliche Auge bei normaler Betrachtung nicht auflöst. Bei einem Foto eines Sonnenuntergangs mit weichen Farbverläufen lassen sich 70 Prozent der Dateigröße einsparen, ohne dass jemand einen Unterschied sieht. Bei einem technischen Diagramm mit feinen Linien ist die Toleranz kleiner.

Die optimale Qualitätsstufe hängt vom Motiv ab. Faustregel für den Einstieg: 80 Prozent für Fotos, 90 Prozent für Produktbilder, in die Besucher stark hineinzoomen. Den genauen Punkt findet man am schnellsten mit einem direkten Vorher-nachher-Vergleich. Squoosh (kostenlos, läuft im Browser) zeigt beide Versionen nebeneinander und die Dateigröße in Echtzeit beim Bewegen des Qualitätsreglers.

Automatisierung im WordPress-Umfeld

Wer Bilder dauerhaft kontrolliert optimiert haben möchte, ohne jeden Upload manuell anzufassen, setzt im WordPress-Umfeld auf Plugins wie Imagify oder ShortPixel. Beide konvertieren und komprimieren beim Upload automatisch, bieten eine Stapelverarbeitung für bereits vorhandene Bilder in der Mediathek und hinterlegen Fallback-Versionen für ältere Browser.

Schritt 3: Das richtige Format wählen

Die Formatwahl hat mehr Einfluss als die Komprimierungsstufe, weil verschiedene Formate grundlegend unterschiedlich effizient kodieren.

WebP ist heute für Fotos und komplexe Grafiken erste Wahl. Aktuelle Browser unterstützen es vollständig. Bei vergleichbarer Bildqualität liefert WebP im Schnitt 25 bis 35 Prozent kleinere Dateien als JPEG. Die verlustfreie WebP-Komprimierung schlägt verlustfreies PNG typischerweise um rund 26 Prozent.

AVIF ist das modernste der verbreiteten Formate und komprimiert nochmals besser als WebP. Moderne Browser unterstützen es, ältere Systeme und einige Unternehmensumgebungen noch nicht. Wer AVIF ausliefert, braucht deshalb zwingend einen Fallback (WebP oder JPEG) über das <picture>-Element. Mehr zu den genauen Komprimierungsvorteilen und der Browser-Unterstützung steht im Artikel WebP und AVIF: Moderne Bildformate.

JPEG bleibt als Fallback relevant, ist für neue Projekte aber nicht mehr die erste Wahl. Es gibt keine Transparenz, keine nennenswerte Verlustfreiheit. Für Fotos, die an ältere Browser geliefert werden müssen, ist es aber nach wie vor besser als PNG.

PNG ist richtig für Grafiken mit Transparenz, scharfen Kanten oder inhaltsreichen Screenshots. Für Fotos ist PNG fast immer falsch: Die unkomprimierte oder verlustfrei komprimierte Version desselben Fotos kann fünf bis zehnmal so groß sein wie das entsprechende JPEG.

SVG gehört für Logos, Icons und Illustrationen gesetzt. SVG skaliert verlustfrei in jede Größe, lässt sich direkt im HTML einbetten und profitiert stark von Textkomprimierung (gzip/Brotli) auf dem Server, weil SVG-Dateien aus reinem Text bestehen.

Schritt 4: Responsive Images mit srcset und sizes

Selbst ein perfekt komprimiertes WebP-Bild ist verschwenderisch, wenn es für einen 1.920 Pixel breiten Monitor erstellt, aber unverändert an ein Smartphone mit 390 Pixel Displaybreite geliefert wird. Genau das passiert, wenn man auf responsive Auslieferung verzichtet.

Das srcset-Attribut löst das Problem. Es nennt dem Browser mehrere Bildversionen in unterschiedlichen Breiten, und der Browser entscheidet selbst, welche Version am besten passt. Er kennt dafür mehr Informationen als jede serverseitige Logik: Verbindungsgeschwindigkeit, Pixeldichte des Displays, aktuelle Fenstergröße und gespeicherte Nutzerpräferenzen.

Das sizes-Attribut ergänzt diese Information: Es sagt dem Browser, wie viel Platz das Bild im Layout einnimmt. Ohne sizes geht der Browser davon aus, dass das Bild die volle Fensterbreite einnimmt, was in Mehrspaltenlayouts zu unnötig großen Versionen führt.

Ein vollständiges, praxisnahes Beispiel:

<img
  src="produkt.webp"
  srcset="produkt-480.webp 480w,
          produkt-800.webp 800w,
          produkt-1200.webp 1200w,
          produkt-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         33vw"
  alt="Produktbeschreibung"
  width="1600"
  height="900"
>

Das sizes-Attribut liest sich von oben nach unten: Bis 600 Pixel Fensterbreite nimmt das Bild die volle Breite ein, bis 1.200 Pixel die halbe, darüber ein Drittel. Der Browser berechnet daraus die optimale Quellversion.

Für Art Direction, also Bilder, die sich in Beschnitt oder Seitenverhältnis je nach Bildschirm unterscheiden sollen, ist das <picture>-Element die richtige Wahl. Es erlaubt zusätzlich, moderne Formate mit Fallback zu kombinieren:

<picture>
  <source srcset="bild.avif" type="image/avif">
  <source srcset="bild.webp" type="image/webp">
  <img src="bild.jpg" alt="Bildbeschreibung" width="800" height="600">
</picture>

Die technische Spezifikation beider Attribute ist in der MDN-Dokumentation zu responsiven Images vollständig dokumentiert. Googles Empfehlungen für die Praxis fasst die web.dev-Anleitung zu responsiven Images zusammen.

width und height immer setzen. Diese beiden Attribute erscheinen auf den ersten Blick wie ein Detail, sind aber wichtig: Der Browser kann damit den Platz für das Bild reservieren, bevor es geladen hat. Ohne diese Attribute verschiebt sich das Layout beim Laden, was den Cumulative Layout Shift (CLS) verschlechtert, einen weiteren Core-Web-Vitals-Wert.

Schritt 5: Lazy Loading richtig einsetzen

Natives Lazy Loading ist eine der einfachsten Maßnahmen: Ein einzelnes Attribut, kein JavaScript, keine Bibliothek. Browser, die es nicht kennen, ignorieren das Attribut einfach.

<img
  src="galerie-bild.webp"
  loading="lazy"
  width="800"
  height="600"
  alt="Galeriebild"
>

Chrome lädt lazy-geladene Bilder bereits dann, wenn sie sich dem sichtbaren Bereich nähern, etwa 1.250 Pixel bei 4G-Verbindung oder 2.500 Pixel bei 3G. Diese Schwellwerte gelten für Chrome; Firefox und Safari verwenden eigene, abweichende Werte. In den meisten Fällen ist das Bild also vollständig geladen, bevor der Nutzer bis dorthin scrollt.

Die wichtigste Regel: Hero-Bilder, Hauptproduktbilder im oberen Seitenbereich und alles, was beim ersten Laden sichtbar ist, bekommen loading="lazy" nicht. Diese Bilder sollen sofort laden, weil sie den LCP-Wert direkt beeinflussen. Genau das erklärt der Artikel Lazy Loading richtig einsetzen mit weiteren Details zur Implementierung.

Ergänzend gibt es fetchpriority="high" für besonders wichtige Bilder: Damit signalisiert man dem Browser, dieses Bild bevorzugt zu laden. Auf das LCP-Bild der Seite setzt man idealerweise fetchpriority="high" und weglassen von loading="lazy".

Übersicht: Maßnahmen, Einsparung, Werkzeuge

Schritt-für-Schritt: Bilder für den Launch vorbereiten

Folgende Schritte gelten für jedes Bild, das auf eine neue oder neu gestaltete Website kommt. Der Aufwand lohnt sich einmal systematisch zu investieren, denn nachträgliches Optimieren kostet mehr Zeit.

1. Verwendungszweck klären: Wird das Bild als Hero-Bild eingesetzt? Als Produktbild im Shop? Als kleines Thumbnailbild in einer Liste? Je nach Zweck unterscheidet sich die maximale Darstellungsbreite und damit die Exportgröße.
2. Maximale Darstellungsbreite bestimmen: Im Layout (CSS oder Browser-Entwicklertools) prüfen, wie breit das Bild maximal dargestellt wird. Für Retina-Displays mit 2x-Pixeldichte diese Zahl verdoppeln. Das ist die Exportbreite.
3. Skalieren: Das Bild auf die Exportbreite verkleinern, ohne es zu strecken. Höhe wird proportional berechnet.
4. Format wählen: Foto? Dann WebP, mit AVIF-Version für modernste Browser. Logo oder Icon? SVG. Grafik mit Transparenz? PNG.
5. Komprimierung einstellen: In Squoosh oder dem Exportdialog des Grafikprogramms die Qualitätsstufe auf 80 Prozent setzen und per Schieberegler prüfen, ob der Unterschied sichtbar ist. Wenn nicht, fertig. Wenn doch, auf 85 oder 90 Prozent erhöhen.
6. Mehrere Größenstufen exportieren: Für responsive Images werden typischerweise drei bis vier Varianten benötigt, etwa 480w, 800w, 1.200w und 1.600w. Diese in srcset eintragen.
7. HTML schreiben: width, height, alt, srcset und sizes setzen. Für LCP-Bild: fetchpriority="high", kein loading="lazy". Für alle anderen Bilder unterhalb des Folds: loading="lazy".
8. Mit Lighthouse prüfen: In Chrome-Entwicklertools unter „Lighthouse“ einen Performance-Report erzeugen. Der Abschnitt zu Bildoptimierungen listet verbleibende Potenziale mit konkreten Einsparungen auf.

<img
  src="BILD-800.webp"
  srcset="BILD-480.webp 480w,
          BILD-800.webp 800w,
          BILD-1200.webp 1200w,
          BILD-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  width="1600"
  height="900"
  alt="BESCHREIBUNG DES BILDINHALTS"
  fetchpriority="high"
>

<img
  src="BILD-800.webp"
  srcset="BILD-480.webp 480w,
          BILD-800.webp 800w,
          BILD-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         800px"
  width="1200"
  height="675"
  alt="BESCHREIBUNG DES BILDINHALTS"
  loading="lazy"
>

Praxisbeispiel

In einem Projekt sahen wir einen Onlineshop, dessen Startseite auf einem Mobiltelefon 8,4 Sekunden für den Largest Contentful Paint brauchte. Der Wert war messbar, aber die Ursache unklar: Das Hosting war solide, das Theme nicht überladen.

Ein Lighthouse-Report zeigte schnell, wo das Problem lag. Das Hero-Bild war 2.400 Pixel breit, 3,1 Megabyte groß und als PNG gespeichert. Es wurde auf dem Smartphone mit 390 Pixeln Breite dargestellt. Der Browser lud also ein Bild mit 38-facher Pixelzahl im Vergleich zu dem, was er tatsächlich darstellen musste. Dazu kam loading="lazy" auf demselben Bild, was den Start des Ladevorgangs künstlich verzögerte.

Nach der Optimierung: Bild auf 1.600 Pixel maximale Breite skaliert, als WebP mit 82-prozentiger Qualität exportiert, vier srcset-Varianten angelegt (400w, 800w, 1.200w, 1.600w), loading="lazy" entfernt und stattdessen fetchpriority="high" gesetzt. Das Hero-Bild hatte danach 87 Kilobyte statt 3.100 Kilobyte. Der LCP fiel auf 1,8 Sekunden. Der Einsatz: zwei Stunden Arbeit für dieses eine Bild und die Einrichtung des Imagify-Plugins für alle künftigen Uploads.

Sofort-Checkliste

• Sind alle Bilder auf die maximale Darstellungsbreite skaliert (keine unkomprimierten Originale)?
• Werden Fotos als WebP ausgeliefert, mit JPEG-Fallback für ältere Browser?
• Ist verlustbehaftete Komprimierung auf 80–85 Prozent eingestellt?
• Hat das <img>-Tag srcset-Varianten für verschiedene Bildschirmbreiten?
• Ist das sizes-Attribut korrekt gesetzt (passt es zur tatsächlichen Layoutbreite)?
• Haben alle <img>-Tags width und height (zur Vermeidung von Layout Shift)?
• Hat das LCP-Bild fetchpriority="high" und kein loading="lazy"?
• Haben alle Bilder unterhalb des sichtbaren Bereichs loading="lazy"?
• Ist ein automatisierter Prozess für zukünftige Uploads eingerichtet (Plugin oder Buildschritt)?
• Hat Lighthouse keine ungenutzten Bildoptimierungspotenziale mehr gemeldet?

Häufige Fragen

Verliere ich Bildqualität, wenn ich von JPEG auf WebP wechsle?

Bei gleichem oder leicht höherem Qualitätswert ist der Unterschied für das menschliche Auge nicht erkennbar. WebP liefert kleinere Dateien, weil das Format effizienter komprimiert, nicht weil es mehr Bildinformation verwirft als JPEG. Wer auf Nummer sicher gehen möchte, konvertiert mit einer höheren Qualitätsstufe und vergleicht das Ergebnis direkt mit dem Original, zum Beispiel in Squoosh.

Muss ich alle bestehenden Bilder manuell neu hochladen?

Nein. WordPress-Plugins wie Imagify oder ShortPixel konvertieren und komprimieren bestehende Mediatheken im Stapelbetrieb. Der Vorgang läuft im Hintergrund durch, ohne dass jedes Bild einzeln angefasst werden muss.

Welche Dateigröße sollte ein Bild fürs Web haben?

Eine feste Grenze gibt es nicht, aber klare Richtwerte helfen bei der Einordnung. Vollflächige Hero-Bilder sollten idealerweise unter 150 Kilobyte bleiben, Produktbilder im Shop unter 80 Kilobyte, kleine Vorschaubilder deutlich darunter. Diese Werte gelten für WebP bei mittlerer Qualitätsstufe und hängen stark vom Motiv ab.

Was ist der Unterschied zwischen srcset und dem picture-Element?

srcset bietet dem Browser mehrere Auflösungsvarianten desselben Bildes zur Auswahl an. Der Browser entscheidet. Das <picture>-Element hingegen erlaubt, dem Browser Regeln vorzuschreiben: bei dieser Fensterbreite dieses Bild, bei jenem Browser-Support jenes Format. Es eignet sich für Art Direction und für Format-Fallbacks (AVIF → WebP → JPEG).

Verbessert Bildoptimierung das Google-Ranking direkt?

Nicht als isolierter Ranking-Faktor. Ladegeschwindigkeit und Core Web Vitals fließen aber in die Bewertung ein, und Bilder sind der häufigste Engpass bei diesen Werten. Wer Bilder optimiert, verbessert in der Regel Largest Contentful Paint und Cumulative Layout Shift, was sich auf die Nutzererfahrungsbewertung durch Google auswirkt.

Sollte ich ein CDN für Bilder einsetzen?

Für Websites mit überwiegend deutschem Publikum ist der geografische Vorteil eines CDN begrenzt. Relevant sind die Nebeneffekte: automatische Formatkonvertierung, moderne Übertragungsprotokolle (HTTP/3) und korrekte Caching-Header ohne manuelle Konfiguration. Wer noch kein CDN einsetzt, gewinnt mit der Imagify- oder ShortPixel-Integration schon viel.