Hyvä läuft jetzt nativ auf Magento 2.4.9 und auf Mage-OS. Wir haben beides getestet. Was das für Ihren Shop bedeutet →
Kurz gesagt
Der Standard-Bildadapter von Magento akzeptiert keine WebP-Quelldateien, und die Accept-Header-Negotiation hat bei uns hinter dem Free-Plan von Cloudflare nicht funktioniert. Unsere Lösung: JPG-Quellen behalten, Magento skalieren lassen, jede skalierte Datei per Cronjob in WebP umwandeln und ein kleines Plugin nutzen, das die WebP-URL zurückgibt, wenn die Datei existiert. Das ist einfach, cache-sicher und funktioniert in jedem modernen Browser.
Produktbilder sind meist der schwerste Teil einer Magento-Seite und oft das größte Element auf dem Bildschirm. Sie als WebP statt JPG auszuliefern, ist einer der einfachsten Wege, Seiten leichter zu machen.


Das klingt nach einer Änderung in einer Zeile. In unserem Hyvä-Demo-Shop hat es drei Anläufe gebraucht. Dieser Beitrag zeigt, was gescheitert ist, was wir heute einsetzen und welches kleine Magento-Plugin alles zusammenhält. Es ist Teil unserer Performance-Arbeit an jedem Hyvä-Shop, und es funktioniert auch mit Luma.
Erster Versuch: WebP-Dateien hochladen
Naheliegend wäre, Produktbilder gleich als WebP hochzuladen. Der GD-Bildadapter von Magento, auf den meisten Servern der Standard, lehnt WebP-Quelldateien jedoch mit dem Fehler “Unsupported image format” ab.
Also haben wir JPG als Quellformat beibehalten. Das hat einen Nebeneffekt: Die Originaldateien bleiben in einem Format, das jedes Tool versteht, und Sie können die WebP-Qualität später ändern, ohne den Katalog anzufassen.
Wie Magento Produktbilder skaliert
Magento schickt nie den ursprünglichen Upload an den Browser. Es erstellt skalierte Kopien für jede Bildrolle aus der Theme-Datei view.xml, etwa für das Kategorieraster, die Produktgalerie und Thumbnails.
Diese Kopien liegen in pub/media/catalog/product/cache. Magento erzeugt sie bei Bedarf oder gesammelt mit diesem Befehl:
bin/magento catalog:images:resizeWir führen die Massen-Skalierung nach Importen und Theme-Änderungen aus, damit Kunden nie warten müssen, bis ein Bild erzeugt wird. Genau diese skalierten Dateien wandeln wir in WebP um.
Zweiter Versuch: Accept-Header-Negotiation
Der klassische serverseitige Ansatz nutzt den vom Browser gesendeten Accept Header. Browser, die WebP unterstützen, geben das in diesem Header an, und nginx kann file.jpg.webp statt file.jpg unter derselben URL ausliefern.
Auf einem einzelnen Server funktioniert das. Hinter dem Free-Plan von Cloudflare hat es bei uns nicht funktioniert, weil Cloudflare seinen Bild-Cache nicht nach dem Accept-Header unterscheidet.
Der erste Besucher entscheidet, welche Version Cloudflare für diese URL cacht. Alle nach ihm erhalten dieselbe Datei, egal was ihr Browser unterstützt. Eine URL, die zwei verschiedene Dateien ausliefert, ist ein Rezept für verwirrende Fehler – also haben wir die Idee verworfen.
Was wir heute einsetzen
Im funktionierenden Setup erhält die WebP-Datei eine eigene URL. Das Caching wird damit trivial, weil jede URL immer dieselbe Datei liefert.
- Produktbilder werden als JPG hochgeladen.
- Magento skaliert sie in den Bild-Cache-Ordner.
- Ein Cronjob führt
cwebp -q 80aus und schreibtfile.jpg.webpneben jedes skalierte Bild, das noch keine hat. - Ein Plugin ändert die Bild-URL auf die
.webpVersion, wenn diese Datei auf der Festplatte existiert.
Der Konvertierungsschritt ist eine kurze Shell-Schleife:
find pub/media/catalog/product/cache -type f -name '*.jpg' | while read -r f; do
[ -f "$f.webp" ] || cwebp -quiet -q 80 "$f" -o "$f.webp"
doneMit Qualität 80 erhielten wir deutlich kleinere Dateien, ohne einen sichtbaren Unterschied bei Produktfotos. Testen Sie einige Ihrer eigenen Bilder, denn der beste Wert hängt von der Fotografie ab.
Das Magento-Plugin
Magento erzeugt Produktbild-URLs in Magento\Catalog\Model\View\Asset\Image. Ein afterGetUrl Plugin auf dieser Klasse kann die URL austauschen, ohne ein einziges Template zu ändern.
Deklariert wird das Plugin im Modul in der Datei etc/frontend/di.xml:
<type name="Magento\Catalog\Model\View\Asset\Image">
<plugin name="vendor_webp_image_url"
type="Vendor\Webp\Plugin\ImageUrlPlugin"/>
</type>Das Plugin selbst prüft nur, ob die WebP-Kopie existiert:
public function afterGetUrl(Image $subject, string $result): string
{
if (is_file($subject->getPath() . '.webp')) {
return $result . '.webp';
}
return $result;
}Hat der Cron ein Bild noch nicht konvertiert, liefert das Plugin die normale JPG-URL. Nichts geht kaputt, und der nächste Seitenaufruf nach der Konvertierung erhält die WebP-Datei.
Alle modernen Browser unterstützen WebP, daher liefern wir es an alle aus und verzichten auf die alten Fallbacks mit dem picture-Element. Das hält das Markup schlank.
Wenn Sie lieber ein fertiges Modul verwenden, gibt es mehrere WebP-Extensions für Magento. Prüfen Sie, wie sie sich hinter Ihrem CDN verhalten, bevor Sie sich auf sie verlassen, und stellen Sie sicher, dass sie mit Hyvä-Templates funktionieren. Unser Team für Extension-Entwicklung kann das für Sie prüfen oder umsetzen.
Theme-Bilder und das CDN
Produktbilder sind nur ein Teil des Ganzen. Auch Theme-Bilder wie Kacheln auf der Startseite und das Bildmotiv der Login-Seite sind in unserem Demo-Shop WebP, 720 Pixel breit und mit einer Qualität von etwa 72.
Das CDN hielt noch eine Überraschung bereit. Cloudflare hatte einige Bild-URLs gecacht, bevor der Skalierungs-Cache existierte, und lieferte auch nach dem Erzeugen der Dateien weiterhin die falsche Antwort aus.
Die Lösung: den CDN-Cache für den Media-Hostnamen nach jeder Massen-Skalierung oder -Konvertierung leeren. Das ist bei uns inzwischen ein fester Schritt nach jedem Bild-Job.
Die Stolpersteine auf einen Blick
- WebP-Uploads werden vom GD-Adapter von Magento abgelehnt, behalten Sie daher JPG-Quellen.
- Die Accept-Header-Negotiation wurde vom CDN-Cache ignoriert – geben Sie WebP daher eine eigene URL.
- Bilder, die vor der Skalierung im CDN gecacht wurden, müssen geleert werden.
- Labortests können falsche Ergebnisse liefern, wenn Ihr Server Headless-Browser blockiert – mehr dazu in unserem Beitrag zu Lighthouse-Tests.
- Der Speicherbedarf wächst leicht, weil jedes skalierte Bild jetzt einen WebP-Zwilling hat.
FAQ
Warum nicht stattdessen in AVIF umwandeln?
AVIF kann noch kleiner sein, aber die Kodierung ist langsamer und die Tool-Unterstützung auf Servern weniger einheitlich. WebP brachte uns einen großen Gewinn mit einer einfachen, zuverlässigen Pipeline – deshalb haben wir damit angefangen.
Funktioniert das auch in Luma-Shops?
Ja. Das Plugin setzt an der Magento-Bild-Asset-Klasse an, nicht am Theme, daher profitieren Luma- und Hyvä-Shops gleichermaßen. Hyvä hat einfach weniger anderes Gewicht auf der Seite, daher fällt der Bildgewinn stärker auf.
Was passiert, wenn ein Produktbild ersetzt wird?
Magento erzeugt neue skalierte Dateien mit neuen Pfaden, und der Cron wandelt sie beim nächsten Lauf um. Bis dahin liefert das Plugin das JPG aus, sodass Kunden immer das richtige Bild sehen.
Sie möchten leichtere Produktseiten, ohne Ihren Katalog neu aufzubauen? Wie wir dabei vorgehen, sehen Sie hier: Magento-Performance-Optimierung, oder starten Sie einen Hyvä-Projekt mit uns.


