Wie leere ich den PrestaShop-Cache richtig?

Um den PrestaShop-Cache richtig zu leeren, beginnen Sie im Back Office: Erweiterte Einstellungen > Leistung, dann auf Cache leeren klicken. Das reicht für die meisten Änderungen an Templates, Übersetzungen und Konfiguration.Performance-Seite - die Schaltfläche Clear cache und die Cache-Steuerungen.Wenn eine Änderung trotzdem nicht sichtbar wird, leeren Sie die tieferen Ebenen in der richtigen Reihenfolge: zuerst PrestaShop-Dateien, dann OPcache, dann alle CDN-, Varnish- oder Full-Page-Caches vor dem Shop.# Run from the PrestaShop root. This deletes cache contents, not the cache directories themselves. find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Older PS 1.6-style installs may also use these Smarty paths: find cache/smarty/compile -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find cache/smarty/cache -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Reset web OPcache by reloading the PHP service: sudo systemctl reload php8.2-fpm # Apache/mod_php alternative: sudo systemctl reload apache2Verlassen Sie sich nicht auf einen reinen CLI-Befehl opcache_reset(), außer Sie wissen sicher, dass CLI-PHP und Web-PHP denselben OPcache-Pool teilen. Auf normalem PHP-FPM-Hosting ist ein Reload von PHP-FPM der zuverlässige Reset. Nach einem serverseitigen Leeren muss der Webserver-Benutzer die Cache-Verzeichnisse wieder beschreiben können; falsche Eigentümer nach einer Bereinigung als root sind eine häufige Ursache neuer 500-Fehler.Der häufige Fehler ist, nur den Back-Office-Cache zu leeren und anzunehmen, OPcache oder ein Reverse Proxy würden folgen. Das tun sie nicht. Wenn Sie Cache-Warming und CDN-Purge-Automatisierung statt manueller Arbeit möchten, enthält Performance Revolution Cache-Warming und CDN-Purge-Logik, und Redis Cache Manager & Monitor hilft bei der Verwaltung eines Redis-Cache-Backends.

Wie viel RAM braucht PrestaShop?

Hier gibt es zwei getrennte Zahlen, und sie zu verwechseln ist der häufigste Fehler.PHP memory_limit (pro Request). Das ist, was PrestaShop tatsächlich pro Seitenaufruf oder Admin-Aktion verbraucht. Die offizielle PrestaShop-9-Dokumentation empfiehlt mindestens 512 MB. PrestaShop 8 kam mit 256 MB gut zurecht; der Sprung in PS 9 spiegelt den schwereren Symfony-Stack im Back Office wider. Import/Export, Modulinstallationen, Massen-Produktupdates und der Migrationsassistent brauchen dieses höhere Limit, setzen Sie es niedriger, bekommen Sie leere Bildschirme oder Fatal Errors wie Allowed memory size exhausted.Server-RAM des Hosts. Das ist der Gesamtspeicher auf VPS oder dediziertem Server, geteilt zwischen PHP-FPM-Workern, MySQL/MariaDB, Webserver, Redis oder Memcached, Cronjobs und Betriebssystem. Praktische Baselines:Unter 1 000 SKUs, wenig Traffic: 2 GB sind die realistische Untergrenze.Mittlerer Katalog (1 000 bis 20 000 SKUs), Caching aktiviert: 4 GB sind komfortabel.Großer Katalog (50 000+ SKUs) oder Multistore: 8 GB+ und ein dedizierter MariaDB-Tuning-Durchlauf.Bulk-Imports, Bildregeneration, große Migrationsjobs: zusätzlichen Puffer einplanen oder schwere Aufgaben in CLI-Cron verlagern.Wenn der Shop langsam wirkt, ist RAM selten das Erste, was Sie reparieren sollten, beginnen Sie mit Full-Page-Cache, Redis, OPcache und einem schlankeren Theme. Die tatsächliche Reihenfolge finden Sie in unserem PrestaShop performance tuning guide.Eine nützliche Kapazitätsprüfung ist nicht einfach memory_limit x max_children, weil nicht jeder Worker gleichzeitig das Limit erreicht, aber die Formel zeigt, ob der Host schon auf dem Papier unmöglich ist:PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroomZehn beschäftigte PHP-Worker mit einem 512-MB-Limit benötigen zum Beispiel mehr als einen 2-GB-VPS, sobald MariaDB einbezogen ist, auch wenn die meisten Requests weniger als das Limit nutzen. Halten Sie CLI-Limits für Bildregeneration und Imports hoch, aber vermeiden Sie, zu viele PHP-FPM-Worker auf einem kleinen Server laufen zu lassen. Wenn der Linux OOM Killer anfängt, PHP oder MariaDB zu beenden, ist es meist besser, die Workerzahl zu senken und Cache-/Datenbankdruck zu beheben, statt nur memory_limit zu erhöhen.

Welche Monitoring-Daten kann das Modul speichern?

