Adaptive Image Loading: AVIF, lazy & responsive Bilder 2026

Bilder sind in modernen Online-Shops der größte Bytes-Block – und gleichzeitig fast immer das LCP-Element. Mit AVIF sparen Sie gegenüber JPEG rund 50 % Bytes bei vergleichbarer visueller Qualität (web.dev). Doch das Format allein reicht nicht: Bei Seiten mit gutem LCP liegt die Bildverzögerung im 75. Perzentil im Median bei 350 ms, bei Seiten mit Nachbesserungsbedarf schon bei 720 ms (Web Almanac 2024) – und genau dort schlägt falsch gesetztes Lazy-Loading zu. In diesem technischen Leitfaden bauen wir eine adaptive Bild-Pipeline aus picture, srcset, loading, fetchpriority, Vary-Headern und Edge-Resizing – sauber genug für Shopware-Shops mit hohem Lighthouse-Score und ohne Verlust visueller Qualität.

Format-Vergleich: JPEG vs WebP vs AVIF

Die drei dominanten Web-Formate unterscheiden sich vor allem in Kompressionseffizienz und Browser-Support. Im Median des Web-Bestands liegt JPEG bei 2,0 Bits-per-Pixel, AVIF bei 1,4 und WebP bei 1,3 (Web Almanac 2024) – je niedriger der Wert, desto stärker die Kompression. Gegenüber JPEG sind bei AVIF je nach Inhalt, Encoder und Qualitätsziel über 50 % Ersparnis gemessen worden (web.dev). Bei aller Effizienz hat AVIF allerdings einen Haken: Die Encoding-Zeiten liegen deutlich über denen von JPEG und WebP. Eine reine On-Demand-Konvertierung ohne Caching ist daher selten sinnvoll.

Laut Web Almanac 2024 stieg der AVIF-Anteil zwischen 2022 und 2024 um 386 %, machte Ende 2024 aber erst 1,0 % aller Bilder im Web aus, während WebP bei 12 % lag und JPEG von 40 % auf 32 % gefallen ist (Web Almanac 2024). Wer heute auf AVIF setzt, ist also kein Nachzügler. Die Median-Bildgröße liegt im 50. Perzentil bei 12 KB, im 75. bei 56 KB und im 90. bei 177 KB (Web Almanac 2024) – vor allem die oberen Perzentile profitieren von AVIF.

Picture-Element und srcset richtig einsetzen

Das picture-Element ist der zentrale Baustein adaptiven Bild-Loadings: Browser wählen automatisch das beste unterstützte Format. Wichtig ist die Reihenfolge der source-Tags – AVIF zuerst, dann WebP, dann JPEG als Fallback im img-Tag. Mit srcset und sizes liefert der Browser zusätzlich die passende Auflösung für die jeweilige Geräteklasse. Damit landen auf Smartphones keine überdimensionierten Desktop-Varianten mehr; zusammen mit der Format-Aushandlung sinkt die Bild-Payload im mobilen Fall erfahrungsgemäß deutlich.

<picture>
  <source
    type="image/avif"
    srcset="/img/hero-400.avif 400w,
            /img/hero-800.avif 800w,
            /img/hero-1200.avif 1200w,
            /img/hero-1600.avif 1600w"
    sizes="(max-width: 768px) 100vw, 50vw">
  <source
    type="image/webp"
    srcset="/img/hero-400.webp 400w,
            /img/hero-800.webp 800w,
            /img/hero-1200.webp 1200w,
            /img/hero-1600.webp 1600w"
    sizes="(max-width: 768px) 100vw, 50vw">
  <img
    src="/img/hero-800.jpg"
    srcset="/img/hero-400.jpg 400w,
            /img/hero-800.jpg 800w,
            /img/hero-1200.jpg 1200w,
            /img/hero-1600.jpg 1600w"
    sizes="(max-width: 768px) 100vw, 50vw"
    width="1600" height="900"
    alt="Produktbild Beispiel"
    loading="eager"
    fetchpriority="high"
    decoding="async">
</picture>

