WebP- & AVIF-Bildoptimierer — Vollständiger Leitfaden
Den WebP/AVIF-Bildoptimierer installieren, konfigurieren und nutzen: Engines Imagick/GD/Binärdateien, transparente Auslieferung per .htaccess oder picture-Umschreibung, natives Lazy-Loading, Komprimierung der Originale, Massenkonvertierung, CRON und CLI für PrestaShop 8 und 9.
Überblick
Der WebP- & AVIF-Bildoptimierer konvertiert und komprimiert die Bilder Ihres Shops direkt auf Ihrem eigenen Server und liefert anschließend jedem Besucher automatisch das leichteste Format aus, das sein Browser darstellen kann. Die gesamte Konvertierung erfolgt lokal: Es wird kein Bild an einen Drittanbieter gesendet, und es gibt keine Kontingente oder Credits.
Der entscheidende Punkt: Ihre Originaldateien werden nie überschrieben. Für jedes Bild produkt.jpg erzeugt das Modul produkt.jpg.webp und produkt.jpg.avif neben dem Original und liefert sie nur an kompatible Browser aus. Der Vorgang ist daher vollständig umkehrbar. Das Modul ist mit PrestaShop 1.7.6, 8 und 9 kompatibel und funktioniert mit Imagick, GD oder den Binärdateien cwebp und avifenc.
Voraussetzungen und Kompatibilität
- PrestaShop — 1.7.6 bis 9.x, einschließlich Multishop.
- PHP — 7.2 bis 8.3.
- Mindestens eine Bild-Engine — die Imagick-Erweiterung (empfohlen, mit WebP/AVIF-Unterstützung kompiliert), oder die GD-Erweiterung mit WebP/AVIF-Unterstützung, oder die System-Binärdateien
cwebpundavifenc. - Webserver — Apache (transparente
.htaccess-Auslieferung) oder Nginx (picture-Modus).
Sie sind nicht sicher, was Ihr Server unterstützt? Das Modul enthält eine Schaltfläche Engines testen, die ein Beispielbild konvertiert und Ihnen Format für Format anzeigt, welche Engine verfügbar ist und welche Größe sie erzeugt.
Installation
- Öffnen Sie im Backoffice Module > Modul-Manager.
- Klicken Sie auf Ein Modul hochladen und legen Sie das ZIP-Archiv des Moduls ab.
- Klicken Sie nach Abschluss der Installation auf Konfigurieren.
Bei der Installation legt das Modul seine zwei Tabellen an (Statistiken und Warteschlange), registriert seine Hooks, wendet einsatzbereite Standardeinstellungen an und schreibt, wenn der .htaccess-Auslieferungsmodus aktiv ist, seinen Regelblock in den Ordner /img. Das Vorhandensein mindestens einer Bildbibliothek (GD oder Imagick) wird geprüft: Ist keine verfügbar, wird die Installation mit einer eindeutigen Meldung abgebrochen.
Erste Schritte
Drei Schritte genügen, um Ihren gesamten bestehenden Katalog zu optimieren:
- Engines testen — klicken Sie auf der Konfigurationsseite auf Engines testen, um zu bestätigen, dass WebP und AVIF erzeugt werden können.
- Medienbibliothek scannen — klicken Sie auf Medienbibliothek scannen: Das Modul durchläuft die Zielordner und füllt die Warteschlange mit den zu verarbeitenden Bildern.
- Konvertierung starten — klicken Sie auf Konvertierung starten: Die Verarbeitung erfolgt in Stapeln, mit einem Fortschrittsbalken, und kann jederzeit pausiert und fortgesetzt werden.
Neue Bilder, die anschließend im Backoffice hinzugefügt werden, werden automatisch konvertiert (siehe Automatische Konvertierung beim Upload).
Konfiguration
Die Konfigurationsseite vereint ein Dashboard (Serverfähigkeiten und erzielte Einsparungen), das Stapelverarbeitungswerkzeug, das Einstellungsformular und ein Wartungspanel.
Next-Gen-Formate
- WebP erzeugen — aktiviert die Erstellung der
.webp-Dateien. - WebP-Qualität — von 1 bis 100. Der Bereich 80–85 bietet den besten Kompromiss aus Qualität und Größe.
- AVIF erzeugen — aktiviert die Erstellung der
.avif-Dateien. - AVIF-Qualität — AVIF ist dichter als WebP: Ein Wert von 45 bis 55 genügt in der Regel für eine ausgezeichnete Qualität.
Engine & Auslieferung
- Konvertierungs-Engine — Automatisch (empfohlen), Imagick, GD oder Binärdateien. Im automatischen Modus wählt das Modul die beste verfügbare Engine für jedes Format, in der Reihenfolge Imagick, dann GD, dann Binärdateien.
- Auslieferungsmodus — .htaccess (transparente Apache-Aushandlung), picture (HTML-Umschreibung für Nginx) oder keiner. Lassen Sie auf Apache
.htaccess: Es ist nichts weiter zu tun. Wählen Sie auf Nginxpicture.
Verzögertes Laden (Lazy-Load)
- Natives Lazy-Loading — fügt den Bildern
loading="lazy"unddecoding="async"hinzu, ohne JavaScript und ohne SEO-Auswirkungen. - Einblendeffekt — eine dezente kosmetische Einblendung beim Erscheinen des Bildes (optional).
Komprimierung der Originale
- Originale rekomprimieren — speichert die originalen JPEG/PNG-Dateien in einer optimierten Version neu. Eine
.dforig-Sicherung wird aufbewahrt, um die Wiederherstellung zu ermöglichen. - JPEG-Qualität (Originale) — die beim Rekomprimieren der originalen JPEGs angewandte Qualität.
Das Rekomprimieren der Originale ist optional und standardmäßig deaktiviert. Die WebP/AVIF-Konvertierung liefert bereits den Großteil des Gewinns; aktivieren Sie die Rekomprimierung nur, wenn Sie auch die an ältere Browser ausgelieferten Dateien verkleinern möchten.
Geltungsbereich
- Zu verarbeitende Bildtypen — Produkte, Kategorien, Hersteller, Lieferanten, Filialen und CMS-Seiten. Die auf Ihrer Installation tatsächlich verfügbaren Typen werden automatisch erkannt.
- Theme-Bilder — verarbeitet auch den Ordner
assets/imgIhres Themes (und verwaltet dort bei Apache-Auslieferung eine eigene.htaccess). - Ausschließen — ein Muster pro Zeile: Jeder Pfad, der eines dieser Fragmente enthält, wird übersprungen (zum Beispiel
logooder/img/cms/banner).
Erweitert
- Automatische Konvertierung beim Upload — konvertiert jedes Produktbild, sobald es im Backoffice (neu) generiert wird.
- Animierte Bilder überspringen — animierte GIFs und PNGs (APNG) werden erkannt und unberührt gelassen.
- Mindestgröße (Bytes) — unterhalb dieser Größe wird das Bild übersprungen: Sehr kleine Bilder gewinnen durch die Konvertierung nichts.
- Stapelgröße — die Anzahl der pro AJAX-Anfrage oder Cron-Durchlauf verarbeiteten Bilder. 10 bis 30 wird bei Shared Hosting empfohlen.
Denken Sie nach jeder Änderung daran, zu speichern. Wenn Sie den Auslieferungsmodus ändern, wird der .htaccess-Block automatisch entsprechend hinzugefügt oder entfernt.
Wie die Auslieferung funktioniert
Das Modul erzeugt nur die Next-Gen-Dateien und teilt dem Server mit, wie er sie ausliefern soll. Die URLs Ihrer Bilder ändern sich nie.
.htaccess-Modus (Apache)
Das Modul schreibt einen Regelblock in /img/.htaccess. Wenn ein Browser produkt.jpg anfordert, liest der Server den Accept-Header: Kündigt er AVIF-Unterstützung an und existiert produkt.jpg.avif, wird diese Datei zurückgegeben; andernfalls wird WebP versucht, dann ersatzweise das originale JPEG. Ein Vary: Accept-Header wird hinzugefügt, damit Caches und CDNs die richtige Version pro Browser behalten. Alles ist transparent: Ihr Theme wird nicht verändert, und nichts geht kaputt, wenn Sie das Modul deaktivieren.
Der Block wird in /img/.htaccess geschrieben und nicht in das Stammverzeichnis, weil PrestaShop seine Stamm-.htaccess regelmäßig neu generiert. Der Ordner /img wird hingegen nicht von PrestaShop verwaltet: Der Block bleibt dort stabil.
picture-Modus (Nginx)
Auf Nginx-Servern ist die Aushandlung über .htaccess nicht verfügbar. Der picture-Modus schreibt dann die img-Tags der Seite in picture mit AVIF- und WebP-Quellen um, kurz bevor die Seite gesendet wird. Der Browser wählt selbst die erste Quelle, die er darstellen kann.
Einen großen Katalog optimieren (CRON und CLI)
Das AJAX-Stapelverarbeitungswerkzeug eignet sich für die meisten Shops. Für Tausende von Bildern oder zur Automatisierung der Verarbeitung neuer Bilder verwenden Sie den Cron oder die Kommandozeile.
CRON-Aufgabe
Planen Sie eine regelmäßige Anfrage an die im Panel Automatisierung der Konfiguration angezeigte URL. Sie ist durch ein Token gesichert:
https://ihr-shop/index.php?fc=module&module=datafireflyimageoptimizer&controller=cron&token=IHR_TOKEN&scan=1&limit=200
Der Parameter scan=1 startet vor der Verarbeitung einen Scan (nützlich, um neue Bilder zu erkennen), und limit legt die Anzahl der pro Durchlauf verarbeiteten Bilder fest.
CLI-Befehl
Für sehr große Medienbibliotheken verarbeitet die Kommandozeile die Warteschlange im Hintergrund, ohne Timeout:
php modules/datafireflyimageoptimizer/cli/optimize.php --scan --loop
Verfügbare Optionen: --scan (vor der Verarbeitung scannen), --loop (fortfahren, bis die Warteschlange leer ist), --limit=N (Stapelgröße), --types=products,categories (die Ziele für diesen Lauf einschränken), --force (Neukonvertierung erzwingen, auch wenn die Next-Gen-Dateien aktuell sind) und --quiet (minimale Ausgabe).
Wiederherstellung und Umkehrbarkeit
Da die Originale nie überschrieben werden, können Sie jederzeit zurückkehren. Im Panel Wartung entfernt die Schaltfläche Alles wiederherstellen die erzeugten .webp– und .avif-Dateien, stellt rekomprimierte Originale aus ihrer .dforig-Sicherung wieder her, entfernt den .htaccess-Block und leert die Statistiken. Im selben Panel können Sie bei Bedarf auch die .htaccess neu generieren.
Integrierte Sicherheit: Stellt sich eine Next-Gen-Version als schwerer als das Original heraus (das kommt bei manchen bereits stark komprimierten Bildern vor), wird sie automatisch verworfen. Der Browser erhält dann die Originaldatei.
Deinstallation
Die Deinstallation entfernt den .htaccess-Block, löscht die Tabellen und die Konfiguration des Moduls. Die bereits erzeugten .webp– und .avif-Dateien bleiben auf der Festplatte. Um mit einer sauberen Medienbibliothek zu starten, verwenden Sie zuerst Alles wiederherstellen im Tab Wartung und deinstallieren dann das Modul.
Fehlerbehebung
Next-Gen-Bilder werden nicht ausgeliefert. Prüfen Sie im Apache-Modus, dass mod_rewrite und mod_headers aktiv sind und dass .htaccess-Dateien berücksichtigt werden (AllowOverride-Direktive). Bestätigen Sie außerdem mit den Werkzeugen Ihres Browsers, dass die Bildanfrage tatsächlich einen Typ image/avif oder image/webp zurückgibt.
- Der Engine-Test schlägt für AVIF fehl — Ihr Imagick/GD ist wahrscheinlich nicht mit AVIF-Unterstützung kompiliert. Installieren Sie die
avifenc-Binärdateien, oder deaktivieren Sie AVIF und behalten Sie WebP. - Weiße Seite im Frontend nach der Aktivierung — das hängt in der Regel mit dem
picture-Modus auf einem stark angepassten Theme zusammen. Wechseln Sie zurück in den.htaccess-Modus (Apache) oder keiner, und wenden Sie sich dann an den Support. - Die Konvertierung ist langsam — verringern Sie die Stapelgröße, oder verlagern Sie die Verarbeitung auf den Cron oder die CLI, die für große Mengen ausgelegt sind.
- Manche Bilder werden nicht konvertiert — prüfen Sie, dass sie die Mindestgröße überschreiten, dass sie nicht animiert sind (wenn die Option aktiv ist) und dass kein Ausschluss-Muster auf sie zutrifft.
FAQ
Werden meine Bilder an einen externen Dienst gesendet?
Nein. Die gesamte Konvertierung erfolgt zu 100 % lokal auf Ihrem Server. Es wird kein Bild an Dritte gesendet, und es gibt keine Kontingente oder Credits.
Werden meine Originaldateien verändert?
Standardmäßig nicht: Die WebP- und AVIF-Versionen werden neben dem Original erstellt. Wenn Sie die Rekomprimierung der Originale aktivieren, wird eine .dforig-Sicherung aufbewahrt, um sie wiederherzustellen.
Muss ich mein Theme oder meinen Server anpassen?
Im Apache-Modus nein: Der .htaccess-Block kümmert sich um alles. Aktivieren Sie auf Nginx einfach den picture-Modus in den Einstellungen.
Welche Formate werden unterstützt?
Das Modul erzeugt WebP und AVIF aus Ihren JPEG-, PNG- und GIF-Dateien (nicht animiert).
Ist es mit PrestaShop 9 und Multishop kompatibel?
Ja, das Modul ist mit PrestaShop 1.7.6 bis 9.x kompatibel und funktioniert im Multishop-Kontext. Es verwendet ausschließlich offizielle Hooks.
Wie verarbeite ich einen Katalog mit mehreren Tausend Bildern?
Starten Sie den Scan und dann die Stapelkonvertierung per AJAX, oder planen Sie die CRON-Aufgabe oder den CLI-Befehl, die die Warteschlange im Hintergrund ohne Timeout verarbeiten.