Was ist der größte Hebel: Format-Wahl oder Quality-Stufe?

Die Pixel-Anzahl. Ein Hero-Bild von 4000x2700 Pixeln auf 1920x1080 herunterzuskalieren spart 64 Prozent der Datei, ohne dass eine Quality-Stufe oder ein Format-Wechsel daran herankommt. Erst die Bildgröße auf die tatsächliche Anzeigegröße bringen, dann Format und Quality wählen.

Reicht es, einfach immer 1920 Pixel Breite zu nutzen?

Für Hero-Bilder ja, für alles andere nein. Ein Thumbnail in einer Listenansicht ist 200 bis 400 Pixel breit, ein Inline-Bild im Fließtext meist 600 bis 800. Ein 1920er-Bild auf 400er-Slot ist Verschwendung von Bandbreite und manchmal auch von Rendering-Zeit. Modernes srcset liefert die passende Variante automatisch.

Lohnt sich AVIF zusätzlich zu WebP?

Für trafficstarke Bilder ja, für den Rest meist nicht. AVIF ist nochmal 15 bis 25 Prozent kleiner als WebP, kostet aber Encoding-Zeit (Faktor 5 bis 20 langsamer) und der Browser-Support liegt 2026 bei rund 95 Prozent. Für ein Hero-Bild der Startseite lohnt der zusätzliche Build, für 200 Produkt-Thumbnails meist nicht.

Sollte ich loading='lazy' oder loading='eager' nutzen?

Eager nur für das Hero-Bild im sofort sichtbaren Bereich (LCP-Kandidat). Lazy für alles, was unterhalb des Folds liegt. Browser laden eager-Bilder priorisiert, lazy-Bilder erst beim Annähern an den Viewport. Falsch gesetztes lazy auf dem Hero-Bild verzögert messbar den Largest Contentful Paint.

Bilder für das Web optimieren: Format, Größe, Quality im Zusammenspiel

Ein einzelnes Bild gut zu komprimieren ist einfach. Eine ganze Website mit hundert Bildern sauber zu optimieren ist die Übung. Hier steht der praktische Workflow von Master-Datei bis srcset.

Ein gut komprimiertes Bild ist die halbe Miete. Die andere Hälfte ist die Frage, wie das Bild auf die Seite kommt: in welcher Auflösung, in welchen Varianten, mit welchen Attributen am <img>. Hier kostet die falsche Entscheidung leicht 30 bis 50 Prozent Bandbreite und manchmal Lighthouse-Punkte. Der Workflow ist nicht kompliziert, aber er braucht Disziplin.

Schritt 1: die Bildgröße auf die Realität bringen

Der mit Abstand größte Hebel ist die Pixel-Anzahl. Bilder kommen oft direkt aus der Kamera mit 4000 bis 6000 Pixeln Kantenlänge. Auf einem Hero-Slot werden sie auf 1920 angezeigt, auf einem Inline-Slot auf 800, auf einem Thumbnail auf 200. Die übrigen Pixel zu komprimieren bringt nichts, weil sie nie gerendert werden.

Konkret: ein 4000x2700-Foto hat 10,8 Megapixel. Auf 1920x1296 herunterskaliert sind das 2,5 Megapixel. Dasselbe als 800x540-Inline-Variante sind 0,4 Megapixel. Vom Original bis zur Inline-Variante sind das ein Faktor 25 weniger Pixel. Ein gut komprimiertes JPEG mit Quality 80 macht aus 4000er-Original etwa 800 KB, aus 1920er-Variante 130 KB, aus 800er-Variante 40 KB.

Die richtige Reihenfolge ist deshalb: Bildgröße zuerst auf die maximale Anzeigegröße herunterskalieren, dann komprimieren. Wer das umgekehrt macht, komprimiert Pixel, die nachher beim Resize-Schritt sowieso verschwinden.

Schritt 2: das richtige Format

Mit der Bildgröße auf Soll ist die Format-Wahl klar:

Foto? JPEG bei Quality 78-82, WebP zusätzlich für moderne Browser.
Logo, Screenshot, Grafik? PNG, optimiert.
Transparenz nötig? PNG, oder WebP mit Alpha.
Animation? Möglichst kurzes MP4 oder WebP-animated, GIF nur wenn nicht anders möglich.

Für trafficstarke Sites lohnt sich zusätzlich AVIF als drittes Format. Das <picture>-Element liefert dem Browser die passende Variante:

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg" alt="..." width="1920" height="1080"
       loading="eager" decoding="async" />
</picture>

Die Reihenfolge der <source> ist entscheidend: der Browser nimmt das erste Format, das er versteht. AVIF zuerst, dann WebP, dann das JPEG-Fallback im <img>.

Schritt 3: srcset für variierende Anzeigegrößen

Wenn dasselbe Bild je nach Bildschirmgröße in unterschiedlichen Auflösungen gerendert wird (Hero-Bild auf Mobil 600 Pixel breit, auf Desktop 1920), lohnt sich srcset. Der Browser kennt die Display-Größe und die Pixel-Dichte und lädt nur die nötige Variante.