Performance Revolution speichert technische Monitoring-Daten über Ihren Shop, aber nicht jede Monitoring-Tabelle hat dasselbe Datenschutzprofil. RUM-Zeilen basieren auf Timings, URL, Geräteklasse und Shop-Kontext statt auf Kundenprofilfeldern; Slow-Query-Logging ist anders, weil es rohen SQL-Text und Stack-Trace-Kontext speichert. Behandeln Sie es daher als potenziell sensible Diagnosedaten, wenn Ihre Queries Kunden-, Warenkorb- oder Bestellkennungen enthalten.Konkret speichert das Modul diese Tabellen:Performance metrics - zeitlich erfasste Messwerte mit Metriktyp, Wert und JSON-Kontext, um die Entwicklung des Shop-Verhaltens über die Zeit darzustellen.Aggregated metrics - zusammengefasste Werte nach Stunde, Tag, Woche und Monat, einschließlich Summe, Durchschnitt, Minimum, Maximum und Anzahl, damit Dashboards auch über längere Zeiträume nutzbar bleiben.Slow queries - Query-Hash, SQL-Text, Ausführungszeit, Controller, Stack Trace, Anzahl der Vorkommen sowie Zeitstempel für erstes und letztes Auftreten. Das Schema kann zusätzliche Platzhalter enthalten, aber der Profiler-Pfad zeichnet diese Felder auf und nicht geprüfte oder gesendete Zeilen.Real-user monitoring (RUM) - Browser-Timing-Daten aus Stichprobenbesuchen: TTFB, FCP, LCP, CLS, FID und INP, plus DOM-Timing-Felder, eine Resource-Timing-Zusammenfassung, URL, Gerätetyp und Shop.RUM aggregates - stündliche Stichprobenzahlen und Durchschnittswerte pro URL und Gerät für die RUM-Metriken. Das Aggregatschema enthält eine p75_lcp-Spalte, aber die aktuelle Aggregationsabfrage befüllt sie nicht.Häufiger Fehler: alle Monitoring-Daten als gleichermaßen risikoarm zu behandeln. RUM ist Timing-/Gerätediagnose, aber Slow-Query-Zeilen können alles offenlegen, was in der SQL-Anweisung enthalten war. Beschränken Sie den Zugriff auf diese Diagnosen genauso wie den Zugriff auf Datenbank-Logs.Die Standardwerte sind bewusst konservativ. Fragment-Cache ist mit einer TTL von 3600 Sekunden aktiviert, Query-Cache ist aktiviert, Metriken sind aktiviert, der Slow-Query-Schwellenwert liegt standardmäßig bei 0.1 Sekunden, die Metrikaufbewahrung standardmäßig bei 30 Tagen, Profiling ist standardmäßig aus, und RUM-Sampling liegt standardmäßig bei 0.1, also ungefähr 10 Prozent der geeigneten Seitenaufrufe. In einem Shop mit wenig Traffic können RUM-Diagramme dadurch spärlich wirken, bis genug Besucher gemessen wurden.Das Front-Script sammelt Browser-Timings mit den Performance APIs, sendet sie anschließend wenn möglich mit sendBeacon und fällt sonst auf XHR zurück. Der RUM-Controller akzeptiert JSON-POST-Daten, prüft, ob eine URL vorhanden ist, speichert bereinigte Timing-/Ressourcenfelder und gibt eine 204-Antwort mit No-Store-/Noindex-Headern zurück. Der Controller entfernt außerdem Set-Cookie-Header, sodass der Beacon-Endpunkt selbst keine Kunden-Cookies erstellt.Für die Bereinigung zeichnet der Query-Profiler langsame SQL-Abfragen nach Hash auf und aktualisiert Vorkommensanzahl und Zeitpunkt des letzten Auftretens, wenn dieselbe Query erneut auftritt. Rohe RUM-Daten können zu stündlichen Zusammenfassungen aggregiert werden, und ältere Rohzeilen werden nach der Aggregation entfernt. So bleiben langfristige Dashboards nutzbar, ohne jeden einzelnen Beacon dauerhaft zu speichern. Die wichtige Einschränkung ist, dass die aktuelle RUM-Aggregation Durchschnittswerte und Zählungen speichert, aber keinen berechneten 75. Perzentil-LCP.

PrestaShop-Cache verursacht Probleme. Soll ich ihn deaktivieren?

Lassen Sie den Cache in einem Produktivshop aktiviert. Caching gehört zu den wichtigsten Gründen, warum PrestaShop schnell ist. Wer es dauerhaft abschaltet, macht jede Seite für jeden Besucher langsamer, ohne die eigentliche Ursache zu beheben. Als Diagnoseschritt ist das vorübergehende Deaktivieren einer Cache-Ebene dagegen legitim. Schalten Sie eine Ebene testweise ab, wenn Sie klären müssen, ob ein Symptom überhaupt vom Cache kommt, typische Fälle: Template- oder Designänderungen erscheinen nicht im Front-Office; veraltete Preise, Bestände oder Blöcke überstehen ein normales Neuladen; eine Moduleinstellung scheint nach dem Speichern keine Wirkung zu haben. Gehen Sie kontrolliert vor: Ändern Sie immer nur eine Ebene, bevorzugt auf einer Staging-Kopie oder in einer ruhigen Phase, notieren Sie die Änderung und aktivieren Sie die Ebene direkt nach dem Test wieder. Verschwindet das Symptom bei abgeschalteter Ebene, wissen Sie, wo die veralteten Daten liegen. Die Lösung ist, diese Ebene zu leeren oder das fehlerhafte Modul bzw. Template zu korrigieren, nicht den Cache abgeschaltet zu lassen. Meist steckt ohnehin nur veralteter Cache dahinter, und richtiges Leeren löst das Problem. Folgen Sie den Schritten in Wie leere ich den PrestaShop-Cache richtig?, bevor Sie zu härteren Mitteln greifen.

Wie behandelt das Modul Cloudflare Edge Caching?

