Bildoptimierung 2026: AVIF, WebP & Lazy Loading

Bilder bleiben die schwersten Elemente auf den meisten Webseiten. In unseren Projekten bei DigiForge stellen wir regelmäßig fest, dass Bilder einen erheblichen Teil des Gesamtgewichts einer Seite ausmachen. Bis 2026 hat sich die Landschaft gefestigt: AVIF und WebP sind die beiden modernen Formate, auf die man setzen sollte, responsive Bilder via srcset sind Standard, und Lazy Loading ist so verbreitet, dass eine falsche Umsetzung die Leistung sogar verschlechtern kann. Dieser Artikel destilliert unsere praktischen Erfahrungen in einen klaren, meinungsstarken Workflow, den Sie auf jedes Projekt anwenden können.

Das richtige Format wählen: AVIF vs. WebP

Jahrelang war WebP das bevorzugte moderne Format. AVIF kam später und versprach bessere Komprimierung und HDR-Unterstützung, allerdings mit höheren Enkodierungskosten und einer Browserunterstützung, die immer noch nicht universell ist (Safari war der letzte Nachzügler). So sieht die Lage im Jahr 2026 aus:

• AVIF liefert in der Regel kleinere Dateigrößen als WebP bei gleicher wahrgenommener Qualität. Es unterstützt 10-Bit-Farben, HDR, verlustfreies Alpha und sogar Animationen. Die Enkodierung ist deutlich langsamer als bei WebP, was es weniger geeignet für Echtzeitgenerierung macht, aber für statische Assets, die zur Build-Zeit erstellt werden, in Ordnung ist.
• WebP wird von allen modernen Browsern universell unterstützt. Es bietet vorhersagbare Qualität, schnelle Enkodierung und hervorragende Werkzeuge (cwebp, sharp, imagemin). Für inhaltsreiche Seiten, bei denen die Enkodierungsgeschwindigkeit wichtig ist, ist WebP nach wie vor der pragmatische Standard.
• JPEG XL (JXL) zeigte frühes Potenzial, konnte sich aber bei den Browsern nie durchsetzen. Chromium hat sein Flag entfernt, und Safari hat es nie implementiert. Verschwenden Sie keine Zeit damit, bis sich die Lage ändert.

Unsere Empfehlung: AVIF mit einem WebP-Fallback ausliefern. Verwenden Sie <picture>, damit Browser zuerst AVIF, dann WebP und schließlich das ursprüngliche JPEG/PNG auswählen können. Das maximiert die Komprimierung für diejenigen, die sie nutzen können, während niemand ein leeres Bild sieht. Die meisten modernen Browser unterstützen AVIF, daher ist der Fallback zwar wichtig, aber nicht der primäre Pfad.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Responsive Größen: Nicht nur srcset

Das srcset-Attribut mit sizes ist allgemein bekannt, doch viele Implementierungen, die wir prüfen, setzen sizes falsch ein. Der Browser verwendet sizes, um zu entscheiden, welcher srcset-Kandidat heruntergeladen wird – es ist nicht nur ein Vorschlag. Fehlt sizes, wird standardmäßig 100vw angenommen, was dazu führen kann, dass der Browser selbst auf kleinen Bildschirmen das größte Bild auswählt und Bandbreite verschwendet.

Für einfache responsive Bilder, die mit dem Viewport skaliert werden, schreiben Sie:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

Aber hier gibt es Nuancen. sizes sollte die tatsächliche CSS-Breite widerspiegeln, die das Bild an jedem Breakpoint einnimmt, nicht den Viewport-Anteil. Für ein Hero-Bild, das immer volle Breite hat, ist sizes="100vw" korrekt. Für eine Galerie, in der jedes Bild ein Drittel der Zeile ausmacht, verwenden Sie 33vw. Wenn das Bild Padding hat oder sich in einem Container mit einer Maximalbreite befindet, müssen Sie die tatsächliche gerenderte Breite berechnen – manchmal ist die Verwendung von calc() in sizes erforderlich.

Breiten-Deskriptoren vs. Pixeldichte

Verwenden Sie w-Deskriptoren (z. B. 400w) und sizes für flexible Bilder, deren Anzeigegröße sich mit dem Layout ändert. Dichte-Deskriptoren (1x, 2x) eignen sich nur für Bilder mit fester Größe wie Logos oder Symbole, bei denen die genauen physischen Abmessungen bekannt sind. Verwenden Sie für Inhaltsbilder immer w – es gibt dem Browser die wahre Flexibilität, basierend auf Viewport-Breite und Geräte-Pixelverhältnis die beste Variante auszuwählen.