Drei Details machen den Unterschied: Erstens immer width und height setzen – sonst springt das Layout und CLS verschlechtert sich. Zweitens sizes realistisch beschreiben, sonst lädt der Browser zu große oder zu kleine Varianten. Drittens JPEG-Fallback nicht weglassen, auch wenn AVIF/WebP fast überall funktionieren – manche Bot-User-Agents und alte In-App-Browser kennen die modernen Formate nicht.

Lazy-Loading: Wann ja, wann niemals

Native loading="lazy" wird seit Chrome 77 (09/2019), Firefox 75 und Safari 15.4 unterstützt – die weltweite Unterstützung liegt bei 95,82 % (caniuse). Die Versuchung ist groß, einfach jedes Bild zu lazy-laden, doch genau das ist der häufigste LCP-Killer im Shopware-Frontend. Laut Web Almanac 2024 lazy-laden 9,5 % der mobilen Seiten ihr LCP-Bild nativ, weitere 6,7 % über ein eigenes Verfahren – zusammen 16 % (Web Almanac 2024). Was das kostet, zeigt die Aufschlüsselung des LCP: Bei gutem LCP liegt die Bildverzögerung im Median bei 350 ms, bei Nachbesserungsbedarf bereits bei 720 ms (Web Almanac 2024).

Ein robustes Muster: erste 3–6 Bilder eager, alles darunter lazy. Bei Karussells nur den aktiven Slide eager laden, alle weiteren Slides lazy. Bei Lazy-Loading-Bibliotheken auf JavaScript-Basis lohnt der Umstieg auf das native Attribut – das ist nicht nur einfacher, sondern auch zuverlässiger und ohne Layout-Flackern.

fetchpriority und Preload für LCP-Hero

fetchpriority="high" signalisiert dem Browser, ein Bild bevorzugt zu laden – noch bevor andere Subressourcen wie nicht-kritisches CSS oder JS in der Queue stehen. In einem Test des Chrome-Teams mit Google Flights sank das LCP von 2,6 s auf 1,9 s (web.dev). Die weltweite Unterstützung des Attributs liegt bei 93,74 % (caniuse); Firefox zog im Oktober 2024 nach.

<!-- Im <head>: Preload für AVIF-Variante des LCP-Bilds -->
<link
  rel="preload"
  as="image"
  href="/img/hero-1200.avif"
  imagesrcset="/img/hero-800.avif 800w,
               /img/hero-1200.avif 1200w,
               /img/hero-1600.avif 1600w"
  imagesizes="(max-width: 768px) 100vw, 50vw"
  type="image/avif"
  fetchpriority="high">

<!-- Im <body>: das Bild selbst -->
<picture>
  <source type="image/avif" srcset="..." sizes="...">
  <img src="/img/hero-fallback.jpg"
       fetchpriority="high"
       loading="eager"
       decoding="async"
       width="1600" height="900"
       alt="Hero-Bild Produkt">
</picture>

Wichtig: maximal ein Bild pro Seite mit fetchpriority="high" – sonst verpufft der Effekt, weil der Browser die Priorität nicht mehr eindeutig zuordnen kann. Auf Listing-Seiten ist das in der Regel das erste Produktbild oben links, auf Produktdetailseiten das große Hero-Bild der Galerie. Ein guter Test: Im Chrome-DevTools-Network-Panel sollte das LCP-Bild mit Priorität „High“ und unter den ersten geladenen Ressourcen erscheinen.

Art-Direction mit picture-source-media

Während srcset denselben Bildausschnitt in unterschiedlichen Auflösungen liefert, erlaubt das media-Attribut auf source echte Art-Direction: unterschiedliche Bildausschnitte oder sogar Motive je Viewport. Klassisches Beispiel: Hochformatiger Hero auf Mobile, breitformatiger auf Desktop. Das spart auf Mobile zusätzlich Bytes, weil der unwichtige Hintergrund weggeschnitten wird, statt nur skaliert.