Performance Revolution lässt Cloudflare ganze HTML-Seiten für anonyme Besucher cachen: sobald eine Seite in den Edge-Cache gefüllt wurde, können weitere Aufrufe direkt von Cloudflare bedient werden. Cache-Misses, die erste Anfrage, abgelaufene Einträge sowie jeglicher angemeldeter oder Warenkorb-Traffic. Erreichen weiterhin Ihren Origin; es ist also eine Edge-Schicht vor PHP, keine Garantie, dass Anfragen es nie erreichen. Das läuft rein serverseitig, keine JavaScript-Tricks.Was bei jeder Anfrage passiert:Für einen anonymen Besucher auf einer cachebaren Seite (Startseite, Kategorie, Produkt, CMS, Suche und Ähnliches) werden die Header gesetzt, die Cloudflare anweisen, das HTML für die von Ihnen gewählte TTL zu cachen.Angemeldete Besucher und alle mit Warenkorb erhalten Bypass-Header, damit personalisierte Seiten immer frisch vom Origin kommen.Set-Cookie wird aus anonymen Antworten entfernt, weil ein CDN eine Seite, die ein Cookie setzt, nicht cachet.Cache-Tag-/Surrogate-Key-Header werden angehängt, sodass beim Bearbeiten eines Produkts oder einer Kategorie nur die betroffenen Seiten geleert werden statt der ganzen Website.Das Purgen passt sich automatisch Ihrem Cloudflare-Tarif an: Business- und Enterprise-Zonen leeren direkt per Tag in einem Aufruf, während free- und Pro-Zonen (die nur das Leeren per URL unterstützen) die Tags zu exakten URLs auflösen und in Cloudflares 30-URL-Stapeln leeren. Außerdem gibt es eine Zonen-Statusprüfung, die Ihre Cloudflare-Einstellungen ausliest, Rocket Loader, Brotli, HTTP/3, Always Online, SSL-Modus, Browser-Cache-TTL, und Fehlkonfigurationen meldet.Zwei ehrliche Grenzen. Erstens müssen Sie eine Cloudflare-Zone-ID und einen API-Token hinterlegen, damit das API-Purgen funktioniert; ohne sie sendet das Modul weiterhin Cache-Header, kann aber nicht aktiv purgen. Zweitens ist Edge-Caching standardmäßig aus und betrifft nur anonymen Traffic, bewusst so, damit Sie nie den Warenkorb eines Kunden einem anderen ausliefern.

Wie viele Produkte kann PrestaShop maximal verarbeiten?

Es gibt in PrestaShop kein offizielles Produktlimit, und die Software stoppt Sie bei keiner festen Kataloggröße. In der Praxis entscheiden Ihre Daten und Ihre Infrastruktur über die Kapazität, nicht die reine Produktanzahl. Kombinationen und Datenvolumen: Viele Attribute, Kombinationen und Merkmale vervielfachen die Datensätze weit über die Produktanzahl hinaus. Genau diese Menge muss die Datenbank tragen. Datenbank und Suche: Facettennavigation, Sortierung und der Suchindex wachsen mit dem Katalog; langsame Abfragen und das Neuaufbauen des Index werden meist zum ersten Engpass. Importe und Exporte: Große Feeds brauchen geplante, in Pakete aufgeteilte Importe; ein Komplettimport belastet den Shop stärker als das Tagesgeschäft. Hosting und Ressourcen: Prozessor, Arbeitsspeicher, Festplattentempo und Datenbankkonfiguration setzen die Obergrenze; ein großer Katalog auf zu kleinem Hosting bleibt langsam, egal wie gut die Software ist. Caching, Theme und Module: Gutes Caching kann die Auswirkungen der Kataloggröße verringern, während ein schweres Theme oder ein schlecht geschriebenes Modul den Nutzen begrenzen kann. Die ehrliche Antwort für Ihren Shop liefert eine Messung: Machen Sie einen Lasttest auf einer Staging-Kopie mit echtem Katalog und realem Traffic. Konkrete Optimierungsschritte finden Sie in unserem PrestaShop-Performance-Leitfaden.

Kann Performance-Debugging beschränkt werden?

Ja. Wenn Sie den Front-Office-Profiler in MPR Performance Revolution einschalten, entscheiden Sie, wer ihn sehen kann: Lassen Sie das Panel komplett aus oder zeigen Sie es, aber beschränken Sie es auf eingeloggte Mitarbeiter, damit Kunden Ihre Timings nie sehen.Debugging kann über die Modulkonfiguration eingegrenzt werden, statt umfassende Diagnosen zu aktivieren.Einer der nützlichsten PrestaShop-Performance-Tipps ist, den Live-Shop zu profilieren, nicht eine saubere Testkopie, echter Traffic, echte Module, echte Daten. Der Profiler fügt eine kleine Leiste hinzu, die SQL-Query-Anzahl und -Zeit jeder Seite zeigt und die langsamsten Queries sowie langsamsten Modul-Hooks auflistet. So sehen Sie genau, wo eine Seite Zeit verbringt, bevor Sie etwas ändern.Der häufige Fehler ist, einen Profiler öffentlich sichtbar zu lassen: Er leakt interne Details und fügt bei jedem Request Overhead hinzu. Halten Sie ihn nur für Mitarbeiter sichtbar, schalten Sie ihn aus, sobald Sie den Engpass gefunden haben, und handeln Sie nach dem, was er zeigt, meistens ein schwerer Modul-Hook oder eine nicht indexierte Query. Das Modul behandelt außerdem Redis Object Caching, Asset Deferral und OPcache-/Smarty-Cache-Warming, sodass Diagnose und Korrekturen am selben Ort liegen.Die relevanten Einstellungen sind zwei Schalter: profiler_panel_enabled aktiviert das Front-Office-Panel, und profiler_employees_only hält es hinter einer aktiven Back-Office-Mitarbeitersitzung. Die Mitarbeiterbeschränkung ist standardmäßig an, während das Panel selbst standardmäßig aus ist. Wenn Profiling startet, initialisiert das Modul die Instrumentierung früh im Request und injiziert das Panel dann vor , aber nur wenn der Collector aktiviert ist und das Mitarbeiter-Gate besteht.Für tiefere SQL- und Hook-Zuordnung enthält das Modul optionale Overrides, die jede Datenbankabfrage und per-Modul-Hook-Timing aufzeichnen, und der Query-Profiler protokolliert langsame Queries über dem konfigurierten Schwellenwert, der standardmäßig 0,1 Sekunden beträgt. Installieren Sie diese nur, wenn Sie diese Sichtbarkeit brauchen, weil sie absichtlich Instrumentierungs-Overhead hinzufügen. Ein guter Workflow ist: Mitarbeiter-only-Profiler aktivieren, eine langsame URL reproduzieren, Query-/Hook-Gesamtwerte erfassen, deaktivieren und dann die kleinste Cache-, Index- oder Moduländerung vornehmen, die den gemessenen Engpass adressiert.

