Performance Revolution: Einrichtung und Hilfe

Laden Sie die ZIP-Datei unter Module > "Module Manager" hoch, installieren Sie sie und klicken Sie auf "Configure". Das Backoffice-Menü heißt Leistung und enthält Übersicht, "Cache", Ressourcen, Abfragen, Sicherung, Einstellungen und Systemprüfung.

Dokumentieren Sie vor dem Aktivieren weiterer Ebenen das Verhalten von Startseite, Kategorie, Produkt, Warenkorb, Kundenkonto und Bestellvorgang. Testen Sie sowohl im Kundenbrowser als auch im Mitarbeiterbrowser. Wählen Sie den gewünschten Shop und sichern Sie die Konfiguration, bevor Sie Core-Caching oder CDN-Regeln ändern.

Beginnen Sie unter Einstellungen > Cache-Backend. Der PHP-Prozess benötigt Schreibzugriff auf die PrestaShop-Cacheverzeichnisse und Verzeichnisse generierter Ressourcen. Für die Installation des PrestaShop-Redis-Objektcaches ist außerdem Zugriff auf die betroffene Core-Cacheklasse und Konfigurationsdateien erforderlich. Cloudflare-Aktionen benötigen ein Token mit Berechtigungen für die gewählte Zone und die gewünschten Vorgänge.

Speichern Sie und prüfen Sie den gewählten Adapter auf Übersicht. Wenn Redis keine Verbindung herstellen kann, prüfen Sie Hostname, Port, Authentifizierung, Datenbank und PHP-Redis-Unterstützung. Die Wahl des Modulbackends aktiviert nicht zwangsläufig auch den Core-Objektcache.

Öffnen Sie "Cache" > Übersicht für die Bereichsschalter Globaler Cache, "Front Office", "Back Office" und "Webservice". Sie sind im Modul standardmäßig aktiviert. Der globale Schalter steuert die Cachenutzung des Moduls; die Bereichsschalter beschränken die jeweiligen Anfragekontexte.

Verwenden Sie "Cache" > Ebenen zur Ebenensteuerung, "Browser" zum Prüfen von Einträgen, Seiten für Seitencachedaten und Voreinstellungen für verfügbare Voreinstellungen. Lesen Sie eine Voreinstellung vor dem Anwenden, da sie mehrere Einstellungen gleichzeitig ändert.

Öffnen Sie Einstellungen > Fragment-Caching.

Ein Entwickler kann ein Kategoriefragment unter Einbeziehung der Kategorieidentität cachen:

{mpr_cache id="category_products" ttl=3600 tags=["product","category"] vary=["category" => $category.id]}
  {foreach from=$products item=product}
    {include file='catalog/_partials/miniatures/product.tpl' product=$product}
  {/foreach}
{/mpr_cache}

Der Cacheschlüssel enthält Sprache, Shop, Währung und Standardkundengruppe, sofern die Kontexteinbeziehung nicht deaktiviert ist. Ergänzen Sie jeden weiteren Wert, der das Fragment beeinflusst, in vary. Verwenden Sie kundenspezifisches Markup in einem gemeinsamen Fragment nur mit geeigneter Variation oder dynamischer Ersetzung.

Verwenden Sie dynamische Platzhalter für unterstützte Werte der aktuellen Anfrage:

<span class="cart-count">{mpr_dynamic name="cart_count"}</span>
<span class="cart-total">{mpr_dynamic name="cart_total"}</span>
<span class="customer-name">{mpr_dynamic name="customer_name" default=""}</span>
<span class="csrf-token">{mpr_dynamic name="csrf_token"}</span>

Unterstützte Namen umfassen auch Kunden-, Sprach-, Währungs- und Shopwerte. Ein eigener Provider kann actionMPRDynamicContent verwenden:

public function hookActionMPRDynamicContent($params)
{
    if (($params['name'] ?? '') === 'loyalty_points') {
        return (string) $this->getCurrentCustomerPoints();
    }
    return $params['default'] ?? '';
}

Öffnen Sie Einstellungen > Abfrage-Cache.

Prüfen Sie erfasste Abfragen unter Abfragen. Aktivieren Sie Profiling zur Fehlerdiagnose und bewerten Sie anschließend dessen Zusatzaufwand, bevor Sie es dauerhaft aktiv lassen.

Öffnen Sie Einstellungen > Asset-Optimierung. Aktivieren und testen Sie jeweils eine Änderung in Ihrem Theme.

Die Aktivierung generierten CSS startet bei einer Shopanfrage keinen Browser. Erstellen Sie es mit den separaten Workern. Status des generierten Initial-CSS zeigt die Einsatzbereitschaft. Der Critical-CSS-Worker benötigt Node ab 22.12 und seine konfigurierte Browserumgebung. Folgen Sie den mitgelieferten Worker-Anweisungen für Generierung und Bereitstellung.

Diese CLI-Befehle prüfen oder initialisieren die Arbeit; sie führen die Browsergenerierung nicht selbst vollständig aus:

php modules/mprperformancerevolution/cli/critical-css.php --targets
php modules/mprperformancerevolution/cli/critical-css.php --seed
php modules/mprperformancerevolution/cli/critical-css.php --status
php modules/mprperformancerevolution/cli/page-type-css.php --status

Erstellen Sie die Offline-CSS-Daten nach relevanten Änderungen an Stylesheets, Templates, Skripten oder Inhalten neu. Fehlen generierte Daten oder sind sie ungültig, greift das Modul auf die vollständigen Stylesheets zurück.

Öffnen Sie Einstellungen > Sofortige Navigation.

Warenkorb, Bestellvorgang, Konto, Anmeldung, Links mit Abfrageparametern, Dateien, Nofollow-Links und Modultools sind durch die eingebaute Richtlinie ausgeschlossen. Der Server validiert auch spekulative Anfragen.

Öffnen Sie Einstellungen > Bilder.

AVIF-Kodierung zur Laufzeit kann GD imageavif oder Imagick mit AVIF-Unterstützung verwenden. GD AVIF benötigt in der Regel PHP ab 8.1. Stapelgenerierung kann auch das mitgelieferte Python-Backend nutzen, wenn Python, Pillow, pillow_avif und Prozessausführung verfügbar sind. WebP nutzt unterstützte GD-Funktionen.

Für Listenbilder gelten zusätzliche interne Standardwerte: Der Bildtypfilter ist standardmäßig aus; die Typenliste lautet default_sm,default_md,default_lg,home_default,product_main,product_main_2x. Dies sind keine separaten sichtbaren Felder im Standardformular Bilder. Ebenso beträgt die interne RUM-Stichprobenrate 0.1.

Führen Sie für einen kontrollierten Stapel im installierten Shop Folgendes aus:

php modules/mprperformancerevolution/scripts/generate-images-cli.php --quality=50 --webp-quality=80 --webp --limit=100

Mit wiederholbarem --path=PATH begrenzen Sie die Arbeit innerhalb des Shopstamms. --force generiert vorhandene Varianten neu. Prüfen Sie vor einem größeren Stapel die Anzahlen konvertierter, übersprungener und fehlerhafter Dateien.

Öffnen Sie Einstellungen > Origin-Seiten-Cache.

Dies ist ein tatsächlicher vollständiger Origin-Seitencache mit dem Cachemanager des Moduls. Er ist von CDN-HTML-Caching und Smarty-Fragmenten getrennt. Warenkorb-, Konto-, Bestell-, Admin-, AJAX-, unsichere Sitzungscookie- und unbekannte Abfrageanfragen umgehen ihn gemäß Laufzeitrichtlinie.

Aktivieren Sie ihn erst nach Prüfung einer anonymen Seite ohne Sitzungscookies und der erforderlichen Umgehungsfälle. Rufen Sie dieselbe anonyme URL zweimal auf und prüfen Sie X-MPR-PageCache. Testen Sie danach Anmeldung, Warenkorberstellung, Währungs-/Sprachwechsel und private Seiten in getrennten Browsersitzungen.

Öffnen Sie Einstellungen > CDN-Seiten-Cache. Beginnen Sie mit der standardmäßigen Cookie-Richtlinie "Strict".

Wenden Sie nach dem Speichern über die CDN-Aktionen die Regeleinrichtung an, verifizieren Sie sie und prüfen Sie das Ergebnis. Eine Änderung der Cookie-Richtlinie wendet Regeln erneut an und leert die Zone. Behandeln Sie fehlgeschlagene oder ausstehende Regelübergänge nicht als abgeschlossene Einrichtung.

Testen Sie anonymes Caching und private Umgehung separat. Anmeldungen, Warenkörbe, Bestellvorgang, Kontoseiten, AJAX, geschützte Modulrouten, Personalisierung und unsichere Anfragezustände dürfen kein anonymes HTML teilen. Behalten Sie die Aufbewahrungsfrist generierter Ressourcen bei, solange langlebiges HTML auf alte Ressourcen verweist.

Das Modul sendet Cacheheader und führt unterstützte Cloudflare-Vorgänge aus. Wie die Edge tatsächlich cacht, hängt weiterhin von Ihren Zonenregeln, den Berechtigungen des API-Tokens und davon ab, ob eine Antwort cachebar ist. Manche Cloudflare-Bereinigungsmethoden gibt es nicht in jedem Tarif.

Öffnen Sie Einstellungen > Cache-Aufwärmung.

Kopieren Sie das tatsächlich generierte Token in den Server-Scheduler. Ein typischer Runner-Befehl lautet:

* * * * * php /var/www/html/modules/mprperformancerevolution/cron.php --token=YOUR_TOKEN --max-tasks=20 --max-seconds=55 --context=cron

Passen Sie PHP- und Shoppfade an. Der Runner verarbeitet je nach Aufgabenstatus außerdem deklarierte Bereinigungen, ausstehende Invalidierungen/Bereinigungen, Bildaufträge und CSS-Wartung. Funktionsaktivierung und Aufgabenplanung sind getrennt zu prüfen.

