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 laut Cloudinary und Smashing Magazine rund 50 % gegenüber JPEG und 20-30 % gegenüber WebP (Cloudinary/Smashing Magazine). Doch das Format allein reicht nicht: Wer sein LCP-Bild lazy lädt, verliert laut web.dev im 75. Perzentil 720 ms statt 364 ms — und sortiert sich von 79 % "good" auf 52 % "good" runter (Web Almanac 2025/web.dev). 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 Lighthouse-Score nahe 100 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. JPEG liegt laut Web Almanac bei rund 2,0 Bits-per-Pixel, WebP bei 1,3 und AVIF bei 1,4 (Web Almanac 2024). In der Praxis bedeutet das: WebP komprimiert bei sichtbarer Qualität rund 25-34 % besser als JPEG (Cloudinary/ShortPixel), AVIF erreicht -50 % gegenüber JPEG und -20 bis -30 % gegenüber WebP bei vergleichbarer visueller Qualität (Cloudinary/Smashing Magazine/Crystallize). Bei aller Effizienz hat AVIF allerdings einen Haken: Encoding-Zeiten liegen je nach Tool 5-10x höher als bei JPEG/WebP. Eine reine On-Demand-Konvertierung ohne Caching ist daher selten sinnvoll.

Laut Web Almanac 2024 stieg AVIF zwar um +386 % zwischen 2022 und 2024, machte aber Ende 2024 erst rund 1 % aller Bilder im Web aus, während WebP bei 12 % liegt und JPEG von 40 % auf 32 % gefallen ist (Web Almanac 2024). Wer heute auf AVIF setzt, ist also kein Nachzügler, sondern noch in der vorderen Hälfte des Felds — zumal die Median-Bildgröße im 50. Perzentil bei 12 KB liegt, im 75. bei 56 KB und im 90. bei 177 KB (Web Almanac 2024). Vor allem die oberen Perzentile profitieren überproportional 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. Auf Smartphones spart das laut web.dev 70-90 % Bytes gegenüber Desktop-Auslieferung (web.dev). In Kombination mit Format-Negotiation entstehen so realistisch bis zu 75 % weniger Image-Payload auf Mobile.

<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 — Coverage liegt 2026 bei rund 95 % (caniuse). Die Versuchung ist groß, einfach jedes Bild zu lazy-loaden, doch genau das ist der häufigste LCP-Killer im Shopware-Frontend. Laut Web Almanac 2025 lazy-laden 10,4 % der Mobile-Pages ihr LCP-Bild nativ + 5,9 % per JavaScript — also rund jede sechste Seite (Web Almanac 2025). Diese Seiten verlieren im 75. Perzentil 200-500 ms LCP und fallen von 79 % "good" auf 52 % "good" zurück (web.dev).

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. Google Flights senkte damit laut web.dev das LCP von 2,6 s auf 1,9 s (-700 ms), Etsy berichtete von +4 % LCP-Verbesserung, in Lab-Tests zeigten sich teilweise 20-30 % Effekt (web.dev/Chrome DevRel). Der Support reicht über Chrome, Edge, Safari und Firefox (seit Oktober 2024) und liegt damit Anfang 2026 bei nahezu allen relevanten Browsern (MDN).

<!-- 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. Laut Cloudflare und Gumlet sparen solche Pipelines 60-80 % der "wasted bytes" auf Mobile — also Pixel, die der Nutzer nie zu sehen bekommt (Cloudflare/Gumlet).

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. Cloudflare empfiehlt zusätzlich Vary: Accept, Save-Data für Save-Data-aware Pipelines (Cloudflare Blog).

# 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 Cloudflare/Plesk-Setups muss der Vary-Header explizit erlaubt sein, damit er nicht herausgestripped wird — siehe Cloudflare-Doku zu "cacheable Vary".

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 sind laut eigenen Benchmarks der Maintainer 4-5x schneller als ImageMagick und benötigen ungefähr 200 MB statt 3 GB RAM bei großen Bildern (sharp.pixelplumbing.com/Criteo). 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 <2 % Ersparnis bei deutlich längerer Encoding-Zeit, ungeeignet für On-Demand-Workloads.

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. Daten zu Browser-Coverage stammen aus caniuse.com und RUMvision-Auswertungen 2026 (caniuse/RUMvision).

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.