Wenn Sie <picture> für die Formatauswahl verwenden, muss jede <source> ihr eigenes srcset und optional sizes haben. Sie können dasselbe sizes über mehrere Quellen hinweg teilen, wenn das Layout identisch ist, vermeiden Sie jedoch unnötige Duplikate.

Lazy Loading: Nativ, Intersection Observer oder beides?

Natives Lazy Loading (loading="lazy") wird seit 2020 von allen gängigen Browsern unterstützt. Es kommt ohne JavaScript aus, funktioniert mit Bildern und Iframes und ist der einfachste Weg. Allerdings hat es in der Praxis einige Eigenheiten:

• Natives Lazy Loading verzögert das Laden, bis der Browser das Element als nahe am Viewport einstuft. Der Schwellenwert ist browserabhängig – Chrome verwendet einen großzügigen Rand, um früh zu laden; Firefox einen kleineren. Das bedeutet, dass Bilder in Firefox möglicherweise später geladen werden als erwartet.
• In einigen frühen Implementierungen funktioniert es nicht perfekt mit srcset. Ältere Safari-Versionen (vor 16.4) hatten Fehler. Im Jahr 2026 sind diese selten, aber es lohnt sich dennoch, sie zu testen.
• Bei <picture>-Elementen sollte loading="lazy" auf dem <img>-Tag stehen, nicht auf den <source>-Tags.

Wir verwenden einen Hybridansatz: natives Lazy Loading als Basis, plus einen schlanken Intersection Observer (IO) als Polyfill für ältere Browser (obwohl das 2026 nur noch eine Nische ist). Der IO kann auch Einblendanimationen auslösen oder Platzhalter in niedriger Qualität laden. Unsere Implementierung:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Alles zusammenführen: Ein praktischer Workflow

Bei DigiForge befolgen wir diese Pipeline für jedes Projekt, sei es eine statische Website, eine CMS-gesteuerte Website oder eine Web-App:

1. Quellbilder: Designer liefern in hochauflösendem PNG oder TIFF. Wir bewahren Originale in einem _originals-Ordner auf, um sie bei neuen Formaten später erneut komprimieren zu können.
2. Formaterzeugung: Verwenden Sie ein Node.js-Skript mit sharp oder ein Makefile mit ImageMagick, um AVIF, WebP und Fallback-JPEG/PNG in 3–5 Breiten (z. B. 480, 800, 1200, 1920) zu erzeugen. Bei großen Projekten führen wir dies parallel mit Worker-Threads durch, um den Build zu beschleunigen.
3. Qualitätsoptimierung: Führen Sie CI-Prüfungen durch, die die Dateigröße mit einer wahrnehmungsbezogenen Metrik (SSIM oder Butteraugli) vergleichen. Wir blockieren Pull-Requests, wenn das gesamte Bildgewicht einer typischen Seite einen angemessenen Schwellenwert basierend auf dem Inhaltstyp überschreitet.
4. Markup: Erzeugen Sie <picture> mit type-Reihenfolge (AVIF, WebP, Fallback) und <img> mit loading="lazy" (außer erstes Hero). Für responsive Größen generieren wir sizes basierend auf dem tatsächlichen CSS – dies stammt oft aus einer Design-Tokens-Datei, die zwischen Design und Entwicklung geteilt wird.
5. Auslieferung über CDN: Für statische Websites liefern wir vorcodierte Assets über ein CDN mit langen Cache-Headern (z. B. Cache-Control: public, max-age=31536000, immutable). Bei Verwendung eines Bild-CDN wie Cloudinary oder imgix werden viele Schritte über URL-Transformationen automatisiert, aber wir codieren kritische Bilder dennoch vor, um Kaltstartkosten zu vermeiden.

Websites wie Unsplash [3] und Pixabay [1] bieten hochauflösende Bilder, die oft mehrere Megabyte roh wiegen. Unsere Pipeline reduziert sie drastisch ohne wahrnehmbaren Verlust. Ebenso kommen KI-generierte Bilder von Tools wie ChatGPT Images [4] oft in hoher Auflösung ohne Optimierung heraus, daher ist es entscheidend, sie durch denselben Komprimierungsworkflow zu führen. Stockbilder von Shutterstock [5] oder Bing Images [2] haben ähnliche Eigenschaften – große Dateien, die die Leistung beeinträchtigen können, wenn sie nicht optimiert sind.

Häufige Fallstricke, die wir sehen (und beheben)

