Zum Inhalt springen
SyncRefine
SyncRefine

Bildoptimierung: schnelle Produktseiten für Google

Bildoptimierung ohne Handarbeit: warum schwere Lieferantenfotos LCP und Core Web Vitals ruinieren und wie WebP und die richtige Größe wirklich helfen.

Kenneth Dekker
6 Min. Lesezeit

Ihr Lieferant schickt wunderschöne Produktfotos: 4000 mal 4000 Pixel, 7 MB pro Stück. Auf Ihrer Kategorieseite zeigen Sie sie als Thumbnail von 300 Pixeln, doch der Browser lädt weiterhin die vollen 7 MB herunter. Bei 40 Produkten auf einer Seite sind das fast 300 MB an Bildmaterial, das über die Leitung muss. Auf dem Handy, im 4G, im Bus.

Und genau in diesem Moment misst Google. Das größte Element, das sichtbar wird, fast immer ein Produktfoto, bestimmt Ihren Largest Contentful Paint. Bei solchen Dateien landet der im roten Bereich. Nicht weil Ihr Theme schlecht ist oder Ihr Hosting zu günstig, sondern weil das gelieferte Bild nie für einen Onlineshop gemacht wurde.

Warum Ihre Produktseite langsam ist: das Foto ist der Übeltäter

Wenn sich eine Produktseite langsam anfühlt, zeigen alle zuerst auf das Theme oder die Plugins. Meist zu Unrecht. Bilder sind der schwerste Bestandteil einer durchschnittlichen Seite: laut dem HTTP Archive Web Almanac 2025 rund 36 bis 37 Prozent des gesamten Seitengewichts. Auf einer medianen mobilen Startseite sind das etwa 911 KB Bildmaterial, mehr als JavaScript und Schriften zusammen. In einem Produktkatalog mit unbearbeiteten Lieferantenfotos liegt diese Zahl noch weit höher.

Der Haken liegt im Missverhältnis. Eine 4000 Pixel breite Datei, die Sie auf einer Fläche von 300 Pixeln zeigen, wird vom Browser erst vollständig geladen und dann verkleinert. Sie bezahlen die Bandbreite des großen Fotos und sehen davon nur ein kleines.

~7 MB
typisches Lieferantenfoto
911 KB
Bild auf medianer mobiler Seite (Web Almanac 2025)
36-37%
des Seitengewichts sind Bilder

Was Google genau misst: Core Web Vitals und LCP

Google bewertet das Ladeerlebnis Ihrer Seite mit drei Core Web Vitals. LCP (Largest Contentful Paint) misst, wie schnell das größte Element sichtbar ist, INP (Interaction to Next Paint) wie schnell Ihre Seite auf einen Klick reagiert, und CLS (Cumulative Layout Shift) wie stark das Layout während des Ladens noch verspringt. Die Schwellenwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1.

Bei Produktfotos ist LCP der Wert, der wehtut. Laut web.dev sind 2,5 Sekunden oder weniger gut, 2,5 bis 4 Sekunden verbesserungswürdig und über 4 Sekunden schlecht, gemessen am 75. Perzentil Ihrer Seitenaufrufe. Es ist auch der schwierigste der drei: Aus dem Web Almanac 2025 geht hervor, dass nur 62 Prozent der mobilen Seiten einen guten LCP erreichen.

Kurz gesagt: auf den meisten Produktseiten ist genau dieses große Produktfoto das LCP-Element. Google empfiehlt deshalb, das Foto im sofort sichtbaren Bereich niemals per Lazy Load zu laden. Tun Sie es doch, findet der Browser es zu spät und Ihr Score sackt ab.

Core Web Vitals sind ein bestätigter Bestandteil von Googles Page Experience-Signalen. Geschwindigkeit macht aus einer schlechten Seite keine gute, aber bei zwei gleich relevanten Ergebnissen kann sie den Ausschlag geben. Und Ihr Wettbewerber hat sein Bildmaterial vielleicht im Griff.