Welche Cache-Backends sind in der Konfiguration verfügbar?

In der Einstellung „Cache Backend“ können Sie Auto-Erkennung (empfohlen), Redis, APCu oder dateibasiertes Caching wählen.Die Auto-Erkennung wählt automatisch die beste verfügbare Option in der Reihenfolge Redis → APCu → Datei. Sie müssen also nicht wissen, was Ihr Server unterstützt, fehlen Redis und APCu, greift das Datei-Caching, das immer funktioniert. Wählen Sie ein bestimmtes Backend nur, wenn Sie es erzwingen möchten; ist es nicht verfügbar, protokolliert das Modul einen Hinweis und fällt trotzdem auf die Auto-Erkennung zurück. So bleibt das Caching nie versehentlich deaktiviert.Bei Redis erhalten Sie die Verbindungsfelder: Host, Port, Passwort, Datenbanknummer und einen Schlüssel-Präfix (nützlich, wenn mehrere Shops eine Redis-Instanz teilen). Stellen Sie diese passend zum Redis-Dienst Ihres Hosters ein.Dies ist Teil von Performance Revolution. Wenn Sie kein eigenes Redis betreiben, es aber aus dem Back Office verwalten möchten, siehe Redis Cache Manager & Monitor.

Welche Datenbank sollte ich mit PrestaShop verwenden, MySQL oder MariaDB?

PrestaShop verwendet MySQL oder MariaDB als Datenbank-Engine. Nach den aktuellen offiziellen Systemanforderungen von PrestaShop 8 und PrestaShop 9 nennen beide als SQL-Unterstützung MySQL 5.7 minimum oder MariaDB 10.2 minimum, mit einer aktuellen Version empfohlen.Für einen neuen oder aktualisierten Produktionsshop behandeln Sie diese Werte als Mindestwerte, nicht als ideale Ziele. MySQL 8.0 oder ein aktuelles MariaDB-LTS-Release ist eine bessere Wahl als ein alter MySQL-5.7-Host, besonders für größere Kataloge, Suchtabellen, Kombinationen, Warenkörbe und Bestellhistorie. Nutzen Sie InnoDB-Tabellen, halten Sie genug Buffer-Pool-Speicher bereit und stellen Sie sicher, dass Backups und Wiederherstellungstests Teil des Hosting-Plans sind.PrestaShop 9 hat außerdem höhere Plattformanforderungen als ältere Installationen; die offiziellen Anforderungen empfehlen mehr PHP-Speicher pro Script als PrestaShop 8. Datenbankkompatibilität allein reicht nicht: PHP-Version, Extensions, Memory Limit, Dateisystemrechte und Modulkompatibilität müssen vor einem Upgrade weiterhin geprüft werden.Wenn Sie Shared Hosting nutzen, fragen Sie den Hoster nach der exakten MySQL-/MariaDB-Version und ob Sie Slow Query Log aktivieren oder Slow-Query-Berichte bekommen können. Das ist im täglichen PrestaShop-Performance-Betrieb wichtiger als der Markenname des Datenbankservers.Fragen Sie bei neuem Hosting nach der exakten Engine und Version, nicht nur nach "MySQL compatible". Manche Managed Hosts betreiben MariaDB hinter einem MySQL-Label, und das ist normalerweise in Ordnung, aber Sie brauchen trotzdem eine Version, die PrestaShops Anforderungen erfüllt, und eine Konfiguration, die Ihren Katalog tragen kann. Für Performance sind die wichtigen Stellschrauben meist InnoDB Buffer Pool Size, Disk-Latenz, Indizes, Slow-Query-Sichtbarkeit und ob die Datenbank mit PHP auf einem winzigen Shared Server konkurriert.Bei der Migration dumpen und restoren Sie mit dem richtigen Zeichensatz, behalten denselben Tabellenpräfix, sofern Sie ihn nicht bewusst ändern, und testen Suche, Produktspeicherung, Bestellerstellung und Back-Office-Grids nach dem Import. Alte Shops können MyISAM-Tabellen oder veraltete Indizes aus sehr alten PrestaShop-Versionen mitbringen; Konvertierung zu InnoDB und Indexbereinigung sollten bewusst mit Backup erfolgen, nicht als blinder Hosting-Panel-Klick.

Läuft Cache Warming standardmäßig automatisch?

