Produktbild-Strategie für Hyvä-Shops

Hyvä entfernt den Großteil des JavaScript- und CSS-Gewichts, das Luma mitbringt. Ist dieses Gewicht weg, bleiben die Bilder übrig.

Auf den meisten Produkt- und Kategorieseiten ist ein Produktfoto das größte Element auf dem Bildschirm. Damit ist Ihre Bildstrategie der größte Hebel, den Sie für den Largest Contentful Paint (LCP) noch selbst in der Hand haben.

Dieser Beitrag beschreibt unser Vorgehen in Hyvä-Shops: wie wir Bilder vorbereiten, wie wir sie ausliefern und welche Fehler uns Zeit gekostet haben.

Warum Bilder nach dem Wechsel zu Hyvä wichtiger werden

Setzen Sie in unserem Hyvä-vs-Luma-Benchmark: Eine schlanke Hyvä-Seite wog rund 200 KB und lieferte etwa 26 KB JavaScript aus.

Ein einziges nicht optimiertes Produktfoto kann schwerer sein als diese gesamte Seite.

In Hyvä kann deshalb ein einziges übergroßes Hero-Bild oder eine Galerie, die alle Fotos auf einmal lädt, einen Großteil dessen zunichtemachen, was das Theme Ihnen bringt.

Die gute Nachricht: Bilder lassen sich leicht messen und leicht optimieren, sobald die Pipeline richtig eingerichtet ist.

Beginnen Sie mit einheitlichen Quellbildern

Performance beginnt vor dem Upload. Einheitliche Quellbilder vereinfachen jeden weiteren Schritt.

• Ein Seitenverhältnis pro Bildtyp. Haben alle Produktfotos dasselbe Seitenverhältnis, springt das Raster nie, und die skalierten Kopien von Magento sehen alle einheitlich aus.
• Ein neutraler, einheitlicher Hintergrund. So wirken Kategorieseiten ruhig, und die Dateien lassen sich besser komprimieren.
• Eine feste Anzahl an Bildern pro Produkt. In unserem Hyvä-Demo-Shop verwenden wir zwei einheitliche Bilder im Studio-Stil pro Produkt, damit sich jede Produktkarte und jede Galerie gleich verhält.
• Sinnvolle Quellgröße. Laden Sie Bilder groß genug für den Zoom hoch, aber keine Kamera-Originale mit vielen Megabyte.

Einheitlichkeit ist auch ein Conversion-Thema. Kunden vergleichen Produkte schneller, wenn die Fotos denselben Regeln folgen.

JPG-Quellen behalten und Magento die Größen erzeugen lassen

Es ist verlockend, WebP-Dateien direkt hochzuladen. Wir haben es ausprobiert, und mit einem Standard-Setup funktioniert das nicht gut.

Der Standard-GD-Bildadapter von Magento lehnt WebP-Quelldateien mit dem Fehler “Unsupported image format” ab.

Deshalb behalten wir JPG-Quellen in der Mediengalerie. Magento erzeugt daraus die skalierten Kopien, die es für jede Bildrolle braucht, etwa das Vorschaubild in der Liste und das Bild auf der Produktseite.

Nach einem Import oder einem Theme-Wechsel erzeugen wir den Resize-Cache vorab, statt darauf zu warten, dass Besucher ihn auslösen:

bin/magento catalog:images:resize

Dieser Befehl kann bei einem großen Katalog eine Weile dauern. Führen Sie ihn außerhalb der Spitzenzeiten aus und bevor Sie Ihr CDN leeren.

WebP-Kopien per Cronjob erstellen

Sobald die skalierten JPGs vorhanden sind, erstellen wir neben jeder Datei eine WebP-Kopie.

Ein Cronjob führt cwebp -q 80 aus und schreibt file.jpg.webp neben jedem skalierten Bild, das noch keine WebP-Kopie hat.

find pub/media/catalog/product/cache -name '*.jpg' \
  ! -exec test -e '{}.webp' \; \
  -exec cwebp -quiet -q 80 '{}' -o '{}.webp' \;

Die JPG-Datei bleibt auf dem Server, sodass nichts kaputtgeht, wenn eine WebP-Kopie fehlt. Alle modernen Browser unterstützen WebP, in der Praxis erhält also fast jeder Besucher die kleinere Datei.

Theme-Bilder wie die Kacheln der Startseite und die Login-Seite exportieren wir direkt als WebP mit 720 px Breite und einer Qualität von etwa 72. Das sind Design-Assets, keine Katalogbilder, daher brauchen sie den Skalierungsschritt von Magento nicht.

Die WebP-URL mit einem kleinen Plugin ausliefern

Der klassische Weg, WebP auszuliefern, ist die Accept-Header-Negotiation in nginx. Hinter dem Einstiegsplan von Cloudflare hat das bei uns nicht funktioniert, weil Cloudflare seinen Bild-Cache nicht nach dem Accept-Header unterscheidet.

Deshalb haben wir die Entscheidung in Magento verlagert. Ein kleines Plugin auf Magento\Catalog\Model\View\Asset\Image ändert die URL, wenn auf dem Server eine WebP-Kopie existiert.