<picture>
  <!-- Mobile: 4:5 Hochformat, fokussiert auf Produkt -->
  <source
    media="(max-width: 640px)"
    type="image/avif"
    srcset="/img/hero-mobile-400.avif 400w,
            /img/hero-mobile-800.avif 800w">

  <!-- Tablet: 1:1 Quadrat -->
  <source
    media="(max-width: 1024px)"
    type="image/avif"
    srcset="/img/hero-square-800.avif 800w,
            /img/hero-square-1200.avif 1200w">

  <!-- Desktop: 16:9 Querformat mit Lifestyle -->
  <source
    type="image/avif"
    srcset="/img/hero-wide-1200.avif 1200w,
            /img/hero-wide-1600.avif 1600w">

  <img src="/img/hero-wide-1200.jpg"
       width="1600" height="900"
       alt="Produkt im Lifestyle-Kontext">
</picture>

Für die Pflege der Crops im Backend bietet sich ein Image-Service mit definierten Crop-Hot-Spots an – Shopware unterstützt das nativ über die Media-Crop-Definition, ähnlich auch Headless-CMS-Setups in Vue/Nuxt-Frontends.

Edge-Resizing und CDN-Format-Negotiation

Wer alle Varianten (AVIF/WebP/JPEG x mehrere Breiten x Crop-Varianten) statisch in die Build-Pipeline schreibt, landet schnell bei Tausenden Dateien pro Produkt. Eleganter ist Edge-Resizing: Das CDN konvertiert und skaliert on-demand, abhängig von URL-Parametern und dem Accept-Header des Browsers. So entstehen Varianten nur für tatsächlich angefragte Breiten – und die Zahl der Pixel, die ein Gerät lädt, ohne sie je anzuzeigen, sinkt entsprechend.

In der Praxis ist eine Hybrid-Strategie oft am robustesten: kritische LCP-Bilder als statische AVIF/WebP-Varianten ausliefern, alle übrigen Produktbilder über Edge-Resizing on-demand. Das Hosting für solche Setups sollte HTTP/2 oder HTTP/3, Brotli und gut konfiguriertes Edge-Caching unterstützen – mehr dazu in unseren Hosting-Lösungen und der Cloud-Beratung.

Vary-Header und korrekte Caching-Strategie

Wer Bilder per Accept-Header in unterschiedliche Formate ausliefert, MUSS das per Vary: Accept an alle Caches signalisieren. Sonst liefert ein CDN das einmal gecachte AVIF-Bild auch an Browser aus, die das Format nicht verstehen – Ergebnis sind kaputte Produktbilder. Liefert die Pipeline zusätzlich nach Save-Data aus, gehört auch dieser Kopf in die Vary-Liste: Vary: Accept, Save-Data.

# Bilder vom Image-Endpoint korrekt cachen
location ~* ^/media/.+\.(jpg|jpeg|png|webp|avif)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    add_header Vary "Accept, Save-Data, DPR";
    add_header X-Content-Type-Options "nosniff";
    expires 1y;
    access_log off;
}

# Falls Edge-Resizing das Bild on-demand erzeugt:
location /img/ {
    proxy_pass https://image-service.example.com;
    proxy_cache_key "$scheme$request_method$host$request_uri$http_accept";
    proxy_cache_valid 200 30d;
    add_header Vary "Accept";
}

Wichtig: Vary: User-Agent ist in der Regel KEIN guter Ersatz, weil dadurch der Cache fragmentiert wird (jede Browser-Version eigener Eintrag). Accept ist deutlich kompakter und genau dafür gedacht. Bei CDN- und Plesk-Setups muss der Vary-Header in der Cache-Konfiguration ausdrücklich erlaubt sein, sonst entfernt ihn die Zwischenschicht.

Build-Pipeline mit libvips und Sharp

Für die Konvertierung im Build oder im Image-Service gibt es mehrere Open-Source-Optionen. libvips und das Node-Binding Sharp erreichen im Benchmark der Maintainer beim PNG-Durchsatz den 4,5-fachen Wert von ImageMagick und arbeiten dabei mit deutlich geringerem Speicherbedarf (Sharp). Squoosh CLI eignet sich gut für Einzelbilder und Marketing-Hero-Konvertierung. Für Shopware-Setups empfiehlt sich Sharp im Background-Worker oder im CDN-Worker, weil es nativ AVIF-Encoding über libaom kann.