Nein. In Performance Revolution ist das geplante Origin-Cache-Warming standardmäßig aus, das Flag cache_warming_enabled startet auf false, und der Cron-Warmer meldet schlicht „disabled" und tut nichts, bis Sie ihn einschalten.Ab Werk startet also niemand den Warmer für Sie. Sie bekommen die einsatzbereite Mechanik:Ein Cron-Eintrag, der nach Aktivierung Ihre URLs durchläuft, damit PHP-OPcache, Smarty-Templates und kombiniertes CSS/JS kompiliert sind, bevor echte Besucher eintreffen.Manuelle Warm-Steuerung im Back Office für einen Lauf auf Abruf.Einstellungen für Parallelität und eine maximale Laufzeit, damit ein Lauf einen kalten Server nicht überlastet.Ein Standard ist an: cache_warming_post_deploy_enabled steht auf true und erlaubt lediglich dem Post-Deploy-CLI-Befehl, nach einem Release einen vollen Warm-Lauf auszuführen. Es erlaubt diesen Befehl, es plant von sich aus nichts. Cloudflare-Edge-Warming (cdn_edge_warm_enabled) ist ebenso standardmäßig aus.Häufiger Fehler: das Cron-Flag aktivieren, aber nie einen echten Cron-Job (oder den Post-Deploy-Hook) einrichten, der es aufruft. Der Schalter sagt „erlaubt"; ein Scheduler muss ihn trotzdem auslösen.

Beschleunigen Sie stark frequentierte PrestaShop-Shops mit Redis-, APCu- oder Datei-Caching und Asset-Optimierung

Performance Revolution - Redis-Cache und Geschwindigkeitsoptimierung für PrestaShop

Performance Revolution - Umsatzverluste durch langsame Seiten reduzieren

Performance Revolution - Bei Cache-Problemen schnell reagieren

Performance Revolution, Redis-Cache und Geschwindigkeit für PrestaShop: Einstellungen zum verzögerten Laden von Assets

Performance Revolution - PrestaShop-Cache mit einem Klick leeren und vorwaermen

Performance Revolution - optimiertes Storefront-HTML mit minimierten und verzoegerten Assets

Beschleunigen Sie stark frequentierte PrestaShop-Shops mit Redis-, APCu- oder Datei-Caching und Asset-Optimierung

Performance Revolution

Name: Performance Revolution
Brand: mypresta.rocks
SKU: mprperformancerevolution
Price: 299.00 EUR
Availability: InStock

Cache-Modul für PrestaShop, Full-Page- und Redis-Cache, Cloudflare-Edge-Regeln und automatische Invalidierung

299,00 €

zzgl. MwSt.

Noch keine Bewertungen

Performance Revolution misst die Ladezeiten echter Kundenbesuche und reduziert wiederholte Arbeit in Ihrem PrestaShop-Shop. Die Installation aktiviert ein empfohlenes Profil; stärkere Eingriffe wählen Sie separat.

Cloudflare ist ein optionaler weltweiter Dienst zur Seitenauslieferung mit kostenlosen und kostenpflichtigen Tarifen. Öffentliche Seiten liegen dadurch näher am Besucher. Das Modul erkennt Ihren Tarif und verwaltet die Verbindung in PrestaShop.

Sie bestimmen ausgeschlossene Adressen, Vorbereitungszeiten und einzelne Bildverbesserungen. Öffentliche Kopien berücksichtigen Sprache, Währung, Land und Gerät; Preis- oder Bestandsänderungen erneuern betroffene Seiten. Warenkorb, Kasse, Kundenkonten und angemeldete Besuche greifen immer auf den laufenden Shop zu. Lokale WebP- und AVIF-Bilder setzen Serverunterstützung voraus, Originale bleiben erhalten.

Berichte nennen die konkrete langsame Seite samt Gerät, sodass Ihre nächste Optimierung dort ansetzt, wo Kunden tatsächlich warten.

Auf Lager

Sofortige Live-Demo Echter Shop, bereit in ca. 1 Min.

Angebot anfordern

Kaufen Sie als Unternehmen? 239,20 € Partner 20 % Partnerkonto beantragen

Erweiterte Lizenzoptionen erfordern JavaScript. Über die Standardschaltfläche „In den Warenkorb“ wird die ausgewählte Menge weiterhin als einfache, nicht konfigurierte Lizenzen hinzugefügt.

Lebenslange Lizenz pro Domain, sie gehört Ihnen dauerhaft. Enthält 3 Monate Support und Updates. Mehr erfahren

Die Demo ist das vollständige Modul: kaufen Sie jederzeit und aktivieren Sie dieselbe Installation, ohne Neuinstallation und ohne Datenverlust. Öffnen Sie den Tab „Lizenz“ des Moduls und klicken Sie auf „Über mypresta.rocks aktivieren“ (oder fügen Sie Ihren Schlüssel ein); Ihre Einstellungen und Daten bleiben unverändert. Updates installieren Sie mit einem Klick über den Tab „Aktualisieren“.

Support und Updates

3 Monate Kostenlos 6 Monate +39,00 € 9 Monate +65,00 € 1 Jahr +89,00 €

Support automatisch verlängern

+29,90 €/Monat

Nach dem anfänglichen Zeitraum verlängert sich der Support automatisch zum Preis von +29,90 €/Monat. Sie können jederzeit in Ihrem Konto kündigen.

Zusätzliche Dienstleistungen

Professionelle Einrichtung Wir konfigurieren das Modul vollständig nach Ihren Bedürfnissen: alle Optionen eingestellt, getestet und verifiziert innerhalb von 1 Werktag. +29,00 €

Visuelle Integration CSS- und Template-Anpassungen passend zu Ihrem Theme: inklusive geräteübergreifender Überprüfung und Screenshot-Review. +49,00 €

Optionen gesamt: 0,00 €

Ausgewählte Summe: 299,00 €

Wie beschleunigt ein Modul den gesamten Shop?