Was langsame Seiten wirklich kosten: von Ladezeit zu Umsatz

Das ist kein technisches Detail für Ihren Entwickler, es trifft direkt Ihren Umsatz. Google nennt die oft zitierte Zahl, dass 53 Prozent der mobilen Besucher abspringen, wenn die Ladezeit über 3 Sekunden liegt. Und die Deloitte-Studie Milliseconds Make Millions, über 37 Marken und mehr als 30 Millionen Sitzungen, zeigte, dass 0,1 Sekunden schnellere Ladezeit die Retail-Conversion um 8,4 Prozent steigerte und den durchschnittlichen Bestellwert um 9,2 Prozent.

Ein Zehntel Sekunde schneller brachte 8,4 Prozent mehr Conversion im Retail. Das Bild ist der größte Hebel, den Sie dafür umlegen können.
Deloitte / Google, Milliseconds Make Millions

Das Problem an der Quelle: Lieferantenfotos sind nicht für Ihren Onlineshop gemacht

Lieferanten fotografieren für die Druckerei und den Katalog, nicht für Ihre Produktseite. Was Sie bekommen, ist eine Studiodatei: ein JPEG von 4000 mal 4000 Pixeln, manchmal ein HEIC-Foto von 4,2 MB direkt aus einem Telefon, in einer Qualität, die auf Papier wunderschön, online aber reiner Ballast ist.

  • Fotos von 6 bis 8 MB, bei denen Ihre Seite mit 60 KB auskäme.
  • Formate wie HEIC oder TIFF, die nicht jeder Browser ohne Umweg anzeigt.
  • Dasselbe Stimmungsfoto, das bei zwanzig Varianten (purple, lila, violett) zwanzigmal geliefert und zwanzigmal gespeichert wird.

Manuell lösen heißt: jede Datei öffnen, in der richtigen Größe exportieren, komprimieren und hochladen. Für hundert Produkte ist das ein Tag. Für ein wachsendes Sortiment ist es nie fertig.

1 Produktfoto
datei product.webp
größe ~1600 px (srcset pro Fläche)
gewicht 84 KB
format WebP + JPEG fallback
laden eager, richtige Größe
// ~98% leichter, LCP unter 2,5s

Zum Umschalten klicken. Gleiches Foto, andere Datei.

Ohne SyncRefine
  • 4000px-Datei von 7 MB, gezeigt auf einer Fläche von 300px
  • Jeder Browser lädt die volle Auflösung, auch auf dem Handy
  • Dasselbe Foto dutzendfach pro Variante gespeichert
  • LCP im roten Bereich, Bandbreite und Speicher verschwendet
Mit SyncRefine
  • Jedes Quellfoto zu WebP, die richtige Größe pro Fläche
  • Thumbnail, Liste und großes Bild je in eigener Auflösung
  • Doppelte Fotos werden einmal gespeichert (Dedup)
  • Bis zu ~98% leichter, LCP und Core Web Vitals atmen wieder

Was Sie automatisieren können: WebP, die richtige Größe und Dedup

Produktfotos für Ihren Onlineshop zu optimieren, ist keine Designarbeit pro Produkt. Es sind drei mechanische Schritte, die eine Pipeline fehlerfrei und endlos wiederholt.

Konvertieren nach WebP

WebP liefert laut Googles eigener Studie 25 bis 34 Prozent kleinere Dateien als JPEG bei gleicher visueller Qualität, gemessen an SSIM. Und es ist eine sichere Wahl: laut caniuse.com unterstützen rund 96 bis 97 Prozent der Browser WebP, mit JPEG als Fallback für den Rest. AVIF geht noch etwas weiter, wird aber noch nicht so breit unterstützt, also ist WebP der pragmatische Standard.

Die richtige Größe pro Fläche

Ein Thumbnail braucht keine 4000 Pixel. Google empfiehlt nachdrücklich, Bilder in der richtigen Größe pro Gerät über srcset oder picture auszuliefern, damit ein Telefon eine kleine Variante erhält und ein großer Bildschirm die große. Einmal einstellen, und jedes neue Foto wird automatisch in allen Größen erzeugt.