Faustregeln für Encoding-Parameter: AVIF Q=50–60 ist meist visuell ununterscheidbar von Q=80 – alles darüber kostet Bytes ohne sichtbaren Gewinn. WebP Q=75–80 entspricht etwa JPEG Q=85. Effort/CPU-Use auf 4–6 setzen – höhere Werte bringen erfahrungsgemäß kaum noch Ersparnis bei deutlich längerer Encoding-Zeit und sind für On-Demand-Workloads ungeeignet.

Browser-Support 2026: Was muss noch kompatibel sein?

Praxis-Folgerung: AVIF + WebP + JPEG-Fallback im picture-Element deckt nahezu alle relevanten Browser ab. loading="lazy" und decoding="async" können bedenkenlos eingesetzt werden. fetchpriority ist seit Firefox 132 (Oktober 2024) breit verfügbar – wer noch ältere Firefox-Versionen unterstützen will, sollte zusätzlich Resource-Hints (rel="preload") setzen, um die LCP-Wirkung dort zu sichern. Die Angaben zur Browser-Unterstützung stammen aus caniuse.com.

Mess-Setup: LCP, p75, Web Vitals

• CrUX-Daten als Wahrheitsquelle: Real-User-Daten aus dem Chrome User Experience Report – entscheidend für Google-Rankings, nicht Lab-Tests.
• Lab-Tests mit Lighthouse (CI-Integration) zur Regression-Erkennung: typischerweise als GitHub-Action vor jedem Deploy. Mehr dazu in unserem Lighthouse-100-Guide.
• RUM-Tracking mit web-vitals.js oder Open-Source-Alternativen: erfasst LCP, INP, CLS pro Seite und User-Segment.
• LCP-Element-Identifikation via PerformanceObserver – speichert die URL des LCP-Bildes, damit Sie genau wissen, welches Asset Sie optimieren müssen.
• Mobile-First-Messung: 75. Perzentil auf Mobile ist die kritische Größe, denn Google bewertet Mobile-Daten primär (siehe Core Web Vitals Guide).
• Synthetic-Monitoring auf Hauptpfaden (Startseite, Top-Kategorie, Top-Produkt, Checkout-Schritt 1) – täglich zu festen Uhrzeiten.

Roadmap: Vom Standard-JPEG zur AVIF-Pipeline

1. Phase 1 – Audit (Woche 1): Analyse der bestehenden Bild-Auslieferung. Welcher Anteil ist bereits WebP/AVIF? Welche Bilder sind LCP? Welche werden lazy geladen, obwohl sie eager sein müssten? Tools wie Lighthouse, WebPageTest und der Performance-Tab in den DevTools.
2. Phase 2 – Format-Pipeline (Woche 2–3): Build- oder Edge-Pipeline für WebP und AVIF aufsetzen. Einheitliche Quality-Profile definieren (z. B. AVIF Q=55, WebP Q=78). Sharp/libvips in CI integrieren oder Edge-Service konfigurieren.
3. Phase 3 – Markup-Refactoring (Woche 3–4): picture-Elemente, srcset, sizes und width/height flächendeckend einbauen. JPEG-Fallback erhalten. Unit-Tests für korrekte Markup-Generierung in der Theme-Layer.
4. Phase 4 – LCP-Optimierung (Woche 4–5): fetchpriority="high" und <link rel="preload"> für LCP-Bilder. Lazy-Loading-Audit: alle Above-the-fold-Bilder auf eager. Karussell-Logik anpassen.
5. Phase 5 – Caching & Headers (Woche 5): Vary: Accept korrekt setzen, lange Cache-Control max-age mit immutable, CDN-Konfiguration prüfen. Einbindung ins bestehende Edge-Caching.
6. Phase 6 – Monitoring & Iteration (laufend): Web-Vitals-Tracking aktivieren, p75 LCP wöchentlich tracken. Bei Regressionen sofort eingreifen. Ziel: nachhaltig unter 2,5 s LCP auf Mobile p75.