public function afterGetUrl(Image $subject, string $result): string
{
    if (is_file($subject->getPath() . '.webp')) {
        return $result . '.webp';
    }
    return $result;
}

Das HTML verweist jetzt direkt auf die WebP-Datei. Das CDN cacht sie wie eine normale statische Datei, und es gibt keine Header-Logik, bei der etwas schiefgehen kann.

Das komplette Setup inklusive der CDN-Details beschreiben wir in WebP-Produktbilder in Magento hinter Cloudflare ausliefern.

Ladereihenfolge: zuerst das LCP-Bild

Auch eine leichte Datei lädt langsam, wenn der Browser sie spät abruft. Die Ladereihenfolge ist genauso wichtig wie die Dateigröße.

• Laden Sie das Hauptproduktbild nie per Lazy Loading. Das erste Galeriebild ist auf einer Produktseite meist das LCP-Element und sollte daher sofort (eager) geladen werden.
• Erwägen Sie fetchpriority="high" für dieses erste Bild, damit der Browser es früh abruft.
• Laden Sie alles unterhalb des sichtbaren Bereichs per Lazy Loading. Weitere Galeriebilder, ähnliche Produkte und Footer-Banner können warten.
• Behandeln Sie die erste Reihe einer Kategorieseite anders. Die ersten Produktkarten sind sofort sichtbar und sollten daher nicht auf Lazy Loading warten.
• Setzen Sie immer Breite und Höhe. Explizite Abmessungen verhindern, dass sich das Layout verschiebt, während die Bilder laden.

Hyvä-Templates sind einfaches PHTML mit Alpine.js, daher sind diese Änderungen in einem Child-Theme klein und gut lesbar. In unserem Leitfaden Ein Hyvä-Child-Theme richtig aufbauen erfahren Sie, wo solche Overrides hingehören.

Stolpersteine, auf die wir gestoßen sind

Die meisten Bildprobleme, die wir gesehen haben, hatten nichts mit Formaten zu tun, sondern mit Timing und Caching.

• Bilder, die im CDN gecacht wurden, bevor der Resize-Cache existierte. Das CDN lieferte weiter die alte Antwort aus. Nach einem vollständigen Resize leeren wir das CDN nach Hostname.
• WebP per Accept-Header wird vom CDN ignoriert. Deshalb liefern wir WebP stattdessen über die URL aus.
• Startseiten-Banner in voller Kameragröße hochgeladen. Ein einziges CMS-Banner kann schwerer sein als der Rest der Seite, deshalb legen wir klare Exportregeln für das Content-Team fest.
• Zu viele Bilder im ersten Viewport. Slider mit mehreren großen Slides laden mehr, als der Besucher sieht.

Eine praktische Checkliste

1. Legen Sie ein Seitenverhältnis und einen Hintergrundstil für Produktfotos fest.
2. Laden Sie JPG-Quellen in sinnvoller Größe hoch.
3. Führen Sie catalog:images:resize nach Importen und Theme-Änderungen.
4. Erstellen Sie WebP-Kopien per Cronjob und liefern Sie sie über die Bild-URL aus.
5. Laden Sie das LCP-Bild sofort und den Rest per Lazy Loading.
6. Leeren Sie das CDN nach einem vollständigen Resize und testen Sie danach erneut.

In unserem Hyvä-Demo-Shop ist dieses Vorgehen ein Teil davon, wie wir mobile Lighthouse-Werte von 96 auf der Startseite, 90 auf der Kategorieseite und 92 auf der Produktseite erreichen (Median-Läufe).

Bilder sind auch Teil der Vereinbarung hinter unserem Launch-Ziel von mindestens 89 für mobile Lighthouse Performance auf Start-, Kategorie- und Produktseiten. Dieses Ziel setzt einen für Hyvä optimierten Server sowie abgestimmte Bilder und Skripte voraus.

FAQ

Kann ich WebP-Bilder direkt in Magento hochladen?

Mit dem Standard-GD-Adapter nicht zuverlässig, denn er lehnt WebP-Quellen mit dem Fehler “Unsupported image format” ab. Wir behalten JPG-Quellen und erzeugen WebP-Kopien, nachdem Magento sie skaliert hat.

Brauche ich noch JPG-Dateien, wenn alle Browser WebP unterstützen?

Wir behalten sie, weil Magento aus JPG skaliert und weil sie ein sicherer Fallback sind. Fehlt eine WebP-Kopie, wird automatisch die JPG-URL verwendet.

Sollte jedes Produktbild per Lazy Loading geladen werden?

Nein. Das Hauptproduktbild und die ersten sichtbaren Kategoriekarten sollten sofort geladen werden. Lazy Loading ist für Bilder unterhalb des sichtbaren Bereichs gedacht.

Sie möchten einen Hyvä-Shop, in dem Bilder von Anfang an mitgeplant sind? Werfen Sie einen Blick auf unsere Hyvä-Theme-Entwicklung, oder bitten Sie uns um einen Audit Ihres aktuellen Shops.