<img
  src="/img/hero-1920.jpg"
  srcset="
    /img/hero-600.jpg 600w,
    /img/hero-960.jpg 960w,
    /img/hero-1280.jpg 1280w,
    /img/hero-1920.jpg 1920w,
    /img/hero-2560.jpg 2560w
  "
  sizes="(max-width: 600px) 100vw,
         (max-width: 1280px) 80vw,
         1920px"
  alt="..."
  width="1920" height="1080"
  loading="eager"
/>

Was hier passiert: der Browser schaut die Display-Breite und Pixel-Dichte an, rechnet die effektive Bildbreite aus, sucht in der srcset-Liste die kleinste Variante, die noch reicht, und lädt nur die. Auf einem 360-Pixel-Smartphone ohne Retina werden 600 Pixel geladen, auf einem 4K-Monitor mit 2x-Pixel-Dichte die 2560-Variante. Spart bei Mobile-Nutzern oft 70 Prozent der Bandbreite.

Die sizes-Angabe ist Pflicht und sagt dem Browser, wie groß das Bild auf der konkreten Seite gerendert wird. Ohne sizes nimmt der Browser an, das Bild belegt die volle Viewport-Breite, und lädt entsprechend großzügig.

Schritt 4: width, height, loading

Drei Attribute am <img>, die regelmäßig vergessen werden und messbare Folgen haben:

width und height setzen. Das verhindert Layout-Shift während des Ladens. Der Browser reserviert den Platz für das Bild, bevor es geladen ist. Ohne diese Angaben rutschen Inhalte um das Bild herum, was den Cumulative Layout Shift in die Höhe treibt und Lighthouse-Punkte kostet.

loading="lazy" für alles unterhalb des Folds. Spart Bandbreite und beschleunigt den ersten Paint. Der Browser lädt das Bild erst, wenn der Nutzer in die Nähe scrollt. Funktioniert in allen modernen Browsern.

loading="eager" (oder weglassen) für das Hero-Bild. Lazy auf dem Hero-Bild ist ein Anti-Pattern, weil der Browser die LCP-Komponente dann später lädt als möglich. Ein lazy-Hero kostet leicht 200 bis 500 Millisekunden Largest Contentful Paint.

decoding="async". Erlaubt dem Browser, das Bild parallel zur HTML-Parse zu dekodieren. Kein Nachteil, kleiner Gewinn.

alt-Text. Pflicht für Accessibility, hilft SEO. Bei rein dekorativen Bildern leer (alt=""), bei Content-Bildern beschreibend.

Schritt 5: die Master-Datei stabil halten

Eine Pipeline-Falle, die regelmäßig auftaucht: die Web-Variante wird zur neuen Master-Datei. Beim nächsten Redesign greift jemand auf das 1920er-JPEG mit Quality 80 zurück, vergrößert es für eine neue Auflösung und re-komprimiert. Das Ergebnis ist ein dreimal komprimiertes Bild mit deutlich sichtbaren Artefakten.

Sauber ist: eine Master-Kopie pro Bild, entweder als PNG oder als JPEG mit Quality 95. Aus dieser Master-Kopie werden alle Web-Varianten neu generiert, jedes Mal. Wenn das Design ändert und plötzlich eine andere Größe gebraucht wird, geht der Schritt vom Master aus, nicht von einer Web-Variante.

Tools, die diesen Workflow automatisieren:

sharp (Node.js) und Pillow (Python) in Build-Pipelines, generieren aus einer Master-Datei alle nötigen srcset-Varianten plus WebP- und AVIF-Versionen.
Astro Image-Service, Next.js Image-Komponente, Nuxt Image: Framework-integriert, machen das Pipeline-Setup pro Bild zur 3-Zeilen-Sache.
Cloudinary, Imgix, ImageKit: hosted Services für Sites ohne eigene Build-Pipeline. Kostet, spart Setup.
Browser-Tools wie bild-komprimieren.de: für die Optimierung einzelner Bilder ohne Pipeline. Wer keine Build-Pipeline hat, generiert die Varianten einmalig im Browser und lädt sie hoch.

Ein realistischer Workflow auf einer typischen Website

Für eine Site mit 50 Content-Bildern ohne Build-Pipeline:

Master-Bilder im Original (Smartphone-Foto, Stock-Quelle) in einem Ordner sammeln, niemals direkt veröffentlichen.
Pro Bild im Browser-Kompressor drei Varianten erzeugen: 1920 Pixel breit (Hero/Lightbox), 800 Pixel breit (Inline), 400 Pixel breit (Thumbnail). Format-Wahl je nach Motiv.
Pro Variante zusätzlich eine WebP-Version generieren, ein Fallback-JPEG bleibt im <img>.
Im HTML mit <picture> + srcset + sizes + width/height + loading einbinden.
Master-Bilder weiter aufbewahren für künftige Layout-Änderungen.

Das ist Disziplin, kein Hexenwerk. Wer das einmal sauber durchzieht, hat eine Site mit deutlich besseren Performance-Werten und keine Bilder, die im Browser auf Mobile 2 MB ziehen.