Bildoptimierung für SEO: Format, Kompression, Auslieferung

1. Warum Bildoptimierung über SEO-Sichtbarkeit und Performance entscheidet

Bilder sind in den meisten Magento-Katalogen der grösste Einzelposten am Seitengewicht, oft 60 bis 70 Prozent der übertragenen Datenmenge einer Kategorie- oder Produktseite. Da das Largest Contentful Paint-Element fast immer ein Hero-Banner oder Produktfoto ist, deckelt die Bildoptimierung die erreichbare Performance, bevor JavaScript-Optimierungen überhaupt greifen können. Dieser Artikel geht bewusst über eine allgemeine Core-Web-Vitals-Betrachtung hinaus und konzentriert sich auf bildspezifische Hebel: Formatwahl, Kompression, Auslieferung und die textuellen SEO-Signale, die ein generischer Performance-Audit meist auslässt.

Die Google Bildersuche ist zudem ein eigenständiger, oft unterschätzter Traffic-Kanal, besonders für visuell geprägte Kategorien wie Mode, Möbel oder Wohnaccessoires. Trotzdem behandeln viele Shops Produktbilder rein als Dekoration und optimieren sie nie für die Rankingfaktoren der Bildersuche: Dateiname, Alt-Text, umgebender Kontext, strukturierte Daten und Sitemap-Einbindung. Beide Dimensionen gleichzeitig sauber umzusetzen erfordert eine koordinierte Pipeline statt einzelner manueller Handgriffe pro Produktbild.

2. Bildformate im Vergleich: WebP, AVIF vs. JPEG, PNG

JPEG bleibt der verbreitetste verlustbehaftete Standard für Fotos, aber WebP erreicht bei vergleichbarer visueller Qualität typischerweise 25 bis 35 Prozent kleinere Dateien, weil es modernere Prädiktions- und Entropiekodierung nutzt. WebP unterstützt zusätzlich verlustfreie Kompression und einen Alphakanal für Transparenz, wodurch es PNG in fast allen Anwendungsfällen ersetzen kann, ohne Qualitätseinbussen bei Icons oder Produktbildern mit transparentem Hintergrund.

AVIF geht noch weiter und erzielt gegenüber WebP oft weitere 20 bis 50 Prozent Einsparung bei vergleichbarer wahrgenommener Qualität, weil der zugrunde liegende AV1-Codec deutlich effizienter komprimiert. Der Nachteil: Die Enkodierung ist rechenintensiver und dauert in Build-Pipelines spürbar länger, und ältere Safari- und Edge-Versionen unterstützen AVIF nicht vollständig. In der Praxis liefert eine Formatkaskade über das <picture>-Element AVIF für moderne Browser, WebP als zweite Stufe und JPEG als universellen Fallback aus.

3. Kompression: Qualitätsstufen, verlustbehaftet vs. verlustfrei

Die Kompressionsqualität ist der Hebel mit dem grössten Einfluss auf die Dateigrösse, wird in der Praxis aber oft falsch eingestellt. Viele Shops liefern Produktbilder mit Qualität 95 oder 100 aus, obwohl der visuelle Unterschied zu Qualität 75 bis 82 für die meisten Nutzer nicht wahrnehmbar ist. Für Produktfotografie mit vielen Details reicht in der Regel Qualität 80, für Icons und Illustrationen mit wenigen Farben lohnt sich verlustfreie Kompression, weil verlustbehaftete Verfahren dort sichtbare Artefakte um scharfe Kanten erzeugen.

Tools wie Squoosh, Sharp oder ImageMagick erlauben automatisierte, reproduzierbare Kompression als Teil der Build- oder Deploy-Pipeline, statt Bilder manuell in einem Bildbearbeitungsprogramm zu exportieren. Wichtig ist, niemals bereits komprimierte Bilder erneut verlustbehaftet zu komprimieren, da sich Kompressionsartefakte mit jedem Durchlauf akkumulieren. Die Zielgrösse sollte pro Bildtyp definiert sein, etwa maximal 150 KB für ein Hero-Bild und maximal 60 KB für ein Produktlisten-Thumbnail, und automatisiert im CI-Prozess überprüft werden.

4. Responsive Images: srcset, sizes und Art Direction

