Bilder sind mit über 50 Prozent des durchschnittlichen Seitengewichts die häufigste Ursache für langsame Websites und schlechte Core Web Vitals. WebP reduziert die Dateigröße um 25 bis 35 Prozent gegenüber JPEG, AVIF sogar um 40 bis 55 Prozent. In Kombination mit responsiven srcset-Attributen und gezieltem Lazy Loading lässt sich die lange Ladezeiten oft halbieren und der PageSpeed-Scores -Score deutlich steigern – ohne Inhalte zu entfernen.
Warum Bilder die häufigste Performance-Schwachstelle sind
Laut HTTP Archive (2025) laden Websites im Median über 900 KB an Bilddaten – auf mobilen Verbindungen ein erheblicher Flaschenhals. Bilder, die unkomprimiert oder im falschen Format ausgeliefert werden, wirken sich direkt auf den Largest Contentful Paint (LCP) aus: Der LCP misst, wann das größte sichtbare Element geladen ist, und ist ein zentraler Core-Web-Vitals-Wert für Google-Rankings.
- Nicht komprimierte JPEGs und PNGs: Häufig 5–20× größer als nötig, direkt im CMS hochgeladen
- Falsches Format: PNG für Fotos statt JPEG/WebP kostet unnötig Bytes
- Keine Größenanpassung: Ein 3000 px breites Originalbild in einem 400 px Container geladen
- Kein Lazy Loading: Alle Bilder werden beim Seitenaufruf geladen, auch die weit unten auf der Seite
- Kein CDN: Bilder werden vom Ursprungsserver ausgeliefert statt von einem Edge-Node in Nutzernähe
WebP und AVIF: Moderne Bildformate im Vergleich
WebP und AVIF sind die zwei wichtigsten modernen Bildformate für das Web. Beide bieten gegenüber JPEG und PNG deutlich kleinere Dateigrößen bei gleicher oder besserer visueller Qualität.
- WebP: 25–35 % kleiner als JPEG bei vergleichbarer Qualität, unterstützt Transparenz (ersetzt PNG), Browser-Support seit 2020 universal
- AVIF: 40–55 % kleiner als JPEG, noch bessere Qualität bei niedrigen Bitraten, Browser-Support seit 2023 breit (Chrome 85+, Firefox 93+, Safari 16+)
- JPEG XL: Vielversprechend, aber Browser-Support 2026 noch lückenhaft – noch nicht produktionsreif
- Fallback-Strategie: Mit <picture> und <source type> WebP/AVIF anbieten, JPEG als Fallback für ältere Browser
- Konvertierung: Tools wie Squoosh, Sharp (Node.js), cwebp oder Bildoptimierungs-Pipelines im Build-Prozess
In der Praxis empfiehlt sich für die meisten Projekte WebP als Standard-Exportformat mit JPEG-Fallback. AVIF lohnt sich zusätzlich, wenn eine automatisierte Konvertierungspipeline vorhanden ist. Ein CDN mit automatischer Bildoptimierung mit automatischer Bildoptimierung (Cloudflare Images, Imgix) kann diesen Schritt vollständig automatisieren.
Responsive Images: srcset und sizes korrekt einsetzen
Ein häufiger Fehler: Die Website liefert dasselbe große Bild auf dem Desktop wie auf einem 375 px breiten Smartphone. Mit dem srcset-Attribut und sizes kann der Browser selbst entscheiden, welche Bildgröße er lädt.
- Faustregel für srcset-Varianten: 400w, 800w, 1200w, 1600w – deckt mobile bis Desktop ab
- sizes-Attribut: Entspricht der tatsächlichen CSS-Breite des Bildes im Layout (z. B. '(max-width: 768px) 100vw, 50vw')
- Retina-Displays: 2× Variante für Schärfe auf HiDPI-Screens, aber Dateigrößen-Tradeoff beachten
- Art Direction mit <picture>: Unterschiedliche Bildausschnitte für mobile vs. Desktop via media-Attribut
- Angular NgOptimizedImage: Automatisches srcset-Generieren, Aspect-Ratio-Reservierung und fetchpriority-Steuerung eingebaut
Lazy Loading: Welche Bilder davon profitieren
Lazy Loading für Bilder bedeutet: Bilder werden erst geladen, wenn sie in den sichtbaren Bereich des Browsers scrollen. Das reduziert die initiale Datenmenge erheblich – besonders auf bildreichen Seiten. Für das initiale Rendering ist entscheidend, dass Bilder above-the-fold explizit vom Lazy Loading ausgenommen werden.
- Native Lazy Loading: loading='lazy' Attribut am <img>-Tag – kein JavaScript nötig, alle modernen Browser unterstützen es
- LCP-Bild NICHT lazy laden: Das Hauptbild im sichtbaren Bereich (Hero, Produktbild) muss loading='eager' oder fetchpriority='high' bekommen
- Angular NgOptimizedImage: priority-Prop für LCP-Bilder setzen – sie erhalten automatisch fetchpriority='high' und preload-Link
- Platzhalter-Dimensionen: width und height immer angeben, damit der Browser Platz reserviert und kein Layout Shift entsteht
- Intersection Observer API: Für komplexere Lazy-Loading-Szenarien (Hintergrundbilder, iFrames) als JavaScript-Fallback
In Angular-Projekten ist NgOptimizedImage (seit Angular 15 stabil) der empfohlene Weg für alle Bilder. Sie erzwingt Breite/Höhe-Angaben, generiert srcset-Varianten und integriert sich sauber in das Caching-Verhalten -Verhalten von CDNs und Service Workern.
Kurz zusammengefasst
- WebP als Standard: 25–35 % kleiner als JPEG, universeller Browser-Support – heute kein Grund mehr für JPEG/PNG als primäres Format
- AVIF als Bonus: Noch kleiner, wenn eine Konvertierungspipeline oder ein CDN die Automatisierung übernimmt
- srcset + sizes immer setzen: Browser wählt die passende Bildgröße selbst
- LCP-Bild nie lazy laden: fetchpriority='high' und kein loading='lazy' für das wichtigste Bild im sichtbaren Bereich
- Alle anderen Bilder: loading='lazy' standardmäßig aktivieren
- Dimensionen immer angeben: width + height verhindern Cumulative Layout Shifts (CLS)
- Angular: NgOptimizedImage nutzen – übernimmt srcset, LCP-Warnung, fetchpriority automatisch