MPR Performance Revolution misst die Geschwindigkeit bei echten Kundenbesuchen, ordnet Verzögerungen der Datenbank, einzelnen Modulen und Seitenvorlagen zu und setzt Verbesserungen an öffentlichen Seiten, Bildern und Browserarbeit in einem PrestaShop-Verwaltungsbereich um.

Echte Besuche: Werte nach Seite, Gerät und Zeitraum machen aus einem allgemeinen Tempoproblem eine genaue Aufgabe.
Sichere öffentliche Seiten: geeignete Seiten liegen auf dem Shopserver und über Cloudflare bereit, private Einkaufszustände bleiben im aktiven Shop.
Aktuelle Inhalte: Katalog-, Preis-, Bestands-, Währungs- und Steueränderungen erneuern nur die betroffenen Seiten.
Leichtere Auslieferung: kleinere Shopdateien, später geladene Bilder sowie lokale WebP- und AVIF-Fassungen entlasten den Browser.
Diagnose und Pflege: langsame Datenbankarbeit, Seitenaufbau, alte Datensätze und ungenutzte Bilder werden zu konkreten Aufgaben.
Kleiner Einstieg, tiefe Steuerung: ein empfohlenes Profil arbeitet nach der Installation, alle wichtigen Entscheidungen bleiben anpassbar.

Performance Revolution beschleunigt die Seiten dieses Shops, auch diese.

Ansicht im Administrationsbereich: Wie beschleunigt ein Modul den gesamten Shop?

Welche Seiten lassen echte Kunden warten?

Das Modul erfasst bei wirklichen Besuchen die Zeit bis zur ersten Antwort und zum sichtbaren Hauptinhalt, die Reaktion auf Eingaben und die Stabilität des Seitenaufbaus. Die Werte bleiben im Shop und werden nach Adresse, Smartphone, Tablet oder Computer und Zeitraum gegliedert.

Eine langsame Produktseite auf Smartphones erscheint dadurch als genau diese Seite und Gerätegruppe. Der aktuelle Zeitraum steht neben dem vorherigen, sodass eine Änderung am Theme, an Bildern oder an der Seitenauslieferung anhand späterer Besuche beurteilt wird und nicht anhand eines einzelnen Tests unter Idealbedingungen.

Messwerte echter Besuche neben den Einstellungen für Asset-Zurückstellung und Cache-Vorwärmung

Wie bleiben vorbereitete Seiten schnell, ohne Warenkörbe zu vermischen?

Geeignete öffentliche Seiten liegen auf dem Shopserver bereit, bevor der vollständige Shopaufbau beginnt. Getrennte Fassungen bewahren den richtigen Shop, die Sprache, Währung, das Land und das Gerät, wenn diese Angaben den Inhalt verändern. Warenkorb, Bestellvorgang, Kundenkonto, angemeldete Besucher, private Sitzungsdaten und unsichere Anfragen gehen immer direkt durch den aktiven Shop.

Cloudflare stellt das weltweite Netz bereit und bietet einen kostenlosen sowie mehrere kostenpflichtige Tarife an. MPR Performance Revolution erkennt den gewählten Tarif, erstellt passende Regeln, beseitigt Konflikte und hält bereits geprüfte öffentliche Seiten bei einer vorübergehenden Serverstörung erreichbar. Sie wählen zusätzliche Adressausschlüsse und Zeitpläne, die festen Schutzregeln für private Seiten bleiben dabei unangetastet.

Änderungen an Produkten, Kategorien, Inhaltsseiten, Herstellern, Lieferanten, Bestand, Preisen, Kombinationen, Währungen und Steuern erneuern die zugehörigen öffentlichen Seiten, während der Rest bereit bleibt.

Der Konfigurationsbildschirm von Performance Revolution

Was erreicht den Käufer in einer leichteren Form?

Bilder von Produkten, Kategorien, Herstellern, Lieferanten, aktivem Theme und installierten Modulen erhalten im Shop WebP- und AVIF-Fassungen, wenn der Server diese Formate unterstützt. Die Originale bleiben erhalten, neue Shopbilder werden automatisch verarbeitet und bestehende Bilder gemeinsam umgestellt, ohne den Katalog an einen externen Bilderdienst zu senden.

Sie wählen Verkleinerung und Bündelung von Shopdateien, später ausgeführte Nebenarbeit, Entfernung ungenutzter Stilregeln und verzögertes Laden der Bilder getrennt. Die Übersicht zeigt ursprüngliche und verringerte Größe, damit zuerst risikoarme Maßnahmen laufen und stärkere Eingriffe einzeln geprüft werden.

Einstellungen zum Zurückstellen von Assets im Administrationsbereich mit Schaltern zur CSS- und JavaScript-Optimierung

Welche langsamen Aufgaben und alten Daten brauchen Aufmerksamkeit?

Langsame Datenbankvorgänge erscheinen mit Dauer, Häufigkeit und dem auslösenden Shopbereich. Die Detailanalyse nennt vollständige Tabellendurchläufe, ungenutzte Indizes und unnötige Sortierung, während die geschützte Seitenanalyse die Aufbauzeit Modulen und Vorlagen zuordnet. Eine Agentur erhält Ursache und Ort statt einer allgemeinen Beschwerde.

Die Pflege zählt verlassene Warenkörbe, Gastsitzungen, Verbindungshistorie und alte Statistiken vor dem Entfernen und bearbeitet ausgewählte Gruppen sofort oder nach Zeitplan. Sie pflegt außerdem gewählte Tabellen und erkennt nicht mehr referenzierte Bilder zur geschützten Entfernung, wobei Datensatz- und Speicherersparnis vorher sichtbar sind.

Das Dashboard von Performance Revolution

Wie schnell beginnt die Optimierung und wie tief reicht die Einstellung?