Ein einzelnes Bild in maximaler Auflösung an alle Geräte auszuliefern verschwendet auf mobilen Viewports erhebliche Bandbreite. Das <img>-Attribut srcset mit Breitenbeschreibungen gibt dem Browser mehrere Auflösungsvarianten zur Auswahl, während sizes dem Browser mitteilt, wie breit das Bild im jeweiligen Layout tatsächlich dargestellt wird. Der Browser wählt dann selbstständig die passende Datei, abhängig von Viewport-Breite und Pixeldichte, ganz ohne JavaScript.

Für Art Direction, also unterschiedliche Bildausschnitte je nach Viewport statt nur unterschiedlicher Auflösungen, reicht srcset allein nicht aus. Das <picture>-Element mit mehreren <source>-Elementen und media-Queries erlaubt es, auf Mobilgeräten einen engeren Bildausschnitt zu zeigen als auf Desktop, etwa bei Hero-Bannern mit viel Textanteil. In Hyvä-Themes lässt sich diese Logik sauber in einem ViewModel kapseln, das pro Bildtyp die passenden Breakpoint-Varianten aus dem Magento-Media-Gallery-Resizer generiert, statt Markup in jedem Template zu duplizieren.

<!-- Hyvä phtml: responsive product image with a modern-format fallback chain -->
<picture>
    <source type="image/avif"
            srcset="{{$block->getImageUrl('avif', 400)}} 400w,
                    {{$block->getImageUrl('avif', 800)}} 800w,
                    {{$block->getImageUrl('avif', 1200)}} 1200w"
            sizes="(min-width: 1024px) 33vw, 100vw">
    <source type="image/webp"
            srcset="{{$block->getImageUrl('webp', 400)}} 400w,
                    {{$block->getImageUrl('webp', 800)}} 800w,
                    {{$block->getImageUrl('webp', 1200)}} 1200w"
            sizes="(min-width: 1024px) 33vw, 100vw">
    <img
        src="{{$block->getImageUrl('jpg', 800)}}"
        srcset="{{$block->getImageUrl('jpg', 400)}} 400w,
                {{$block->getImageUrl('jpg', 800)}} 800w,
                {{$block->getImageUrl('jpg', 1200)}} 1200w"
        sizes="(min-width: 1024px) 33vw, 100vw"
        width="800"
        height="800"
        loading="lazy"
        decoding="async"
        alt="{{$block->escapeHtmlAttr($block->getImageAlt())}}"
        class="w-full h-auto object-cover rounded-lg"
    >
</picture>

5. Lazy Loading unterhalb des Folds richtig einsetzen

Natives loading="lazy" verzögert das Laden eines Bildes, bis es sich dem sichtbaren Bereich nähert, und reduziert dadurch initiale Datenmenge und Serverlast spürbar, besonders auf Kategorieseiten mit vielen Produktbildern. Die Regel ist einfach, wird in der Praxis aber häufig verletzt: Alles oberhalb des Folds, insbesondere das LCP-Element, darf niemals lazy geladen werden, weil das genau die Metrik verschlechtert, die Lazy Loading eigentlich schützen soll.

Ein häufiger Fehler in Produktkarussells: Das erste sichtbare Bild wird lazy geladen, weil das Karussell-Markup pauschal ein loading-Attribut auf alle enthaltenen Bilder anwendet. Hier hilft nur eine bewusste Unterscheidung der ersten ein bis zwei sichtbaren Slides von den nachfolgenden. Für Hintergrundbilder, die über CSS background-image statt <img> eingebunden sind, funktioniert natives Lazy Loading nicht. Dort ist ein IntersectionObserver notwendig, der die Bild-URL erst beim Erreichen des Viewports setzt.

// Lazy-load CSS background images once they approach the viewport
const bgObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach((entry) => {
    if (!entry.isIntersecting) return;
    const el = entry.target;
    el.style.backgroundImage = `url(${el.dataset.bg})`;
    el.classList.remove('bg-placeholder');
    observer.unobserve(el);
  });
}, { rootMargin: '200px 0px' });

document.querySelectorAll('[data-bg]').forEach((el) => bgObserver.observe(el));

// Never lazy-load the first one or two above-the-fold carousel slides
document.querySelectorAll('.carousel-slide').forEach((slide, index) => {
  const img = slide.querySelector('img');
  if (index < 2) {
    img.loading = 'eager';
    img.fetchPriority = index === 0 ? 'high' : 'auto';
  }
});

6. CDN- und Auslieferungsstrategien für Bilder

