Bilder fürs Web vorbereiten: Maße, Format, Qualität

Bilder sind auf fast jeder Website der mit Abstand größte Posten. Eine Seite mit sechs Handyfotos lädt 25 MB, obwohl der Text darauf in ein paar Kilobyte passt. Wer daran etwas ändert, macht die Seite spürbar schneller — und Ladezeit ist einer der wenigen Faktoren, die Google offen als Rankingsignal benennt.

Drei Entscheidungen genügen, und sie gehören in diese Reihenfolge.

1. Die Maße — der größte Hebel

Ein Bild braucht so viele Bildpunkte, wie es angezeigt wird. Mal zwei, weil moderne Bildschirme mit doppelter Punktdichte arbeiten. Mehr ist verschenkt.

Wo das Bild erscheint	Breite
Bild in der Textspalte	800 px
Großes Beitragsbild	1600 px
Bildschirmbreites Hero	1920 px
Vorschaubild in einer Liste	400–600 px
Logo im Kopfbereich	2× der Anzeigebreite

Der Unterschied ist gewaltig: Von 4000 auf 1600 Pixel Breite bleiben 16 Prozent der Bildpunkte übrig — 84 Prozent sind weg, bevor überhaupt komprimiert wurde. Keine Qualitätseinstellung der Welt holt so viel heraus. Der Bild-Verkleinerer hält dabei das Seitenverhältnis, sodass nichts verzerrt.

Das ist auch der Grund, warum „ich komprimiere das Bild schon" oft nicht reicht: Ein 4000 Pixel breites Foto bei 60 Prozent Qualität ist immer noch größer als dasselbe Foto bei 1600 Pixeln und 80 Prozent — und sieht schlechter aus.

2. Das Format

WebP ist 2026 die Voreinstellung fürs Web. Es erzeugt bei gleicher sichtbarer Qualität rund 25 bis 35 Prozent kleinere Dateien als JPEG, kann Transparenz wie PNG, und alle aktuellen Browser unterstützen es seit Jahren.

JPEG bleibt richtig, wenn die Datei irgendwo landet, wo Altsysteme mitreden — manche Bewerbungsportale, Behördenformulare, Druckereien, ältere Warenwirtschaft.

PNG ist für Fotos die falsche Wahl: verlustfrei, aber um ein Vielfaches schwerer. Richtig ist es bei Logos, Screenshots mit Text, Diagrammen, Strichzeichnungen — überall dort, wo harte Kanten und wenige Farben zusammenkommen. Dort erzeugt JPEG sichtbare Schlieren.

AVIF komprimiert noch etwas besser als WebP, kodiert aber langsamer und wird nicht überall gleich gut unterstützt. Für die meisten Seiten ist WebP der bessere Kompromiss.

Faustregel: Foto → WebP, notfalls JPEG. Grafik mit harten Kanten → PNG.

3. Die Kompression — mit Blick, nicht mit Zahl

Für Fotos liegt der Sweet Spot bei 75 bis 80 Prozent. Darunter werden Blockmuster in Himmel und weichen Verläufen sichtbar, darüber wird die Datei ohne erkennbaren Gewinn schwerer.

Aber Zahlen sind hier weniger wert als Augen. Deshalb zeigt der Bild-Komprimierer Vorher und Nachher bei 100 Prozent Zoom nebeneinander — eine eingepasste Vorschau würde genau die Artefakte verstecken, um die es geht. Zieh den Regler ein paar Mal hin und her: Was du dort nicht siehst, sieht auch sonst niemand.

Was viele übersehen

• Breite und Höhe im HTML angeben. Ohne width und height springt das Layout, sobald das Bild eintrifft. Dieser Sprung ist eine der drei Core Web Vitals und einer der einfachsten Punkte, die man verschenken kann.
• loading="lazy" für alles unterhalb der Falz. Bilder, die man erst nach dem Scrollen sieht, müssen nicht sofort geladen werden — aber ausgerechnet das erste, große Bild sollte nicht lazy sein, sonst verzögert man genau das Element, an dem die Ladezeit gemessen wird.
• Alt-Texte schreiben. Nicht für Google, sondern für Menschen, die die Seite vorlesen lassen. Dass Suchmaschinen sie auch lesen, ist ein Nebeneffekt.
• Metadaten entfernen. Fotos tragen Aufnahmezeit und oft GPS-Koordinaten mit sich. Auf einer öffentlichen Seite hat beides nichts verloren.
• Screenshots nicht krumm skalieren. 70 Prozent macht Schrift unscharf, weil Bildpunkte zwischen zwei Zielpunkten landen. Halbieren oder lassen.

Die Kette in Kurzform

1. Auf die Anzeigebreite mal zwei verkleinern.
2. Als WebP ausgeben (JPEG nur, wenn es sein muss).
3. Bei 75–80 Prozent komprimieren und im Vergleich gegenprüfen.
4. Im HTML width, height, alt setzen und alles unterhalb der Falz lazy laden.

Vier Schritte, ein paar Minuten pro Bild — und aus 25 MB werden 800 KB, ohne dass es jemand sieht.