Doppelte Fotos einmal speichern

Großhändler liefern oft dasselbe Stimmungsfoto für eine ganze Serie von Varianten. Dedup erkennt das und speichert die Datei einmal statt dreißigmal. Das spart Speicher und hält Ihre Mediathek übersichtlich.

So macht SyncRefine das
Vom Quellfoto zur schnellen Seite, automatisch
SyncRefine wandelt jedes Lieferantenfoto in WebP um, in der richtigen Größe pro Fläche von Thumbnail bis großem Bild, bis zu etwa 98 Prozent leichter, und speichert doppelte Fotos einmal. Schnellere Seiten verbessern bei Google Ihre Core Web Vitals und Ihren LCP. Sehen Sie, wie Sie Ihren Katalog in schnelle WebP-Bilder umwandeln oder was SyncRefine automatisch mit Ihrem Bildmaterial macht.

Was Bildoptimierung NICHT ist (und warum das ehrlich ist)

Wichtig, hier klar zu sein, denn in diesem Bereich wird viel versprochen. Das ist Kompression und Format-Optimierung. Es ist kein Entfernen von Hintergründen, kein Löschen von Wasserzeichen und schon gar kein KI-Upscaling, das aus einem schlechten Foto ein gutes macht. Ein hässliches Quellfoto bleibt ein hässliches Foto, nur eben leichter.

Und es arbeitet nicht-destruktiv. Ihre Originale bleiben bestehen und Ihr Shop wird nie überschrieben. Sie erhalten optimierte Varianten neben dem Original, die sauber in der Anbindung an WooCommerce und Magento landen. Wollen Sie sehen, wie das zu Ihrer bestehenden Struktur passt, dann lesen Sie wie SyncRefine Ihren bestehenden Shop liest und Bilder passgenau ausliefert.

Checkliste: ist Ihr Bildmaterial bereit für Google und schnelle Ladezeiten?

Gehen Sie diese Punkte durch, bevor Sie den Schluss ziehen, dass Ihr Theme langsam ist:

  • Liefern Sie WebP (mit JPEG als Fallback) statt reiner JPEGs aus?
  • Erhält jede Fläche ihre eigene Größe, oder laden Sie überall die große Datei?
  • Ist das Foto im sofort sichtbaren Bereich NICHT auf Lazy-Load gesetzt, damit Ihr LCP nicht absackt?
  • Werden identische Fotos einmal statt pro Variante gespeichert?
  • Messen Sie LCP mobil am 75. Perzentil, nicht an Ihrem schnellen Büro-WLAN?
Kurz zusammengefasst
  • Das LCP-Element auf einer Produktseite ist fast immer das große Produktfoto, also trifft schweres Bildmaterial direkt Ihr Ranking.
  • WebP ist 25-34% leichter als JPEG bei gleicher Qualität und wird von ~96-97% der Browser unterstützt.
  • Der Gewinn liegt in der Automatisierung: konvertieren, die richtige Größe pro Fläche und doppelte Fotos deduplizieren, nicht in Handarbeit pro Produkt.
  • Ehrlicher Rahmen: das ist Kompression und Format, kein Hintergrund-Entfernen, kein Upscaling, und Ihre Originale bleiben intakt.
Bereit, Ihre Lieferantenfotos in schnelle WebP-Bilder umzuwandeln?
Geschrieben von
Kenneth Dekker
Automatisierung & Datenintegration
LinkedIn
Weiterlesen

Neugierig, was SyncRefine mit Ihren Produktdaten macht?

Buchen Sie eine unverbindliche Demo, wir zeigen es live an Ihren Daten.

Kenneth Dekker
Automatisierung & Datenintegration

„KI-Automatisierung ist keine Zukunftsmusik mehr. In einer halben Stunde zeigen wir Ihnen, was das für Ihr Unternehmen bringt.“

Unverbindlich und komplett maßgeschneidert