Bilder gehören oft zu den größten Ressourcen einer Webseite. Gleichzeitig sind sie visuell wichtig und dürfen nicht einfach aggressiv verkleinert werden.
Eine gute Webstrategie behandelt deshalb nicht nur „Kompression“, sondern den gesamten Weg:
Motiv → Crop → Abmessungen → Format → Kompression → responsive Varianten → HTML → Priorität → Messung.
Schritt 1: Nur benötigten Inhalt behalten
Ein unnötig großer Ausschnitt kostet Pixel und Bytes.
Wenn ein Hero-Bild einen breiten Ausschnitt benötigt, ein Kartenbild aber nur ein Detail zeigt, können verschiedene Crops sinnvoll sein.
Art Direction ist manchmal effizienter als eine einzige Datei für alle Layouts.
Schritt 2: Pixelabmessungen bestimmen
Eine 5.000 Pixel breite Quelldatei ist selten nötig, wenn sie maximal 1.200 CSS-Pixel breit erscheint.
Der Leitfaden Welche Auflösung sollte ein Bild haben? erklärt das Verhältnis von CSS-Größe, Bildpixeln und Pixeldichte.
Mit dem Bildgrößen-Werkzeug können passende Varianten erstellt werden.
Schritt 3: Seitenverhältnis stabil halten
Das Layout sollte möglichst vor dem Download wissen, wie viel Platz das Bild braucht.
HTML-Abmessungen:
<img width="1200" height="800" ...>
oder CSS aspect-ratio helfen, Platz zu reservieren.
Das reduziert Layoutverschiebungen und kann CLS verbessern.
Die wichtigsten Rasterformate unterscheiden sich deutlich.
Der Leitfaden PNG, JPEG, WebP oder AVIF: Welches Format wählen? behandelt die Details.
Kurz:
- Foto → WebP/AVIF/JPEG;
- Screenshot → PNG oder verlustfreies WebP;
- Logo/Icon → SVG;
- transparente Rastergrafik → PNG/WebP/AVIF.
Schritt 5: Kompression abstimmen
Selbst das passende Format kann schlecht eingestellt sein.
Der Artikel Bild komprimieren ohne sichtbaren Qualitätsverlust zeigt, wie Qualitätsstufen und Motiv gemeinsam bewertet werden.
Wichtig ist, nicht von einer bereits stark komprimierten Zwischenkopie aus weiterzukodieren.
Schritt 6: Mehrere Breiten bereitstellen
Responsive Layouts benötigen unterschiedliche Größen.
Mit srcset und sizes kann der Browser eine geeignete Quelle auswählen.
Das verhindert, dass kleine Geräte immer die größte Datei laden.
Schritt 7: LCP-Bild erkennen
Das größte sichtbare Element im oberen Bereich ist häufig ein Bild und kann den Largest Contentful Paint beeinflussen.
Ein wichtiges Hero-Bild sollte:
- früh im HTML sichtbar sein,
- nicht unnötig lazy geladen werden,
- in passender Größe vorliegen,
- effizient komprimiert sein,
- gegebenenfalls hohe Fetch-Priorität erhalten.
Schritt 8: Nichtkritische Bilder verzögert laden
Bilder weit unterhalb des sichtbaren Bereichs müssen nicht sofort geladen werden.
loading="lazy" kann Netzwerk und Dekodierung entlasten.
Es sollte jedoch nicht reflexartig auf jedes Bild gesetzt werden.
Schritt 9: Dekodierung berücksichtigen
Eine kleine Datei kann nach dem Dekodieren trotzdem viele Megabyte Arbeitsspeicher benötigen.
Ein 4.000 × 3.000 RGBA-Bild benötigt als rohe Pixel grob:
4.000 × 3.000 × 4 ≈ 48 MB.
Deshalb sind unnötige Abmessungen nicht nur ein Netzwerkproblem.
EXIF- und andere Metadaten können unnötige Bytes und sensible Informationen enthalten.
Mit dem Bild-Metadatenleser lässt sich prüfen, was enthalten ist. Der Metadaten-Entferner kann Dateien lokal neu kodieren.
Mehr dazu: Bildmetadaten und Datenschutz.
Hero-Bilder
Hero-Bilder sind visuell dominant und häufig LCP-Kandidaten.
Empfehlungen:
- keinen unnötig großen Crop;
- mehrere Breiten;
- modernes Format;
- angemessene Qualität;
- keine Ladeverzögerung;
- stabile Abmessungen;
- reale LCP-Messung.
Kartenbilder und Listen
Bei Karten sind kleine, konsistente Varianten besonders wichtig. Eine große Originaldatei pro Karte kann bei langen Listen enorme Datenmengen erzeugen.
Ein dediziertes Thumbnail kann sinnvoller sein als die automatische Skalierung des Originals.
Hintergrundbilder
CSS-Hintergründe werden anders priorisiert als normale <img>-Elemente und sind semantisch nicht für inhaltlich wichtige Bilder gedacht.
Ein LCP-relevantes Bild sollte daher nicht ohne guten Grund als schwer entdeckbarer CSS-Hintergrund implementiert werden.
Mit <picture> können unterschiedliche Formate oder Crops angeboten werden.
Beispiel:
<picture>
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="">
</picture>
In Kombination mit Media Queries können auch andere Ausschnitte gewählt werden.
Preload vorsichtig einsetzen
Ein wichtiges Bild kann vorgeladen werden. Zu viele Preloads konkurrieren jedoch mit CSS, Fonts und JavaScript.
Preload ist ein Priorisierungstool, kein allgemeiner Performance-Schalter.
fetchpriority
Moderne Browser unterstützen fetchpriority für bestimmte Ressourcen. Ein LCP-Bild kann beispielsweise höhere Priorität erhalten.
Auch hier gilt: nur gezielt einsetzen. Wenn alles „high“ ist, verliert Priorisierung ihren Sinn.
Caching
Stabile Bild-URLs mit langfristigem Cache reduzieren wiederholte Downloads.
Bei Änderungen sollten versionierte oder content-hashed URLs verwendet werden, damit neue Dateien zuverlässig ausgeliefert werden.
Ein Bild-CDN kann Größen und Formate dynamisch erzeugen. Das ist hilfreich bei großen Plattformen.
Bethemesh verfolgt bei seinen lokalen Werkzeugen dagegen bewusst einen browserbasierten Ansatz. Für die eigene Website-Auslieferung ist die Architekturfrage getrennt davon zu betrachten.
SEO und Bilder
Technische Bildoptimierung kann Suchmaschinen helfen, weil Seiten schneller und stabiler werden. Sie ersetzt aber nicht:
- sinnvolle Dateinamen,
- Alt-Texte,
- passenden Kontext,
- semantische Einbindung.
Die technische SEO-Checkliste kann als Ergänzung dienen.
Alt-Texte
Ein alt beschreibt die Funktion oder Information eines Bildes im Kontext.
Er sollte nicht mit Keywords gefüllt werden. Dekorative Bilder können einen leeren Alt-Text benötigen.
Performance und Accessibility sind unterschiedliche Anforderungen, die beide erfüllt werden sollten.
CLS vermeiden
Wenn Bildabmessungen unbekannt sind, kann Inhalt nach dem Laden springen.
width und height im HTML oder CSS aspect-ratio geben dem Browser früh genug Informationen, um Platz zu reservieren.
LCP nicht nur lokal testen
Eine schnelle Entwicklungsmaschine mit Glasfaser kann Probleme verstecken.
Teste:
- mobile CPU,
- gedrosseltes Netzwerk,
- echten Produktionsserver,
- Cache leer und warm,
- verschiedene Viewports.
Field Data sind langfristig wertvoller als ein einzelner Lab-Test.
Dateigröße ist nicht die einzige Kennzahl
Ein 50-KB-Bild kann schlecht sein, wenn es:
- zu spät geladen wird,
- Layout verschiebt,
- unscharf ist,
- unnötig hoch priorisiert wird.
Ein 150-KB-Hero kann dagegen sinnvoll sein, wenn es visuell wichtig und gut priorisiert ist.
Ein kompletter Workflow
- Bildfunktion festlegen.
- Crop bestimmen.
- maximale Anzeigegrößen messen.
- passende Pixelbreiten erzeugen.
- Format pro Inhalt wählen.
- Kompression testen.
- Metadaten prüfen.
srcset/sizes konfigurieren.- width/height setzen.
- LCP-Bild priorisieren.
- nichtkritische Bilder lazy laden.
- Browser-Messungen durchführen.
Häufige Anti-Patterns
Ein einziges 4K-Bild für alles
Verschwendet Netzwerk und Dekodierung.
AVIF allein löst keine falschen Abmessungen.
Alle Bilder lazy laden
Kann LCP verschlechtern.
Keine intrinsischen Maße
Kann CLS erzeugen.
Nur Lighthouse-Score optimieren
Der Score ist ein Signal. Nutzererlebnis und reale Felddaten sind wichtiger.
Fazit
Web-Image-Optimierung ist ein System. Dimensionen, Format, Kompression, responsive Auswahl, Priorität und Layoutstabilität müssen zusammenpassen.
Wer nur einen Qualitätsregler reduziert, lässt oft die größten Einsparungen liegen. Wer dagegen die gesamte Pipeline optimiert, kann Bilder deutlich effizienter ausliefern, ohne sichtbare Qualität zu opfern.
