Warum Bildoptimierung die wichtigste Performance-Maßnahme ist
Laut HTTP Archive machen Bilder im Median über 50% des Gesamtgewichts einer Webseite aus. Auf mobilen Verbindungen bedeutet das: Ein 3-MB-Hero-Image kann die Ladezeit um mehrere Sekunden verlängern und den Largest Contentful Paint (LCP) in den roten Bereich treiben.
Google berücksichtigt Core Web Vitals seit 2021 im Ranking. LCP ist direkt von der Bildgröße abhängig, wenn das größte sichtbare Element ein Bild ist — was auf den meisten Seiten der Fall ist. Eine Reduktion der Bildgröße um 50% kann den LCP-Wert um 1-2 Sekunden verbessern.
Das Gute: Bildoptimierung ist eine der einfachsten Performance-Verbesserungen. Du brauchst keinen Code umzuschreiben, keine Architektur zu ändern. Es geht um das richtige Format, die richtige Größe und die richtige Ladestrategie. Die Werkzeuge dafür sind ausgereift und oft automatisierbar.
Bildformate im Vergleich: JPEG, PNG, WebP, AVIF
JPEG bleibt der Standard für Fotos. Es verwendet verlustbehaftete Kompression und bietet bei Qualitätsstufe 75-85 ein gutes Verhältnis von Dateigröße zu visueller Qualität. Progressive JPEG lädt ein unscharfes Vorschaubild zuerst und schärft dann schrittweise nach — subjektiv empfinden Nutzer das als schneller.
PNG ist verlustfrei und unterstützt Transparenz (Alpha-Kanal). Verwende es für Screenshots, Diagramme und Grafiken mit scharfen Kanten oder Text. Für Fotos ist PNG fast immer zu groß. PNG-8 (256 Farben) kann für einfache Icons eine Alternative zu SVG sein, aber SVG ist bei Skalierbarkeit überlegen.
WebP bietet sowohl verlustbehaftete als auch verlustfreie Kompression und ist typischerweise 25-35% kleiner als JPEG bei vergleichbarer Qualität. Browser-Support liegt 2026 bei über 97%. Es gibt kaum noch einen Grund, WebP nicht als Standard für Fotos im Web zu verwenden.
AVIF ist das neueste Format, basierend auf dem AV1-Videocodec. Es schlägt WebP bei verlustbehafteter Kompression um weitere 20-30%, besonders bei niedrigen Bitraten. Der Nachteil: Encoding ist deutlich langsamer als WebP (5-10x), und der Browser-Support liegt bei etwa 92%. Für statische Assets, die du einmal encodierst, ist AVIF die beste Wahl.
<!-- Moderner Bild-Tag mit Format-Fallback -->
<picture>
<!-- AVIF für Browser die es unterstützen -->
<source srcset="hero.avif" type="image/avif">
<!-- WebP als Fallback -->
<source srcset="hero.webp" type="image/webp">
<!-- JPEG für den Rest -->
<img src="hero.jpg" alt="Produktfoto" width="1200" height="800"
loading="lazy" decoding="async">
</picture>Kompression richtig einstellen
Die ideale Qualitätsstufe hängt vom Inhalt ab. Für die meisten Fotos liefert WebP bei Qualität 75-80 visuell identische Ergebnisse wie das Original, bei einem Bruchteil der Dateigröße. AVIF kann oft auf Qualität 50-60 eingestellt werden und sieht trotzdem gut aus — die Skala ist nicht linear vergleichbar.
Verlustfreie Optimierung entfernt unnötige Metadaten (EXIF, ICC-Profile, Thumbnails) ohne die Pixeldaten zu verändern. Tools wie oxipng für PNG oder jpegtran für JPEG machen das automatisch. Das spart typischerweise 10-20% ohne jeden sichtbaren Unterschied.
Für UI-Elemente und Icons solltest du SVG verwenden, nicht rasterbasierte Formate. SVGs sind vektorbasiert, skalieren verlustfrei auf jede Größe und lassen sich mit SVGO um 30-60% komprimieren. Inline-SVGs sparen zusätzlich einen HTTP-Request.
Ein häufiger Fehler: Bilder in der vollen Auflösung der Kamera (4000x3000px) hochladen und per CSS verkleinern. Der Browser lädt trotzdem die volle Datei. Skaliere Bilder auf die tatsächlich benötigte Anzeigegröße — für einen Hero-Banner reichen meist 1600px Breite, für Thumbnails 400px.
# WebP-Konvertierung mit cwebp (verlustbehaftet, Qualität 80)
cwebp -q 80 input.jpg -o output.webp
# AVIF-Konvertierung mit avifenc (Qualität 60, Geschwindigkeit 4)
avifenc --min 30 --max 60 --speed 4 input.png output.avif
# PNG verlustfrei optimieren mit oxipng
oxipng -o 4 --strip safe *.png
# SVG optimieren mit SVGO
svgo --multipass input.svg -o output.svgResponsive Images: srcset und sizes
Das srcset-Attribut liefert dem Browser mehrere Bildvarianten in verschiedenen Auflösungen. Der Browser wählt die passende Version basierend auf Viewport-Breite, Pixeldichte und Netzwerkbedingungen. Das spart auf Mobilgeräten erheblich Bandbreite.
Das sizes-Attribut sagt dem Browser, wie breit das Bild im Layout sein wird — bevor CSS geladen ist. Ohne sizes nimmt der Browser die volle Viewport-Breite an und lädt möglicherweise ein zu großes Bild. Definiere sizes immer, wenn du srcset mit Breitenangaben (w) verwendest.
Für Art Direction — wenn du auf verschiedenen Bildschirmgrößen komplett unterschiedliche Bildausschnitte zeigen willst — verwende <picture> mit <source media="...">. Typischer Anwendungsfall: Ein breites Landschaftsbild auf Desktop und ein quadratischer Ausschnitt auf Mobile.
Automatisierung ist hier entscheidend. Niemand erstellt manuell 5 Größenvarianten in 3 Formaten für jedes Bild. Build-Tools wie sharp (Node.js), responsive-loader (Webpack) oder das Image-Modul in Next.js generieren Varianten automatisch. Unser Image Resizer hilft dir, schnell einzelne Bilder in den gewünschten Dimensionen zu erstellen.
<!-- Responsive Bild mit srcset und sizes -->
<img
srcset="
produkt-400w.webp 400w,
produkt-800w.webp 800w,
produkt-1200w.webp 1200w,
produkt-1600w.webp 1600w
"
sizes="(max-width: 600px) 100vw,
(max-width: 1200px) 50vw,
800px"
src="produkt-800w.webp"
alt="Produktansicht von vorne"
width="800" height="600"
loading="lazy"
>Lazy Loading und Ladepriorisierung
loading="lazy" ist seit 2020 nativ in allen Browsern verfügbar. Es verzögert das Laden von Bildern, die sich außerhalb des sichtbaren Bereichs befinden (Below the Fold). Wichtig: Verwende lazy loading NICHT für das LCP-Bild — das muss sofort laden.
Für das wichtigste Bild der Seite (Hero-Image, Produktfoto Above the Fold) verwende fetchpriority="high" und ein <link rel="preload"> im <head>. Das signalisiert dem Browser, dieses Bild priorisiert herunterzuladen, noch bevor der Parser den <img>-Tag erreicht.
decoding="async" erlaubt dem Browser, das Bild im Hintergrund zu dekodieren, ohne den Main Thread zu blockieren. Es gibt keinen sichtbaren Nachteil — verwende es bei allen Bildern, die nicht sofort sichtbar sein müssen. Zusammen mit lazy loading ist das die Standard-Kombination für Below-the-Fold-Bilder.
Placeholder-Strategien verbessern die wahrgenommene Ladezeit: Dominant Color (ein farbiger Hintergrund in der Bildgröße), LQIP (Low Quality Image Placeholder, ein stark komprimiertes 20px-Vorschaubild) oder BlurHash (eine kompakte Hash-Darstellung des Bildes). Next.js Image-Komponente und Plaiceholder-Library bieten das out of the box.
<!-- LCP-Bild: Hohe Priorität, kein Lazy Loading -->
<link rel="preload" as="image" href="hero.avif" type="image/avif">
<img src="hero.avif" alt="Hero-Banner"
fetchpriority="high" decoding="async"
width="1600" height="900">
<!-- Below-the-Fold-Bild: Lazy Loading + async decoding -->
<img src="galerie-3.webp" alt="Detailansicht"
loading="lazy" decoding="async"
width="800" height="600">Build-Pipeline: Automatische Bildoptimierung
Sharp ist die schnellste Node.js-Bibliothek für Bildverarbeitung (basiert auf libvips). Es kann Resize, Format-Konvertierung und Qualitätsanpassung in einer Pipeline erledigen. Für Build-Systeme ist es die erste Wahl, weil es 10-50x schneller als ImageMagick ist.
In Next.js übernimmt die Image-Komponente die Optimierung automatisch: Resize, Format-Erkennung (AVIF/WebP basierend auf Accept-Header) und Lazy Loading. Du musst nur width und height angeben. Für statische Exports konfiguriere einen externen Image-Loader.
Für statische Sites (Astro, Hugo, Eleventy) gibt es Plugins die zur Build-Zeit alle Bilder optimieren und responsive Varianten generieren. Das Ergebnis ist ein Cache-freundlicher Output mit Content-Hash im Dateinamen, der via CDN ausgeliefert wird.
CI-Integration: Füge einen Bildoptimierungs-Check in deine Pipeline ein. Tools wie imagemin-lint-staged prüfen bei jedem Commit, ob neue Bilder optimiert sind. Das verhindert, dass ein 5-MB-PNG versehentlich in Production landet.
// Bildoptimierung mit Sharp in einer Build-Pipeline
import sharp from 'sharp';
// AVIF und WebP aus dem Originalbild generieren
async function optimizeImage(inputPath: string) {
const image = sharp(inputPath);
// WebP-Variante (Qualität 80)
await image
.resize(1600, null, { withoutEnlargement: true })
.webp({ quality: 80 })
.toFile(inputPath.replace(/\.[^.]+$/, '.webp'));
// AVIF-Variante (Qualität 55)
await image
.resize(1600, null, { withoutEnlargement: true })
.avif({ quality: 55 })
.toFile(inputPath.replace(/\.[^.]+$/, '.avif'));
}Core Web Vitals und Bildmetriken messen
Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Viewport fertig gerendert ist. Zielwert: unter 2,5 Sekunden. Wenn dein LCP-Element ein Bild ist, hängt der Wert direkt von Download-Zeit plus Dekodierungszeit ab.
Cumulative Layout Shift (CLS) leidet unter Bildern ohne explizite width/height-Attribute. Der Browser kennt die Dimensionen erst nach dem Laden und verschiebt dann den umliegenden Inhalt. Lösung: Immer width und height im HTML angeben oder CSS aspect-ratio verwenden.
Tools zum Messen: Lighthouse in Chrome DevTools für Lab-Daten, PageSpeed Insights für Feld-Daten aus dem Chrome UX Report, und WebPageTest für detaillierte Wasserfalldiagramme. Die Feld-Daten sind wichtiger als Lab-Daten, weil sie echte Nutzer auf echten Geräten abbilden.
Ein oft übersehener Faktor: Bildkompression allein reicht nicht, wenn das CDN falsch konfiguriert ist. Prüfe die Cache-Header (Cache-Control: public, max-age=31536000, immutable für versionierte Assets), aktiviere Brotli-Kompression auf dem Server und stelle sicher, dass dein CDN den Accept-Header respektiert für Content Negotiation.
Checkliste: Bilder für Production optimieren
Format: Verwende AVIF als primäres Format mit WebP-Fallback und JPEG als letzten Fallback. Für Grafiken und Icons nutze SVG. Für animierte Inhalte prüfe ob ein kurzes Video (MP4/WebM) nicht effizienter ist als ein animiertes GIF — das ist fast immer der Fall, oft um Faktor 10 kleiner.
Dimensionen: Erstelle Varianten für gängige Breakpoints (400w, 800w, 1200w, 1600w). Liefere nie ein Bild aus, das breiter als der Viewport ist. Berücksichtige Retina-Displays: Ein Bild das 400px breit angezeigt wird, braucht auf einem 2x-Display eine 800px-Quelle.
Laden: LCP-Bild mit fetchpriority="high" und Preload. Alles andere mit loading="lazy" und decoding="async". Gib immer width und height an um Layout Shifts zu vermeiden. Verwende <picture> mit mehreren <source>-Elementen für Format-Fallbacks.
Tooling: Unser Image Compressor hilft dir, einzelne Bilder schnell in WebP oder AVIF zu konvertieren und die optimale Qualitätsstufe zu finden. Der Image Resizer erstellt Varianten in verschiedenen Dimensionen. Für automatisierte Pipelines kombiniere sharp mit deinem Build-System.