Die Installation setzt ein empfohlenes Profil für Messung, sichere Wiederverwendung, leichtere Shopdateien und später geladene Bilder. Die Auslieferung öffentlicher Seiten und die stärksten Browseränderungen bleiben bewusste Entscheidungen, daher arbeitet der Einstieg sofort, ohne alle Schalter gleichzeitig zu aktivieren.

Sie wählen selbst öffentliche Adressen, Ausschlussmuster, Umfang und Zeitpunkt der Vorbereitung, Bildformate, Aufbewahrungsfristen der Datenbank, Schwelle für langsame Vorgänge und jede Browsermaßnahme. Ein zeitweiliger Wartungsmodus speichert die aktiven Werte, pausiert sie während technischer Arbeiten und stellt den vorherigen Zustand danach wieder her.

Die Einstellungen von Performance Revolution

Referenz

mprperformancerevolution
PrestaShop-Kompatibilität

PS 1.6 – 9.x
Preismodell

Einmalkauf
Modultyp

Front & Back-office
DSGVO-relevant

Nein
Geschäftsziel

Abläufe optimieren
Externes Konto erforderlich

Nein
Modul-Komplexität

Komplettlösung
Phase der Customer Journey

Shop verwalten
Funktioniert mit Plattform

Keine externe Plattform

Was unsere Kunden über uns sagen

Unternehmensbewertungen

5.0 ★ ★ ★ ★ ★ (4 Bewertungen)

Kundenbewertungen werden geladen...

Noch keine Produktbewertungen

Teilen Sie als Erste/r Ihre Erfahrung mit diesem Modul.

Bewertung schreiben

Ihre Bewertung *

★ ★ ★ ★ ★

Bewerten Sie bestimmte Aspekte (optional)

Qualität

★ ★ ★ ★ ★

Preis-Leistung

★ ★ ★ ★ ★

Stabilität

★ ★ ★ ★ ★

Kompatibilität

★ ★ ★ ★ ★

Kundensupport

★ ★ ★ ★ ★

Ihr Name *

Ihre E-Mail *

Bewertungstitel

Ihre Bewertung *

Fotos hinzufügen (Max. 3)

Zum Hochladen klicken oder per Drag & Drop

Bietet eine vollständige Performance-Schaltzentrale für PrestaShop: Redis/APCu/Datei-Cache, Smarty-Fragment-Caching, Query-Caching, Asset-Optimierung, Lazy Loading, AVIF/WebP-Erzeugung, CDN-Page-Cache-Header für anonyme Besucher, Cache-Warming sowie ein Dashboard für Cache-Hit-Rate, langsame Abfragen, Core Web Vitals, Speicher und Status des Cache-Backends.

Vollständige Dokumentation lesen PDF herunterladen

Haben Sie eine Frage zu diesem Produkt? Unsere Experten helfen Ihnen gerne. Fragen Sie uns zu Installation, Kompatibilität oder technischen Daten.

1343 Fragen

9 Kategorien

Alle Fragen anzeigen

v1.5.152026-05-27

AddedFinalize performance endpoint SEO cleanup
AddedRetain generated assets across cache clears
AddedFlip CDN cache from whitelist to blacklist — cache all pages by default

Passt gut zu Performance Revolution

Module, die unser Team wirklich mit diesem kombiniert, und warum jedes davon in dasselbe Setup gehört.

Beschleunigen Sie PrestaShop-Seiten durch Lazy-Loading- und Decoding-Attribute für Shop-Bilder

Automatische SEO-Lazy-Tags für Bilder

69,00 €

★ ★ ★ ★ ★

Ergänzung

Performance Revolution gibt Ihrem Team breite Geschwindigkeitskontrollen, Caching, Cache-Warming, Asset-Handling und Engpassanalyse, einschließlich verzögertem Bildladen und lokal erzeugten WebP- und AVIF-Bildern, während ein spezialisiertes Bildlade-Werkzeug eigene einfache Einstellungen bietet.

Automatic SEO Images Lazy Tags deckt das ab und fügt loading="lazy" und optional decoding="async" hinzu, bei Produkt-, Listen- und bearbeitbaren Inhaltsbildern, ohne Theme-Änderungen. Es ergänzt die Performance-Suite: Neben ihren Bildeinstellungen bietet das spezialisierte Werkzeug eine eigene Steuerung und verzögert Bilder außerhalb des Sichtbereichs, damit der Browser priorisiert, was Käufer zuerst sehen, mit bewusst abgestimmten Ladeeinstellungen.

Zusammen gehen Sie Geschwindigkeit vom Server und vom Browser aus zugleich an. Performance Revolution kümmert sich um Caching- und Asset-Engpässe, während Lazy Loading bildreiche Seiten clientseitig entlastet: Eine Kategorie- oder Produktseite profitiert sowohl von gut verwaltetem Caching dahinter als auch von leichterem Bildladen vor dem Käufer, was die Gefahr verringert, dass langsame Seiten Traffic verlieren.

Alte Warenkörbe, Logs, Suchen und Mail-Datensätze aus Ihrer PrestaShop-Datenbank entfernen

Datenbankbereinigung

0,00 €

★ ★ ★ ★ ★

Ergänzung

Performance Revolution konzentriert sich auf Caching, Warming, Asset-Handling und Engpassanalyse. Daneben bietet es eigene Datenbankwartung. Mit der Zeit belasten jedoch angesammelte Betriebsdaten wie veraltete Warenkörbe, alte Logs und abgelaufene Einträge die tägliche Verwaltung, was außerhalb dessen liegt, was Cache-Tuning löst.

