Website
Bilder komprimieren für Website und Web-Performance
Für die eigene Website ist Komprimieren nur die halbe Miete. Die andere Hälfte ist die Frage, in welcher Auflösung, in welchem Format und mit welchen HTML-Attributen das Bild eingebunden wird. Eine sauber optimierte Website spart leicht 50 Prozent Bandbreite und Lighthouse-Punkte.
Empfohlenes Format
WebP für moderne Browser, JPEG-Fallback im picture-Element
Empfohlene Quality
WebP 72-78, JPEG-Fallback Quality 80
Auflösung
srcset-Varianten: 600 / 960 / 1280 / 1920 Pixel breit (Hero), 400 / 800 für Inline
Größen-Limit
Kein hartes Limit, aber unter 200 KB pro Hero-Bild und 50 KB pro Inline-Bild sollte das Ziel sein.
Auto-Recompression der Plattform
Nein, die Webseite liefert die Datei direkt aus dem Origin oder CDN.
Workflow
-
Schritt 1
Master-Datei separat halten
PNG oder JPEG-Quality-95 als Original. Aus dieser Master werden alle Web-Varianten neu generiert.
-
Schritt 2
Pro Bild mehrere Größen erzeugen
Mindestens 2 Varianten (Hero: 1920 + 960, Inline: 800 + 400). Bei trafficstarken Sites mehr Stufen für besseren srcset-Fit.
-
Schritt 3
WebP zusätzlich generieren
Aus derselben Master-Datei eine WebP-Version pro Größe. picture-Element liefert WebP an moderne Browser, JPEG-Fallback an alte.
-
Schritt 4
HTML mit width/height/loading
width und height verhindern Layout-Shift. loading=eager nur für das Hero-Bild im sichtbaren Bereich, loading=lazy für alles unter dem Fold.
Typische Fallen
loading=lazy auf das Hero-Bild
Lazy auf dem Hero verzögert den Largest Contentful Paint. Browser lädt LCP-Bild später als möglich. Hero-Bild auf eager (oder weglassen, Default ist eager).
width und height vergessen
Ohne diese Attribute schiebt der Browser Layout um das Bild herum, sobald es lädt. Cumulative Layout Shift steigt, Lighthouse-Punkte sinken. Beide Attribute sind Pflicht.
Ein 4000-Pixel-Bild auf 800-Pixel-Slot
Browser skaliert herunter, aber die Datei wird trotzdem in voller Größe geladen. Pro Bild durchschnittlich 5x Bandbreite verschwendet. srcset oder vorab herunterskalieren.
Häufige Fragen
- Was ist der größte Hebel für Web-Bild-Performance?
- Die Pixel-Anzahl. Ein 4000x2700-Foto auf 1920x1080 herunterzuskalieren spart 64 Prozent Datei. Erst Größe auf Anzeige-Realität, dann komprimieren.
- Brauche ich AVIF zusätzlich zu WebP?
- Für Hero-Bilder mit viel Traffic lohnt es sich. Für Standard-Inline-Bilder reicht WebP mit JPEG-Fallback. AVIF-Encoding ist deutlich langsamer (Faktor 5 bis 20), für Build-Pipelines beachten.
- Wie viele srcset-Varianten brauche ich?
- Mindestens 2 (klein und groß), idealerweise 4 bis 5 für gute Mobile-Performance. Zu viele Varianten sind aber auch Pipeline-Aufwand und Storage. Web Almanac empfiehlt 4 als guten Trade-off.
- Sollte ich Bilder lazy-loaden?
- Alles unter dem Fold ja. Das Hero-Bild im sichtbaren Bereich nein, sonst verzögert sich der LCP messbar.