Ein Image-CDN wie Cloudflare Images, Fastly Image Optimizer oder imgix übernimmt Formatverhandlung, Resizing und Kompression direkt am Edge, basierend auf dem Accept-Header des anfragenden Browsers. Das bedeutet: Der Ursprungsserver, also Magento selbst, muss nicht mehr hunderte statische Bildvarianten für jede Kombination aus Auflösung und Format vorhalten, sondern liefert ein Ausgangsbild, aus dem das CDN bei Bedarf die passende Variante generiert und cached.

Für Magento-Shops reduziert das zusätzlich die Last auf pub/media und vereinfacht Deployments, weil setup:static-content:deploy nicht mehr für jede Bildgrösse separate Dateien erzeugen muss. Wichtig bei der CDN-Konfiguration sind lange Cache-Header (Cache-Control: public, max-age mit einem Jahr oder mehr) kombiniert mit versionierten oder gehashten Dateinamen, damit ein neu hochgeladenes Produktbild nicht mit veralteten Edge-Caches kollidiert. Ohne CDN empfiehlt sich mindestens ein dediziertes Media-Storage mit eigenem, aggressiv gecachtem Vhost, getrennt vom Anwendungsserver.

7. Alt-Text und Dateibenennung für Bilder-SEO

Der alt-Attributwert ist gleichzeitig Barrierefreiheits-Signal für Screenreader und eines der wenigen textuellen Rankingsignale, die Google für ein Bild direkt zur Verfügung hat, da Bildinhalte selbst nur näherungsweise interpretiert werden. Ein guter Alt-Text beschreibt präzise, was auf dem Bild zu sehen ist, etwa "Rote Leder-Sneaker Modell Aurora, Seitenansicht" statt generischem "Produktbild" oder keyword-gestopftem "Sneaker rot Leder kaufen günstig Angebot".

Rein dekorative Bilder, etwa Trennlinien oder Hintergrundgrafiken ohne Informationsgehalt, sollten ein leeres alt="" erhalten, damit Screenreader sie korrekt überspringen, statt sie mit einem irreführenden Alt-Text zu belegen. Auch der Dateiname trägt zur Bilder-SEO bei: rote-leder-sneaker-aurora.webp liefert Google mehr Kontext als IMG_20260304_0091.webp. In Magento lässt sich der Alt-Text pro Produktbild in der Media Gallery pflegen und sollte per Import-Skript oder Pflichtfeld-Validierung konsequent befüllt werden, statt leer zu bleiben.

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://mironsoft.de/media/catalog/product/rote-leder-sneaker-aurora.webp",
  "name": "Rote Leder-Sneaker Modell Aurora, Seitenansicht",
  "description": "Produktfoto des Sneaker-Modells Aurora in Rot, Leder, Seitenansicht auf weissem Hintergrund.",
  "width": 1200,
  "height": 1200,
  "license": "https://mironsoft.de/bildlizenz",
  "acquireLicensePage": "https://mironsoft.de/bildlizenz",
  "creditText": "Mironsoft",
  "creator": { "@type": "Organization", "name": "Mironsoft" }
}

8. Image-Sitemaps und Sichtbarkeit in der Google Bildersuche

Die Standard-XML-Sitemap von Magento listet nur Seiten-URLs, keine Bild-URLs. Die Sitemap-Erweiterung für Bilder ergänzt pro <url>-Eintrag <image:image>-Tags mit der Bild-URL und optional Titel und Beschreibung, wodurch Google gezielt auf Bilder hingewiesen wird, die sonst erst beim regulären Crawling der Seite entdeckt würden. Für Kategorien mit vielen Produktbildern beschleunigt das die Indexierung in der Google Bildersuche spürbar.

Magento bringt Image-Sitemap-Unterstützung nicht standardmässig mit, sie erfordert eine Erweiterung des Sitemap-Moduls oder ein dediziertes Drittanbieter-Modul. Ergänzend hilft strukturiertes ImageObject-Schema auf Produktseiten, das Lizenzinformationen, Bildunterschrift und Urheber maschinenlesbar macht. Die Google Search Console zeigt im Index-Coverage-Bericht, wie viele Bild-URLs tatsächlich indexiert wurden, und deckt zuverlässig auf, wenn Bilder durch robots.txt-Regeln oder fehlende Sitemap-Einträge unsichtbar bleiben.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://mironsoft.de/rote-leder-sneaker-aurora.html</loc>
    <image:image>
      <image:loc>https://mironsoft.de/media/catalog/product/rote-leder-sneaker-aurora.webp</image:loc>
      <image:title>Rote Leder-Sneaker Modell Aurora</image:title>
      <image:caption>Seitenansicht des Sneaker-Modells Aurora in Rot</image:caption>
    </image:image>
    <image:image>
      <image:loc>https://mironsoft.de/media/catalog/product/rote-leder-sneaker-aurora-detail.webp</image:loc>
      <image:title>Rote Leder-Sneaker Modell Aurora, Detailansicht</image:title>
    </image:image>
  </url>