Für einen manuellen Durchlauf nach der Bereitstellung eignet sich:

php modules/mprperformancerevolution/cli/warm-cache.php --full --both --url-set=all --concurrency=1 --resolve-ip=127.0.0.1 --max-seconds=120

Verwenden Sie --edge nur für Edge, --cron für den Cron-Modus und --help für unterstützte Argumente. Lesen Sie die Zusammenfassung zu deaktivierten, fehlgeschlagenen oder blockierten externen Schreibzuständen. Bei konservativen Standards kann ein pausierter oder budgetbegrenzter Durchlauf erwartbar sein.

Öffnen Sie Einstellungen > Kontrollübersicht. Erfassung von Messwerten aktivieren ist standardmäßig ein, Aufbewahrung der Messwerte beträgt 30 Tage und Messwerte echter Besucher ist ein. Die interne RUM-Stichprobenrate beträgt 10 Prozent. Dashboard-Metriken umfassen Adapterzustand, Treffer, Nichttreffer, Trefferquote, Speicher, langsame Abfragen und verfügbare TTFB-, FCP-, LCP-, CLS- und INP-Messungen.

Öffnen Sie Einstellungen > Entwicklungsmodus, um cachebezogene Einstellungen vorübergehend auszusetzen. Entwicklungsmodus startet inaktiv, speichert die vorherige Konfiguration und stellt sie bei Deaktivierung oder Ablauf wieder her. Mitarbeiter-Debug-Modus startet aus und aktiviert PrestaShop-Entwicklungsausgaben nur für erkannte Mitarbeiter mit validiertem Debugcookie des Moduls.

Unter Einstellungen > "Debug" sind Debug-Overlay, Debug-Panel aktivieren und Profiler-Panel standardmäßig aus. Erlaubte IP-Adressen und Erlaubte Mitarbeiter-IDs sind anfangs leer. Profiler: nur Mitarbeiter ist standardmäßig ein. Beschränken Sie die Diagnose beim Testen und deaktivieren Sie sie anschließend.

Optionale Profilerdateien liegen unter optional-overrides/classes/Hook.php und optional-overrides/classes/db/Db.php. Verwenden Sie den abgesicherten Installationsablauf für Profiler-Overrides, damit bestehende Overrides geprüft werden. Leeren Sie den PrestaShop-Klassen-/Cachestatus entsprechend diesem Ablauf. Überschreiben Sie fremde Overrides nicht durch bedingungsloses Kopieren. Entfernen Sie nicht mehr benötigte optionale Profiler-Overrides über denselben Ablauf.

Prüfen Sie nach jeder Konfigurationsänderung Startseite, Listenansicht, Produkt, Warenkorb und Bestellvorgang sowie Cacheheader und Umgehungsgründe in getrennten Kundensitzungen. Katalog-, Bestands-, Preis- und Inhaltshooks invalidieren unterstützte Cachetags; Theme-, Integrations- und CDN-Regeländerungen können dennoch explizites Cacheleeren erfordern.

Weicht der Adapter von Ihrer Auswahl ab, prüfen Sie Backend-Verfügbarkeit und Redis-Endpunktauflösung. Umgeht eine Seite den Cache, lesen Sie zuerst den Diagnosegrund, bevor Sie Grenzen erhöhen oder die Cookie-Richtlinie ändern. Prüfen Sie bei veraltetem HTML Origin und Edge separat und bestätigen Sie die abgeschlossene Invalidierung.

Beschädigen Bündelung, Aufschub oder CSS-Änderungen eine Komponente, deaktivieren Sie die betroffene Einstellung, leeren Sie deren generierte Dateien oder Cache und testen Sie erneut. Prüfen Sie bei generiertem CSS Status und Worker-Protokoll. Bei Bildfehlern prüfen Sie Encoderunterstützung und Schreibrechte. Bei ausstehendem Aufwärmen prüfen Sie Runner, Funktionsschalter, Hostlast und Budgets.

Entfernen Sie vor der Deinstallation selbst installierte optionale Profiler-Overrides und prüfen Sie aktive CDN-Regeln. Deaktivieren oder entfernen Sie moduleigene Edge-Regeln über den CDN-Ablauf, damit die Zone private Routen nicht ohne den vorgesehenen Origin-Schutz weitercacht. Sichern Sie benötigte Konfiguration und generierte Daten.

Die Deinstallation entfernt geplante Aufgaben, Mitarbeiter-Debug-Bootstrap, installierte Redis-Cacheklasse, Modulmenüs und Moduldatenbanktabellen. Prüfen Sie anschließend PrestaShops Core-Cachekonfiguration und externe CDN-Konfigurationen; gehen Sie nicht davon aus, dass der Module Manager alle externen Konfigurationen rückgängig macht.

Erfordert PrestaShop 1.6.1 oder neuer und PHP 7.1 oder neuer.