• Fehlendes sizes vollständig: Der Browser lädt den größten srcset-Kandidaten herunter, da er 100vw annimmt. Geben Sie immer sizes an – selbst ein einfaches 100vw ist besser als nichts.
• JPEG für alles verwenden: Viele Teams liefern immer noch JPEG als einziges Format. Bis 2026 gibt es keine Ausrede mehr – WebP und AVIF sind ausgereift, und der Aufwand, sie hinzuzufügen, ist minimal.
• Übermäßiges Lazy-Loading: Jedes mit loading="lazy" markierte Bild verzögert den ersten sinnvollen Paint. Verwenden Sie loading="eager" für kritische Bilder und erwägen Sie, das Hero-Bild mit <link rel="preload" as="image" href="..."> vorzuladen, um die maximale LCP-Geschwindigkeit zu erreichen.
• Kein Fallback für animierte Formate: Wenn Sie animiertes AVIF verwenden (das eine lückenhafte Unterstützung hat), stellen Sie einen WebP- oder GIF-Fallback über <picture> bereit.
• Bilder on-the-fly in serverlosen Funktionen kodieren: AVIF-Kodierung ist CPU-intensiv. Ein Burst von Anfragen kann zu Timeouts oder Kostenexplosionen führen. Generieren Sie Assets immer während des Builds vor, außer bei benutzerhochgeladenen Bildern, die nicht vorgekocht werden können.

Wir haben auch Teams gesehen, die sich auf eine einzige Bildquelle ohne Versionierung verlassen. Wenn ein Designer ein Hero-Banner aktualisiert, wird die alte Datei überschrieben, was den CDN-Cache zerstört. Verwenden Sie Inhalts-Hashes in Dateinamen (z. B. hero-a1b2c3.avif), damit neue Versionen eine neue URL erhalten und alte unbegrenzt zwischengespeichert werden können.

Tool-Empfehlungen

Für Entwickler, die CLI bevorzugen, sind cwebp (von libwebp) und avifenc (von libavif) solide und scriptbar. Für Node.js-Pipelines ist sharp unschlagbar – es ist schnell, verarbeitet alle Formate und kann AVIF ausgeben (erfordert libvips, das mit AVIF-Unterstützung gebaut wurde). Für Ad-hoc-Vergleiche verwenden wir Squoosh oder Vergleichstools wie icdif (Image Compare Diff).

Für große Projekte empfiehlt sich ein Bild-CDN wie Cloudinary, imgix oder Fastlys Image Optimizer. Diese automatisieren Größenänderung und Formatverhandlung über URL-Parameter und übernehmen oft die AVIF-Kodierung in ihrer eigenen Caching-Schicht, sodass die CPU-Kosten nicht auf Ihrem Ursprungsserver anfallen. Beachten Sie jedoch die Abhängigkeit und die Kosten – für eine Website mit vielen Bildern kann die monatliche Rechnung beträchtlich sein. Wir empfehlen oft einen Hybridansatz: Generieren Sie die gängigsten Größen und Formate vor und lassen Sie das CDN seltene Breakpoints oder Benutzer-Uploads übernehmen.

Wenn Sie ein CMS oder einen Static Site Generator verwenden, gibt es Plugins für die meisten Frameworks (z. B. @next/image für Next.js, gatsby-plugin-sharp für Gatsby, eleventy-img für Eleventy). Diese übernehmen die Generierung und das Markup automatisch, aber wir empfehlen dennoch, die Standard-Qualitätseinstellungen zu überprüfen – sie sind tendenziell konservativ (verlustfrei oder nahezu verlustfrei), um Beschwerden zu vermeiden, was Bytes verschwenden kann.

Das Fazit

Bildoptimierung im Jahr 2026 ist eine Frage von Kompromissen: AVIF spart die meisten Bytes, kostet aber CPU; WebP ist der zuverlässige Mittelweg. Responsive Größen müssen präzise sein, nicht annähernd. Lazy Loading ist nahezu automatisch, erfordert aber eine durchdachte Anwendung, um LCP nicht zu beeinträchtigen. Eine gut abgestimmte Bild-Pipeline kann das Seitengewicht drastisch reduzieren – das ist ein direkter Gewinn für Benutzererfahrung, Core Web Vitals und Konversionsraten.

Wir haben Pipelines für Websites gebaut, die zig Millionen optimierte Bilder pro Monat ausliefern. Die Prinzipien sind unabhängig vom Maßstab dieselben: Kodierung zur Build-Zeit, ordentliches Fallback, responsive Größen und Lazy Loading, aber nicht gierig. Wenn Sie Ihre aktuelle Bildstrategie überprüfen oder Hilfe bei der Implementierung einer Pipeline benötigen, kontaktieren Sie DigiForge – wir können das Seitengewicht meist schon im ersten Durchlauf erheblich reduzieren.