Database Cleanup ergänzt diese Wartung um szenariospezifische Aufbewahrung und Laufhistorie mit einem kontrollierten Back-Office-Bildschirm, um veraltete Warenkörbe zu entfernen, dazu Suchstatistiken, abgelaufene Sonderpreise, Logs, Verbindungen, Gastdatensätze und alte Mail-Einträge, mit Vorschau vor dem Löschen. Es ergänzt die Performance-Suite durch Datenhygiene, ein vom Laufzeit-Caching getrenntes Anliegen.

Zusammen eingesetzt bleibt Ihr Shop zur Laufzeit schnell und in seinen gespeicherten Daten schlank. Performance Revolution hält die Seitenauslieferung flott, während Database Cleanup hilft, das Aufblähen der Betriebstabellen durch nicht mehr benötigte Einträge zu verhindern, sodass die Verwaltung handhabbar bleibt, mit bewusst abgestimmten Bereinigungsbereichen und Zeitplänen beider Werkzeuge.

Redis-Cache in PrestaShop aus dem Back Office einrichten und die Verbindung sofort testen

Redis-Cache-Verwaltung & -Überwachung

99,00 €

★ ★ ★ ★ ★

Ergänzung

Performance Revolution bietet Caching, Warming und Engpassanalyse, doch ein fokussierter Shop wünscht sich oft einen dedizierten Weg, die Redis-Verbindung selbst zu prüfen und zu pflegen, getrennt vom breiteren Performance-Dashboard.

Redis Dashboard & Key Manager liefert genau das: ein Back-Office-Panel zur Konfiguration von Host, Port, Passwort, Datenbank und Schlüssel-Präfix, um die Verbindung zu testen über die PHP-redis-Erweiterung und Live-Metriken einzusehen wie Version, Laufzeit und Speicher. Es ergänzt Performance Revolution, indem es sich auf Redis-Prüfung und -Bereinigung als eigene Aufgabe konzentriert.

Zusammen erhalten Sie breites Performance-Management plus einen klaren, fokussierten Blick auf Ihr Redis-Backend. Performance Revolution kümmert sich um Caching-Strategie und Engpässe, während Redis Dashboard & Key Manager die Redis-Schicht einfach zu prüfen und zu bereinigen macht, sodass Sie seltener von einem falsch konfigurierten Cache-Backend überrascht werden, jedes Werkzeug deckt einen anderen Ausschnitt desselben Geschwindigkeitsziels ab.

Ihren PrestaShop-Shop mit einem Audit zu PHP-Profiling, Abfragen, Caching und Core Web Vitals beschleunigen

PrestaShop-Prüfung von Geschwindigkeit & Core Web Vitals

490,00 €

★ ★ ★ ★ ★

Messung

Performance Revolution gibt Ihnen die Stellschrauben, um an der Geschwindigkeit zu arbeiten; doch zu wissen, welche davon für Ihren konkreten Shop am meisten zählen, und ob der eigentliche Engpass PHP, Abfragen, Assets oder das Hosting ist, , erfordert oft eine externe, evidenzbasierte Einschätzung.

Performance Audit liefert genau das: Es profiliert Ihre Live-Site über PHP, langsame Abfragen, Cache und CCC, Core Web Vitals, die Bild-Pipeline, Theme-Assets, Hosting und CDN hinweg und stuft jeden Engpass nach seiner Auswirkung auf Ladezeit und Conversions ein. Es ergänzt das Modul, indem es diagnostiziert statt konfiguriert.

Der Vorteil: Ihr Tuning ist geführt. Sie behalten Performance Revolution, um Caching- und Asset-Änderungen umzusetzen, während das Audit Ihnen in Prioritätsreihenfolge sagt, wo die echten Bremsen in Ihrem realen Shop liegen, so fließt der Aufwand in den Engpass mit dem größten Ertrag, statt auf jede verfügbare Einstellung verteilt zu werden.

Alle bekannten Probleme anzeigen

14 Implementiert

14 Anfragen

Funktionswünsche werden geladen...

Vollständige Roadmap anzeigen

30 Tage Rückgaberecht
Einfache Rückgabe, keine Fragen

Plug & Play Module
Installieren, einrichten und profitieren

Support an erster Stelle
Priorität für Hilfe & Zufriedenheit

Vielleicht gefällt Ihnen auch

PrestaShop-Kunden mit sofortiger AJAX-Autovervollständigung schnell Produkte finden lassen

Smart Search Revolution

299,00 €

★ ★ ★ ★ ★

Durchstöbern Sie Produktmedien mit Swiper-Galerien, Videos und einer PhotoSwipe-Lightbox in PrestaShop

Gallery Revolution

299,00 €

★ ★ ★ ★ ★

Beschleunigen Sie die facettierte Suche in Ihrem PrestaShop-Shop mit sauberen Filter-URLs und SEO-Seiten

Filter Revolution

299,00 €

★ ★ ★ ★ ★

Zeigen Sie aktuelle Ansichten und Verkaufssignale auf Ihren PrestaShop-Produktseiten

Live-Statistiken zu Produktverkäufen & Aufrufen

149,00 €

★ ★ ★ ★ ★

Wer dieses Modul entwickelt und pflegt

Entwickelt und gepflegt von David Miller und mypresta.rocks. David arbeitet seit 2013 mit PrestaShop, und das Unternehmen hinter diesem Shop ist seit dem 3. Dezember 2018 eingetragen. Jedes Modul in diesem Katalog ist unsere eigene Arbeit, deshalb landen Ihre Supportfragen bei den Menschen, die den Code geschrieben haben. Das Änderungsprotokoll auf dieser Seite zeigt jedes Update mit Datum.

Über uns