</urlset>

9. Magento Media Gallery: Pipeline, Bulk-Optimierung und Cleanup

Magentos integrierter Bildresizer erzeugt beim Produkt-Import oder über bin/magento catalog:images:resize automatisch die im Theme definierten Bildgrössen aus dem Originalbild in pub/media/catalog/product. Seit Magento 2.4.6 unterstützt der Resizer WebP als Ausgabeformat nativ, muss dafür aber explizit in den Katalog-Einstellungen aktiviert werden, andernfalls fallen alle generierten Varianten weiterhin auf JPEG zurück, selbst wenn der Browser WebP anfordert.

Ein häufig übersehenes Problem: pub/media/catalog/product/cache wächst über Jahre unkontrolliert, weil alte Bildvarianten bei Theme-Wechseln oder Produktänderungen nicht automatisch bereinigt werden. bin/magento catalog:images:resize --regenerate zusammen mit einem regelmässigen Cache-Cleanup-Cronjob hält den Media-Storage schlank. Für AVIF-Unterstützung, die der Magento-Core noch nicht nativ abdeckt, bieten Module wie der Magefan Image Optimizer oder eigene Pub/Sub-Pipelines mit Sharp eine praxistaugliche Ergänzung, die sich in den regulären Import-Workflow einhängen lässt.

#!/usr/bin/env bash
# Bulk-convert Magento media gallery images to WebP and AVIF
set -euo pipefail

SOURCE_DIR="pub/media/catalog/product"
CACHE_DIR="pub/media/catalog/product/cache"

# Regenerate configured image sizes from the originals first
bin/magento catalog:images:resize

# Convert every generated JPEG/PNG variant to WebP (quality 80) and AVIF
find "$CACHE_DIR" -type f \( -iname "*.jpg" -o -iname "*.png" \) | while read -r file; do
  cwebp -q 80 "$file" -o "${file%.*}.webp"
  avifenc --min 20 --max 35 "$file" "${file%.*}.avif"
done

echo "Conversion done. Remember to purge stale CDN cache entries."

Die folgende Tabelle vergleicht die gängigsten Bildformate direkt gegenüber, als Entscheidungshilfe für die Formatstrategie im Shop.

In der Praxis wirken Formatwahl, Kompression und Auslieferung zusammen: Ein perfekt komprimiertes AVIF-Bild bringt wenig, wenn es ohne srcset in voller Auflösung an mobile Geräte ausgeliefert wird, und ein sauberes responsives Setup nützt wenig, wenn der Ursprungsserver keine modernen Formate erzeugt. Wer die Tabelle als Formatkaskade im <picture>-Element umsetzt und die Pipeline automatisiert, deckt den grössten Teil des Optimierungspotenzials ab.

10. Zusammenfassung

Bildoptimierung für SEO ist kein einzelner Schalter, sondern eine Kette aus mehreren Entscheidungen: das richtige Format (AVIF und WebP mit JPEG-Fallback), die passende Kompressionsqualität pro Bildtyp, responsive Auslieferung über srcset und sizes, gezieltes Lazy Loading unterhalb des Folds und eine CDN-Strategie, die Formatverhandlung und Caching automatisiert. Jede einzelne Massnahme spart nur wenige Prozent, in Kombination summieren sie sich aber häufig auf 60 bis 80 Prozent weniger Bilddatenvolumen gegenüber einem unoptimierten Magento-Standard-Setup.

Genauso wichtig wie die technische Auslieferung sind die textuellen Bilder-SEO-Signale: präzise Alt-Texte, sprechende Dateinamen, strukturierte ImageObject-Daten und eine vollständige Image-Sitemap. Erst das Zusammenspiel aus schneller Auslieferung und guter Auffindbarkeit in der Google Bildersuche macht aus Produktbildern einen echten Wachstumshebel statt einer reinen Performance-Bremse.

11. FAQ: Bildoptimierung für SEO