PrestaShop-Performance: Shop messen, untersuchen und verbessern

Was wir zuerst tun würden

Die richtige Lösung hängt vom bestehenden Shop ab: von Theme, Modulen, Integrationen, Katalogdaten, Hosting und Traffic. Zwei Shops mit demselben Geschwindigkeitswert können gegensätzliche Änderungen brauchen. Wir würden die langsame Seite reproduzieren, Serverzeit von Browserarbeit trennen und die Abfragen, Modulaufrufe oder Skripte ermitteln, die diese Zeit verbrauchen. Dominiert SQL, testen wir eine gezielte Abfrage- oder Indexänderung auf Staging, bevor Servereinstellungen geändert werden. Wartet die Datenbank auf den Datenträger oder konkurriert sie um Arbeitsspeicher, bewerten wir zuerst die Hostinglast. Kommt das Dokument zügig an, bleibt die Seite aber schwer bedienbar, arbeiten wir an Bildern, CSS und JavaScript.

Für die meisten Korrekturen ist der praktische Weg derselbe: Reproduzieren Sie das Problem auf einer isolierten Staging-Kopie mit realistischen Daten, proben Sie die Änderung dort mit einem getesteten Rückweg, setzen Sie sie als geplante Änderung um und wiederholen Sie dieselben Messungen im Live-Shop. Vergleichen Sie vor und nach jeder Änderung gleichwertige Anfragen, damit sich jedes Ergebnis dieser Änderung zuordnen lässt.

Den ersten Test nach dem Symptom wählen

Bitten Sie Ihren Entwickler um eine Anfrageanalyse, die aufwendige Arbeit, Verantwortliche, eine vorgeschlagene Änderung und den Vorher-nachher-Vergleich benennt. Ein Screenshot der Datenbankgröße oder ein einzelner Geschwindigkeitswert liefert diesen Nachweis nicht.

Wenn Sie diese Zuordnung für Ihren Shop erstellen lassen möchten, verfolgt das PrestaShop Speed & Core Web Vitals Audit echte Live-Anfragen durch Server, Datenbank und Browser und liefert einen priorisierten Maßnahmenplan; Codeänderungen, Serverkonfiguration und Hostingkäufe gehören nicht zu seinem Umfang und werden separat vereinbart.

Ausgangswerte erfassen und richtige Kennzahlen lesen

Testen Sie die Startseite, eine stark besuchte Kategorie, ein Produkt, den Warenkorb und den Bestellprozess sowie jede langsame Backoffice-Seite. Beziehen Sie Suche und Filter ein, wenn sie für Ihren Shop wichtig sind. Erfassen Sie URL, Core-/PHP-Version, Theme, aktivierte Module, Gerät, Standort, Verbindungsprofil, Kundenstatus, Sprache, Währung, Einwilligungsstatus, Cache-Zustand und Trafficbedingungen.

Nutzen Sie für kontrollierte Änderungen und Profiling eine Staging-Kopie mit realistischen Katalogdaten. Führen Sie mehrere vergleichbare Tests aus und halten Sie Median und Streuung fest. Vergleichen Sie einen neuen Besucher, einen wiederkehrenden Browser und einen angemeldeten Kunden getrennt und beziehen Sie ungecachte Anfragen ein: Ein schneller öffentlicher Cache-Treffer beweist nicht, dass Warenkorb oder Bestellprozess schnell sind. Eine Backoffice-Anmeldung aktiviert nicht automatisch das Profiling und macht Shop-Anfragen nicht schneller.

Die aktuellen Core-Web-Vitals-Zielwerte sind LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden und CLS höchstens 0,1, bewertet am 75. Perzentil jeweils für Mobilgeräte und Desktop. INP ersetzte FID im März 2024.

LCP betrifft den größten geeigneten sichtbaren Inhalt, oft ein Bild oder einen Textblock. INP betrifft die Reaktionsfähigkeit auf Interaktionen. CLS betrifft unerwartete Layoutverschiebungen. Diagnostizieren Sie das tatsächliche Element, Ereignis oder die Verschiebung, statt allein aus der Kennzahl eine Ursache abzuleiten.

Lighthouses Performance-Wert ist ein zusammengesetzter Laborwert, keine Conversion-Rate oder Rankingprognose. Seine Ladeprüfung enthält Total Blocking Time; ein normaler Seitenladetest bewertet Feld-INP nicht direkt. Accessibility, Best Practices und SEO sind separate Prüfkategorien, keine vollständige Zertifizierung dieser Themen. Lesen Sie die Erläuterung zur Bewertung und die einzelnen Befunde.

Eine normale GA4-Installation erfasst Core Web Vitals nicht automatisch und bietet nicht die alten Universal-Analytics-Berichte zur Websitegeschwindigkeit. Ergänzen Sie explizite Web-Vitals- oder RUM-Instrumentierung samt Ereignissen und Berichten. Segmentieren Sie nach Seitentyp, Gerät und Markt mit angemessenen Datenschutzkontrollen.

Erfassen Sie neben Geschwindigkeits- auch Geschäftskennzahlen. Akamais Einzelhandelsbericht von 2017 brachte in seiner Untersuchung 100 Millisekunden Verzögerung mit einer um 7 % niedrigeren Conversion-Rate in Verbindung. Dieses historische Ergebnis ist keine Formel zur Prognose der Verbesserung in Ihrem Shop.

Die Staging-Kopie isolieren und einen Rückweg vorbereiten

Isolieren Sie die Staging-Kopie, bevor die wiederhergestellte Anwendung, Worker oder geplante Aufgaben laufen. Geben Sie ihr eine eigene Datenbank, Sandbox-Ziele für Zahlungen und Integrationen, ein Testpostfach und kontrollierten externen Zugang. Beschränken Sie den Zugriff auf kopierte Kundendaten, damit Performance- und Cache-Tests keine echten Kundennachrichten oder Geschäftsvorgänge auslösen können.

Erstellen Sie vor dem Löschen von Datensätzen, dem Hinzufügen von Indizes, dem Neuaufbau von Tabellen oder einem Wechsel von Datenbank-Engine oder -Konfiguration zusammenpassende Datei- und Datenbank-Backups, testen Sie eine Wiederherstellung auf Staging und dokumentieren Sie das Rollback. Proben Sie die Änderung selbst unter Berücksichtigung von Sperren, Speicherplatzbedarf und Dienstunterbrechung, damit die Live-Bereitstellung einem bekannten Verfahren zu einem geplanten Zeitpunkt folgt. Bitten Sie den Hoster, die Konfiguration zu übernehmen, wo Sie den Server nicht selbst verwalten.

Halten Sie die Kopie nah am Produktivsystem: dieselben PrestaShop-, PHP- und Datenbankversionen, dasselbe Theme und dieselben Module, mit repräsentativen Daten. Die Staging-Hardware entspricht selten dem Live-Server; nutzen Sie sie daher für den Vorher-nachher-Vergleich und bestätigen Sie den Gewinn dann im Live-Shop mit denselben Ausgangsanfragen.

Verbindungszeit, Serverarbeit und Browserarbeit trennen

Clientseitig beobachtete TTFB umfasst Vorgänge vor Dokumentankunft wie DNS, Verbindungsaufbau, TLS, Weiterleitungen und Anfrage-/Antwortweg. Sie misst PHP-Ausführungszeit nicht direkt. Waiting in DevTools misst ein anderes Intervall. Nutzen Sie die Aufschlüsselung der TTFB-Zeiten zur Interpretation Ihres Werkzeugs.

Dieses Shell-Beispiel ruft eine Seite ab und zeigt kumulierte curl-Zeiten. Ersetzen Sie die Beispiel-URL durch eine echte Shop-URL:

url='https://example.com/'
curl --silent --show-error --output /dev/null   --write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'   "$url"

Diese Werte werden ab Übertragungsbeginn gemessen und sind keine zu addierenden Einzeldauern. Prüfen Sie Weiterleitungen separat oder erfassen Sie sie ausdrücklich. Wiederholen Sie mit kontrollierten Cache-Zuständen und geografischen Standorten.

Ein nach dem ersten Dokumentbyte geladenes Browserskript kann dieses erste Byte nicht verzögern. Es kann Rendering, Interaktionen oder spätere Anfragen verzögern. Ein PHP-Modul mit externer API-Anfrage vor HTML-Ausgabe kann die Serverantwort verzögern. Ein Browser-Wasserfalldiagramm allein identifiziert dieses PHP-Modul nicht.

Den passenden Profiler nutzen

Aktivieren Sie für klassisches PrestaShop-Profiling _PS_DEBUG_PROFILING_ in config/defines.inc.php auf einer zugriffsbeschränkten Staging-Kopie:

define('_PS_DEBUG_PROFILING_', true);

Laden Sie relevante Seitentypen und prüfen Sie SQL-Zeit, wiederholte Aufrufe, Hooks und Speicher innerhalb der Berichtsabdeckung. Setzen Sie das Flag anschließend wieder auf false. _PS_MODE_DEV_ ist ein separater Schalter für Entwicklung und Fehlerausgabe. Es ist weder der klassische Profilingschalter noch die Smarty-Kompilierungsrichtlinie.

Die Symfony-Werkzeugleiste deckt Anfragen des Symfony-Kernels ab. Ihr Doctrine-Bereich belegt keine vollständige Abdeckung klassischer SQL-Abfragen über Db. Bestätigen Sie instrumentierte Datenbank- und Hook-Pfade, bevor Sie sämtliche Arbeit einem Modul zuschreiben.

Ein öffentlicher URL-Test kann Erreichbarkeit und Browserzeiten bewerten. Interne Abfragezahlen, Cache-Trefferraten und Modulzeiten benötigen berechtigten Zugriff oder Instrumentierung. Auch gewöhnliche Seitenabrufe können Protokolle, Analysedaten oder Cache-Einträge erzeugen. Vereinbaren Sie deshalb Testumfang und Anfragevolumen.

Produktionseinstellungen getrennt prüfen

Prüfen Sie unter Erweiterte Einstellungen → Leistung jede Einstellung separat und testen Sie ihre Wirkung. Lassen Sie Entwicklungsmodus und Profiling im öffentlichen Produktivshop ausgeschaltet.

Verzögertes/asynchrones JavaScript und externe Ressourcen können außerhalb der normalen CCC-Kombination bleiben. Direkt von Hooks ausgegebene Tags können die Ressourcenverwaltung umgehen. Isolieren Sie bei CCC-Fehlern das betroffene Bundle oder die Abhängigkeit auf Staging und korrigieren Sie deren Registrierung; lassen Sie keinen defekten Bestellprozess weiterlaufen.

Deaktivieren Sie verdächtige Module auf Staging und vergleichen Sie Messungen. Normale Hooks deaktivierter Module werden durch Core-Ausführungsprüfungen ausgeschlossen. Deinstallieren Sie nur tatsächlich unerwünschte Module nach Prüfung ihres Deinstallationsverhaltens und Sicherung benötigter Einstellungen oder Daten.

Kompatibles PHP wählen, OPcache und Hosting prüfen

Verwenden Sie einen gepflegten PHP-Zweig, den Ihre genaue PrestaShop-Version, Ihr Theme und Ihre Module unterstützen. Die aktuelle PrestaShop-9-Matrix empfiehlt PHP 8.4 für 9.0 und PHP 8.5 für 9.1. Prüfen Sie auch die PHP-Wartungsfristen. Der Upstream-Support für PHP 8.1 endete am 31. Dezember 2025. Stellen Sie PrestaShop 1.7.8 nicht als pauschale Beschleunigung auf PHP 8 um.

Bestätigen Sie aktiven OPcache für Web-PHP, nicht nur für die Kommandozeilen-Binärdatei. Er speichert kompilierten Bytecode und vermeidet erneutes Parsen von PHP-Dateien bei wiederholten Anfragen. JIT ist eine separate Option; setzen Sie nicht voraus, dass es die Shopleistung erklärt oder aktiviert sein muss.

1. Prüfen Sie belegten/freien Speicher, internierte Zeichenfolgen, gecachte Skripte und Schlüssel unter repräsentativer Last.
2. Prüfen Sie cache_full, verschwendeten Speicher sowie Zähler für Neustarts wegen Speichermangel, Hash-Auslastung und manueller Auslösung über opcache_get_status(), soweit der Hoster dies erlaubt.
3. Dimensionieren Sie Speicher und Skriptkapazität anhand dieser Werte. Ein voller Cache kann keine weiteren Skripte aufnehmen und einen Neustart planen; er verdrängt nicht wie ein einfacher Cache ständig einzelne Einträge.
4. Dokumentieren Sie das Bereitstellungsverhalten. Bei opcache.validate_timestamps=1 folgt die Zeitstempelprüfung ihrer Konfiguration einschließlich opcache.revalidate_freq. Ohne Validierung benötigen geänderte Dateien explizite Invalidierung oder Zurücksetzen/Neustart des betreffenden Web-PHP-Caches.

Ein CLI-Reset leert normalerweise nicht den OPcache des Webservers. Sechzig Sekunden Warten ist kein allgemeingültiges Reset-Verfahren. Nutzen Sie die OPcache-Einstellungen und Statusfelder für eine kontrollierte Richtlinie und halten Sie Diagnoseendpunkte privat.

Prüfen Sie bei PHP-FPM ausgelastete Worker, Warteschlangen, pm.max_children, Worker-Speicher und Timeout-Protokolle. Mehr Worker können Speicherdruck oder Datenbankkonflikte verschärfen. Prüfen Sie zu Spitzenzeiten CPU-Last und Steal, Swapping, I/O-Wartezeiten und Datenbanklatenz. Werkzeuge wie free -m, vmstat 1 5 und iostat -xz 1 5 können Ihrem Administrator helfen, Symptome zu korrelieren.

Dimensionieren Sie Hosting nicht allein nach Bestellungen pro Tag. Gleichzeitige Katalogbesuche, Filter, Importe, Cronjobs, Varianten und Bestellarbeit zählen ebenfalls. Vergleichen Sie Ressourcennutzung und Antwortzeiten unter erwarteter Spitzenlast vor Hosterwechsel oder Kapazitätserhöhung. Siehe PrestaShop-Hosting.

Deuten die Nachweise auf Kapazitäts- oder Wiederherstellungsgrenzen hin, prüft das PrestaShop Hosting & Infrastructure Audit die Last und gibt eine schriftliche Einschätzung, ob der aktuelle Host verbessert oder gewechselt werden sollte; Serverarbeiten und die Migration selbst sind separate Leistungen. Wählen Sie den Migrationsweg anhand der bestehenden Module, Integrationen, des Themes und der Daten. Testen Sie bei einem Hostwechsel, der die aktuelle Einrichtung beibehält, eine isolierte Kopie auf dem neuen Host. Empfiehlt die Bewertung einen Neuaufbau des Shops, ist der übliche sichere Weg eine saubere Zielinstallation auf Staging, kompatible Komponenten und eine geprobte Datenmigration. Planen Sie die finale Datensynchronisierung und die Umstellung, und dokumentieren Sie, wie ein Rollback die nach dem Start eingegangenen Bestellungen erhalten würde.

Langsames SQL finden und EXPLAIN richtig lesen

Bitten Sie den Datenbankadministrator, zuerst die genaue Engine und Version festzuhalten: MySQL- und MariaDB-Einstellungen sind nicht austauschbar. Nutzen Sie vorhandenes Abfrage-Monitoring, wo es verfügbar ist. Aktivieren Sie andernfalls das Slow Query Log der Datenbank mit einem Schwellenwert, der anhand der Anfragezeiten und der Last gewählt wird. Ein kurzes Diagnosefenster könnte zum Beispiel so beginnen:

[mysqld]
slow_query_log = 1
long_query_time = 0.5

Lassen Sie den Datenbankadministrator ein zulässiges Protokollziel, eine Speichergrenze, Rotation, Zugriffskontrolle und ein Löschdatum festlegen. Abfragetexte können personenbezogene Daten enthalten. Erfassen Sie repräsentativen Traffic und geplante Aufgaben für den relevanten Spitzenzeitraum statt einer festen Dauer für jeden Shop, und beenden oder reduzieren Sie die detaillierte Protokollierung anschließend nach Bedarf. Abfragen ohne Indizes zu protokollieren und nach einer Mindestzahl untersuchter Zeilen zu filtern, kann helfen, aber auch Rauschen und zusätzliche Arbeit erzeugen oder relevante kleine Abfragen ausschließen; ein kleiner Tabellenscan ist nicht automatisch ein Fehler. Prüfen Sie das Protokollverhalten der Datenbank für Ihre Version.

Fassen Sie ein Protokoll mit mysqldumpslow oder pt-query-digest zusammen, wo diese Werkzeuge installiert sind und Ihr Protokollformat unterstützen. Ersetzen Sie den Pfad durch die tatsächliche Datei und speichern Sie Berichte an einem zugriffsbeschränkten Ort:

mysqldumpslow -s t -t 20 /path/to/slow-query.log
pt-query-digest /path/to/slow-query.log

Ordnen Sie nach Gesamtzeit, Aufrufzahl, untersuchten Zeilen und Sperrzeit sowie nach der langsamsten Einzelausführung: Eine wiederholte mäßige Abfrage kann über eine Seite oder einen Spitzenzeitraum hinweg mehr kosten als eine langsamere Einzelabfrage. Lesen Sie den Sortiermodus der Zusammenfassung, bevor Sie ihre Rangfolge deuten, denn eine nach durchschnittlicher Dauer sortierte Liste beantwortet eine andere Frage als eine nach kumulierter Zeit sortierte. Erfassen Sie vor dem Tuning die genaue Abfrage, ihre Parameter, das Datenvolumen und den Shopkontext, und schwärzen Sie Berichte, bevor Sie sie weitergeben.

Der Erfassungsschwellenwert verbirgt auch Arbeit: Wiederholte Abfragen unterhalb davon können fehlen, selbst wenn ihre gemeinsamen Kosten ins Gewicht fallen. So können Bewertungsabfragen einzeln unter dem Schwellenwert bleiben, aber für jede Produktkarte erneut laufen, während ein geplanter Export eine einzelne langsame Abfrage beiträgt, die mit dieser Seite nichts zu tun hat. Setzen Sie die langsame Anfrage mit dem Anwendungsprofiling in Beziehung, mit einer begrenzten Erfassung statt uneingeschränkter Protokollierung, und ordnen Sie beide Muster ihren Aufrufern zu, bevor Sie entscheiden, welche Änderung die Anfrage des Kunden verbessert.

Verwenden Sie die tatsächliche Abfrage aus der langsamen Anfrage mit ihrem Shop-, Sprach- und Kundenkontext und prüfen Sie ihren Plan auf einer Staging-Kopie mit repräsentativen Daten. Dieses lesende Kategoriebeispiel verwendet das Standardpräfix, Shop 1, Sprache 1 und Kategorie 42. Es zeigt die Form, nicht die Abfrage, die Ihr installiertes Listen- oder Filtermodul erzeugt. Es liest shopspezifischen Preis und Status aus product_shop und grenzt übersetzte Daten auf denselben Shop ein:

EXPLAIN SELECT p.id_product, pl.name, ps.price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
JOIN ps_product_lang pl ON pl.id_product = p.id_product
  AND pl.id_shop = ps.id_shop
JOIN ps_category_product cp ON cp.id_product = p.id_product
WHERE ps.id_shop = 1 AND pl.id_lang = 1
  AND cp.id_category = 42 AND ps.active = 1
ORDER BY ps.date_add DESC;

Ein gewöhnliches EXPLAIN schätzt einen Plan, ohne die Abfrage auszuführen. Ausführungsbasierte Analysebefehle können sie ausführen; prüfen Sie das Verhalten des Befehls für Ihre Engine und Version, bevor Sie ihn nutzen.

Prüfen Sie vorhandene Indizes, bevor Sie einen hinzufügen. Wählen Sie die Spaltenreihenfolge eines zusammengesetzten Index nach Gleichheitsbedingungen, Bereichen, Sortierung und Wiederverwendung des linken Präfixes. „Selektivste Spalte zuerst“ ist keine allgemeingültige Regel. Zusätzliche Indizes belegen Speicherplatz und verursachen Schreibaufwand; wägen Sie daher den Lesegewinn gegen die Schreibkosten ab. Testen Sie Schemaänderungen auf Staging, proben Sie sowohl Einrichtung als auch Rücknahme, und planen Sie Sperren und temporären Speicherplatz ein.

Eine Bewertungstabelle, die nach Produkt, Freigabestatus und Anzeigereihenfolge abgefragt wird, zeigt, warum das Indexdesign das gesamte Zugriffsmuster braucht. Ein Index, der zu dieser Abfrage im Shop passt, eignet sich womöglich nicht für eine Verwaltungsliste, die nach Shop gefiltert wird. Verlangen Sie gemessene Pläne für beide sowie die Auswirkung auf Bewertungsimporte und Schreibvorgänge der Moderation, bevor Sie den Index freigeben.

Untersuchungsbeispiel: eine langsame gefilterte Kategorie

1. Speichern Sie ausgewählte Filter, Sortierung, Shop, Sprache, Währung und Kundenstatus. Reproduzieren Sie die ungecachte Anfrage mit repräsentativen Staging-Daten.
2. Ermitteln Sie die Abfragen für Produktauswahl, Facettenanzahlen, Preisberechnung und Modulerweiterungen. Trennen Sie wiederholte Aufrufe von einzeln aufwendigen Abfragen.
3. Prüfen Sie die tatsächlichen Joins, Einschränkungen, vorhandenen Indizes und den Plan des teuren Musters. Das Kategoriebeispiel oben zeigt nur die Syntax; in diesem Fall entscheiden die eigenen Abfragen des Filtermoduls.
4. Schlagen Sie eine Änderung an dieser Abfrage, einen möglichen Index oder eine Änderung an der wiederholten Arbeit des verantwortlichen Moduls vor. Proben Sie diese mit dem bereits vorbereiteten passenden Backup und Rollback-Plan.
5. Wiederholen Sie dieselben Filter- und Sortieraktionen. Vergleichen Sie Anfragedauer, Abfragehäufigkeit und Pläne und prüfen Sie anschließend Produktergebnisse, Facettenanzahlen und Kundenpreise.

Preisberechnung, Facetten und wiederholte Abfragen untersuchen

Spezifische Preise und Warenkorbregeln

Die Auswahl spezifischer Preise hängt von Produkt, Variante, Shop, Währung, Land, Gruppe, Kunde, Warenkorb, Menge und Zeitraum ab, mit Prioritäts- und Reihenfolgeregeln. Eine Mengenstaffel muss für die angefragte Menge gelten; from_quantity >= 1 ist kein korrekter Auswahltest. Maskieren Sie die reservierten Datumsspalten in Diagnose-SQL als `from` und `to`. Profilieren Sie den nativen Preisaufruf, statt seine Auswahl durch eine unvollständige Abfrage zu ersetzen, und übernehmen Sie keine Preisabfrage und keinen Index aus einem anderen Shop ins Produktivsystem: Ein unvollständiges Beispiel kann ein falsches geschäftliches Ergebnis liefern.

Prüfen Sie inaktive oder abgelaufene Aktionen gemäß Ihrer Geschäftspolitik. Relevante Core-Abfragen für Warenkorbregeln filtern bereits Aktivstatus und Datum. Deaktivierung und vergangenes Enddatum sind daher nicht beide erforderlich, um eine Regel auszuschließen. Erhalten Sie für Bestellungen, Berichte oder gültige Kampagnen benötigte Regeln.

Messen Sie die Regelauswertung mit repräsentativen Warenkörben. Lassen Sie sich vor dem Zusammenlegen sich überschneidender Regeln vom Händler die beabsichtigten Kombinationen und das Ablaufverhalten bestätigen, und testen Sie dann Rabatte und Summen mit berechtigten und nicht berechtigten Warenkörben erneut.

Facettenzahlen und Suche

Profilieren Sie die installierte Facettensuche und ihre tatsächlichen Zählabfragen. Schließen Sie nicht auf eine Abfrage je möglichem Filterwert. Vergleichen Sie die angeforderten Zählungen mit den Filtern, die Kunden tatsächlich nutzen, und testen Sie, ob weniger ungenutzte Facetten, ein korrigierter Index oder der eigene Cache der Integration helfen. Wer einen nützlichen Filter nur für einen besseren Benchmark entfernt, verändert den Kaufweg.

Nutzen Sie bei erforderlichem Neuaufbau die unterstützte Indexierungsfunktion. PrestaShop 9.1 ergänzte einen Suchbefehl mit Optionen für vollständigen Neuaufbau und Shopbegrenzung:

php bin/console prestashop:search:index --full --shop-id=1

Prüfen Sie die installierte Befehlshilfe vor Nutzung in anderen Versionen. Für Versionen ohne diesen Befehl ist die Suchindexierung im Backoffice die Alternative. Ein externes Suchsystem kann weiterhin native Verbraucher oder Rückfallwege haben; leeren Sie native Suchtabellen nicht bloß wegen einer anderen installierten Suchmaschine.

N+1-Arbeit

Ein Listen-Hook, der Bewertungen für jedes Produkt einzeln abfragt, wiederholt mit wachsendem Ergebnis Arbeit. Sammeln Sie, soweit die Funktion es erlaubt, Produkt-IDs, laden Sie aggregierte Daten mit einer korrekt eingegrenzten Abfrage und verwenden Sie sie beim Rendering wieder. Berücksichtigen Sie Shopzugehörigkeit und Sichtbarkeit, validieren Sie IDs und behandeln Sie leere Listen. Vergleichen Sie Ausgabe und Abfragezahl.

Verlangen Sie einen Vorschlag zur Bündelung, der erklärt, wie die Produkt-IDs der Liste gesammelt werden, wie der Anzeige-Hook die Ergebnisse wiederverwendet und warum diese Wiederverwendung keine Shops oder kundenspezifischen Werte vermischen kann. Prüfen Sie den genauen Hook und die verfügbaren Produktdaten für das installierte Modul und seine Version. Belassen Sie die Korrektur im verantwortlichen Modul oder in seinen unterstützten Erweiterungspunkten, damit sie Updates übersteht. Eine Anzahl von Produkten, Regeln oder installierten Modulen ist kein automatischer Anlass zum Löschen oder Ersetzen.

Vergleichen Sie bei Arbeit mit externen APIs zuerst die Datenbankzeit mit den Wartezeiten der externen API: Ein langsamer Lieferanten- oder ERP-Aufruf braucht eine andere Korrektur als ein fehlender Index. Halten Sie Timeout- und Fehlerverhalten fest. Cachen und aktualisieren Sie Daten außerhalb der Besucheranfrage, wenn ihre Aktualitätsanforderungen das zulassen. Versandtarife im Bestellprozess, Bestands- oder Zahlungsprüfungen können aktuelle Daten erfordern; entfernen Sie notwendige Echtzeitprüfungen daher nicht nur für einen besseren Benchmark.

Datenbankspeicher und Datenpersistenz anhand von Messungen abstimmen

Der InnoDB Buffer Pool speichert Daten- und Indexseiten im Cache. Dimensionieren Sie ihn gemeinsam mit Betriebssystem, PHP-Workern, Redis und den Puffern der Datenbankverbindungen: Ein größerer Pool kann dem Shop schaden, wenn der übrige Server anfängt auszulagern. Ein eigener Datenbankhost und ein kombinierter Web-/Datenbankhost brauchen unterschiedliche Budgets, keinen festen Prozentsatz des installierten Arbeitsspeichers. Die Datenbankgröße allein beweist nicht, dass der aktive Arbeitsbestand hineinpasst.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Nehmen Sie zwei Stichproben über einen repräsentativen Zeitraum. Verwenden Sie für die kumulativen Zähler der Buffer-Pool-Lesevorgänge, langsamen Abfragen und temporären Tabellen die Differenzen zwischen den Stichproben. Lesen Sie Threads_connected als aktuelle Verbindungsanzahl und Max_used_connections als höchste gleichzeitige Anzahl seit dem Start oder dem relevanten Zurücksetzen; ihre Differenzen messen keine Verbindungslast. Ist die Änderung der Leseanfragen ungleich null, gilt hit_ratio_percent = (1 - delta_reads / delta_read_requests) * 100, wobei delta_reads die Änderung von Innodb_buffer_pool_reads und delta_read_requests die Änderung von Innodb_buffer_pool_read_requests ist. Verwerfen Sie Zeiträume, die einen Serverneustart oder ein Zurücksetzen der Zähler umfassen, und vergleichen Sie gleichwertige Lasten statt Summen, die seit unterschiedlichen Neustartzeitpunkten gesammelt wurden. Eine hohe Quote kann neben teuren Abfragen bestehen, und eine niedrigere Quote rechtfertigt nicht automatisch mehr RAM. Setzen Sie physische Lesevorgänge, Datenträgerlatenz und Speicherdruck in Beziehung; ein größerer Cache kann wiederholte Lesevorgänge verbessern, ohne einen lang laufenden Schreibvorgang oder eine Sperrwartezeit zu beheben.

Behalten Sie innodb_flush_log_at_trx_commit=1 als normale dauerhafte Einstellung bei. Mit dem Wert 2 können nach einem Absturz des Betriebssystems oder einem Stromausfall kürzlich bestätigte Transaktionen verloren gehen. Tauschen Sie die Dauerhaftigkeit von Bestellungen nicht gegen einen ungemessenen Tuning-Gewinn; jeder Vorschlag, das Schreiben beim Commit abzuschwächen, braucht eine ausdrückliche geschäftliche Entscheidung über Datenverlust und Wiederherstellung.

Verwenden Sie versionsspezifische Konfiguration. MySQL 8 hat den Query Cache entfernt. MariaDB behält eine eigene Implementierung, doch testen Sie Konflikte und den Nutzen für Ihre Last, bevor Sie ihn aktivieren, und wechseln Sie die Engine nicht allein wegen der Geschwindigkeit. MariaDB 10.6 hat innodb_buffer_pool_instances entfernt. MySQL 8.0.30 führte innodb_redo_log_capacity anstelle der älteren Praxis zur Redo-Größenbestimmung ein; nutzen Sie die aktuelle Redo-Log-Dokumentation und die von Ihrem Server unterstützten Variablen.

Übernehmen Sie keine universellen Größen für I/O-Threads, Verbindungen, Sortierpuffer oder temporäre Tabellen auf jeden Server. Zuweisungen pro Verbindung und Parallelität können den Arbeitsspeicher erschöpfen, und wer Puffer und Verbindungsgrenzen gemeinsam erhöht, vervielfacht dieses Risiko unter Last. Lassen Sie das Performance Schema für die Diagnose verfügbar, sofern keine gemessenen Einschränkungen eine Änderung rechtfertigen; stimmen Sie die Instrumentierung ab, statt sie als pauschale Produktivregel zu deaktivieren. Nutzen Sie seine Monitoring-Abfragen nur, wenn die erforderliche Instrumentierung verfügbar ist. Prüfen Sie Table_locks_waited zusammen mit enginespezifischer Sperrdiagnose; der Wert ist kein vollständiges Maß für Wartezeiten auf InnoDB-Zeilensperren.

Fragen Sie den Hoster bei jeder vorgeschlagenen Änderung nach der aktuellen Einstellung, der gemessenen Einschränkung, dem vorgeschlagenen Wert, dem erwarteten Nutzen und dem Verfahren zur Rücknahme. Auf einem Server, der mit PHP geteilt wird, muss eine Vergrößerung des Buffer Pools Platz für ausgelastete PHP-Worker und Importe lassen. Auf einem eigenen Datenbankhost zählen Datenträgerlatenz, gleichzeitige Verbindungen und Backupaufgaben weiterhin.

Tabellen nur nach vereinbarter Aufbewahrungsrichtlinie bereinigen

Messen Sie Tabellenwachstum und Aufbewahrung getrennt vom Abfrage-Tuning, und betrachten Sie das Wachstum zusammen mit den tatsächlichen Abfragekosten und der Backupgröße. Besucheraktivität und Warenkorberstellung hängen von aktivierten Funktionen und vom Verhalten ab. Einige spezifische Bereinigungswege gibt es bereits, darunter die Bereinigung von Verbindungsseiten. Nutzen Sie den Leitfaden zur Datenbankwartung für eine abhängigkeitsbewusste Aufbewahrung von Warenkörben, Gästen und Protokollen.

Alte Besuchsdaten, Suchanfragen, Mailprotokolle, verlassene Warenkörbe und abgelaufene Preisregeln können Kandidaten sein, doch prüfen Sie zuerst Abhängigkeiten von Berichtswesen, Support, Warenkorbrückgewinnung und Integrationen, und vereinbaren Sie mit den Personen, die diese Datensätze nutzen, was aufbewahrt wird. Ein alter Warenkorb ohne Bestellung ist nicht automatisch gefahrlos löschbar. Aufbewahrung ist eine geschäftliche Entscheidung, keine allgemeingültige Zahl von Tagen.

Mit Backups, einem getesteten Staging-Lauf und einem vorbereiteten Rollback bietet Database Cleanup auswählbare Bereiche, Aufbewahrungsfristen, eine Zeilenvorschau und eine Simulation vor dem Entfernen. Es lässt Bestellungen, Kundenkonten, aktive Produkte und Warenkörbe, die zu Bestellungen gehören, unangetastet und beschränkt die Bereinigung im Multistore auf die ausgewählten Shops. Umfasst das Problem auch verwaiste Bilder und ungenutzte Dateien, ergänzt Cleanup Revolution diese Bereiche, Bereinigungen mit Vorschau, Aufbewahrungseinstellungen und eine Zeilenobergrenze je Lauf. Entfernte Bilder bleiben für einen gewählten Zeitraum in einem datierten Papierkorb wiederherstellbar, was kein Wiederherstellungsversprechen für jeden gelöschten Datensatz ist, und Konten ohne Bestellungen erfordern eine separate doppelte Bestätigung. Wählen Sie das Werkzeug nach dem Wartungsumfang, statt standardmäßig beide zu installieren.

Prüfen Sie die genauen Kandidaten in der Vorschau, geben Sie einen kontrollierten ersten Durchlauf frei und prüfen Sie dann das Verhalten im Shop, die Kandidatenzahlen und den Laufverlauf, bevor Sie weitere Läufe planen. Die geschützten Bereiche eines Bereinigungswerkzeugs ersetzen nicht Ihr eigenes Backup. InnoDB kann gelöschten Platz wiederverwenden, doch das Löschen von Zeilen gibt nicht unbedingt Speicherplatz an das Betriebssystem zurück, und der Neuaufbau einer Tabelle kann zusätzlichen Platz und Sperren erfordern. Ein routinemäßiges OPTIMIZE TABLE nach jeder Bereinigung ist unnötig, und das Leeren des Suchindex ist keine Aufräumarbeit; muss die Suche neu aufgebaut werden, nutzen Sie die unterstützte Indexierungsfunktion Ihrer Version.

Aufwand für Bilder, Stylesheets und JavaScript reduzieren

Prüfen Sie das tatsächliche LCP-Element und die Anfragekette. Stimmen Sie erzeugte Bildgrößen auf Darstellungsgröße, Pixeldichte und Zoombedarf ab. Es gibt keine universelle Quellbildgrenze oder garantierte Formateinsparung. Reservieren Sie Bildabmessungen gegen Verschiebungen, laden Sie sichtbare prioritäre Bilder zügig und verzögern Sie geeignete Bilder außerhalb des Sichtbereichs.

Generieren Sie betroffene Vorschaubilder nach Bildtypänderungen neu. Sichern Sie zuvor die Bilder. In PrestaShop 9.1+ entfernt php bin/console prestashop:thumbnails:regenerate products --delete bestehende Produktvorschaubilder vor dem Neuaufbau. Führen Sie große Neuaufbauten außerhalb der Spitzenzeiten aus. Lassen Sie zur Fortsetzung eines unterbrochenen Laufs --delete weg, damit vorhandene Ausgaben erhalten und fehlende Dateien erzeugt werden. Ältere Versionen benötigen ihr unterstütztes Backoffice-Werkzeug oder ein separat bereitgestelltes Tool. WebP-Speicherung begann mit 8.0; Mehrformaterzeugung einschließlich AVIF kam in 8.1 experimentell hinzu. Bestätigen Sie Server- und Theme-Unterstützung und prüfen Sie das im Browser gelieferte Format. Siehe Bildoptimierung.

Critical CSS umfasst die für den anfänglichen Sichtbereich benötigten Stile. Erzeugen Sie es für repräsentative Seiten und responsive Zustände, betten Sie den validierten Teil direkt ein und laden Sie übriges CSS passend. Erhalten Sie Rückfallstile und testen Sie Menüs, Einwilligungsbanner, Sprachvarianten und dynamisch eingefügte Inhalte. Unvollständige Extraktion kann Aufblitzen, Verschiebungen oder fehlende Bedienelemente verursachen.

Reduzieren Sie ungenutztes CSS und JavaScript anhand von Messungen aller benötigten Zustände. Coverage eines einzigen anfänglichen Sichtbereichs beweist nicht, dass ein Selektor gefahrlos entfernbar ist. Vergleichen Sie bei geringem Zusatznutzen einen Slider mit einem statischen Titelbild und testen Sie das tatsächliche Ergebnis.

Bei klassischen externen Skripten verschiebt defer die Ausführung bis zum Ende des Parsens und erhält die Reihenfolge verzögerter Skripte; async dient unabhängigen Aufgaben mit variabler Abschlussreihenfolge. Keine Option beseitigt Ausführungskosten. PrestaShops JavaScript-Registrierungsoption steht im Plural:

['position' => 'bottom', 'priority' => 200, 'attributes' => 'defer']

Übergeben Sie diese Optionen beim Registrieren einer eigenen Ressource an registerJavascript(). Registrieren Sie sie nur auf benötigten Seiten. Testen Sie nach Reihenfolge- oder Zeitänderungen Abhängigkeiten und alle betroffenen Interaktionen. Fassen Sie doppelte Tracker zusammen und steuern Sie nicht notwendige Dienste korrekt.

Schriften, Symbole und Theme prüfen

1. Filtern Sie bei deaktiviertem Browsercache das Netzwerk nach Font. Erfassen Sie Dateien, Übertragungsgrößen und auslösende Stylesheets.
2. Prüfen Sie berechnete Stile und Coverage über Seitentypen und Interaktionen, um verwendete Familien, Stärken, Stile und Symbole zu erkennen.
3. Durchsuchen Sie registrierte Ressourcen, CSS-Importe und Templates des aktiven Themes. Classic-basierte Themes nutzen normalerweise templates/_partials/head.tpl; individuelle Themes können abweichen.
4. Entfernen Sie unnötige Ressourcen über die gepflegte Theme-Quelle oder ein Child-Theme. Prüfen Sie alle unterstützten Sprachen, Währungssymbole und dynamischen Inhalte.

Classic und Hummingbird enthalten Material-Icons-Schriftdefinitionen. Prüfen Sie das gelieferte CSS, bevor Sie bei einem Theme den Verzicht auf Symbolschriften annehmen. Prüfen Sie die genaue Version und von Modulen ergänzte Bibliotheken. Teilmengen oder ausgewählte SVG-Symbole können ungenutzte Ressourcen reduzieren; erhalten Sie benötigte Zeichen und barrierefreie Beschriftungen.

Fordern Sie nur verwendete Schriftstärken und Zeichen an. WOFF2 und gezielte Teilmengen können Übertragungen verringern; Einsparungen hängen von Schrift und Sprachen ab. Ein Systemschrift-Stack vermeidet zusätzliche Webfont-Downloads. Beispiel:

font-family: system-ui, -apple-system, "Segoe UI", sans-serif;

Wählen Sie für behaltene Schriften eine passende font-display-Richtlinie. swap zeigt während des Ladens Ersatztext, doch Metriken können sich ändern und Verschiebungen erzeugen. Stimmen Sie Ersatzmetriken möglichst ab und testen Sie das Layout. Fordern Sie für Google Fonts bei Bedarf display=swap explizit an und prüfen Sie das gelieferte CSS; es gilt nicht allgemein für jede API-URL. Siehe den Fonts-API-Leitfaden.

Selbst gehostete lizenzierte Schriftdateien vermeiden die Schriftanfrage an den externen Anbieter und können Ihre Origin-Verbindung wiederverwenden. Externes Laden benötigt weiterhin eine angemessene Datenschutzbewertung. Im Münchner Google-Fonts-Fall vom Januar 2022 wurden EUR 100 zivilrechtlicher Schadenersatz zugesprochen, keine behördliche Geldbuße, gemäß der Erläuterung der niedersächsischen Aufsichtsbehörde.

Verwenden Sie für Theme-Vergleiche dieselben Staging-Daten und Einstellungen, ein kompatibles Standardtheme und dokumentierte Cache-Zustände. Ein Theme-Wechsel verändert auch Funktionen und Moduldarstellung; der Unterschied ist ein Experiment, keine exakte Aufteilung aller Theme-Kosten. Deaktivieren Sie einzelne Effekte, Schriften oder Komponenten zur weiteren Eingrenzung. Bewahren Sie gepflegte Änderungen gegebenenfalls in einem Child-Theme auf.

Prüfen Sie in einer Performance-Aufzeichnung lange JavaScript-Aufgaben und deren Aufrufstapel. Nutzen Sie Layout-/Recalculate-Style-Ereignisse und Forced-Reflow-Diagnosen für wiederholte Layoutneuberechnung. Rote Markierungen allein belegen sie nicht. Nutzen Sie die DevTools-Performance-Referenz zur Interpretation der Aufzeichnung.

Tatsächliche Ausführung und Ressourcen der Module prüfen

Erstellen Sie je Seite ein Inventar von Modul-CSS/-JS, übertragener und dekodierter Größe, Anfragen, Datenbankaufrufen, Serverausführung und ressourcenabhängigen Widgets. Hook-Registrierungen oder Modulzahl allein sagen nichts über die Kosten.

Im Einzelshop-Kontext zeigt Design → Positionen Hook-Registrierungen. Aktivieren Sie Nicht positionierbare Hooks anzeigen für Aktions-Hooks wie actionFrontControllerSetMedia neben Anzeige-Hooks wie displayHeader. Der Core unterstützt Controller-Ausnahmen für Hook-Registrierungen; Module können Ressourcen bedingt registrieren. Ein Hook ohne sichtbares HTML kann dennoch erforderliche Initialisierung ausführen.

Ein Netzwerkfilter nach /modules/ ist ein nützlicher Einstieg. Er übersieht über CCC oder Theme gebündelte, externe und dynamisch erzeugte Dateien. Verfolgen Sie Auslöser und Bundle-Inhalte; deaktivieren Sie CCC bei Bedarf für einen Diagnoselauf vorübergehend auf Staging.

1. Finden Sie teure Ressourcen und Serveraufrufe auf der langsamen Seite.
2. Prüfen Sie den Einsatzort ihrer Funktionen. Bewertungen und Wunschlisten-Schaltflächen können auf Kategorielisten berechtigt Ressourcen benötigen.
3. Blockieren Sie für ein Browserexperiment eine eng abgegrenzte Ressourcen-URL und prüfen Sie anschließend Fehlfunktionen. Das Blockieren der gemeinsamen Shopdomain isoliert kein Modul.
4. Deaktivieren Sie ein verdächtiges Modul auf Staging und wiederholen Sie dieselben Tests. Browserblockierung entfernt keine serverseitige Hook-Arbeit; ein Deaktivierungsexperiment ändert auch das Seitenverhalten.
5. Bevorzugen Sie korrigierte bedingte Registrierung im Modul. Nutzen Sie Hook-Ausnahmen oder Ab-/Neuregistrierung erst nach Prüfung von Abhängigkeiten und Initialisierung.
6. Prüfen Sie Produkt-, Kategorie-, Konto-, Warenkorb-, Bestell-, Einwilligungs- und mobile Interaktionen erneut.

Erhalten Sie nützliche Funktionen und reduzieren Sie deren unnötige Arbeit. Es gibt weder ein allgemeines Zehn-Millisekunden-Budget pro Modul noch eine feste prozentuale Einsparung durch eine Prüfung.

Cache-Ebene wählen, Eignung und Invalidierung testen

Ergänzen Sie Caching dort, wo Messungen wiederholte Arbeit zeigen, die sich sicher wiederverwenden lässt. Ein neuer Cache verändert die Last; er erspart Ihnen nicht, weiter zu messen und einen gesunden ungecachten Pfad zu erhalten.

Redis-Integration

Installieren Sie einen echten Redis-Dienst, erforderliche PHP-Unterstützung und den Adapter für den beabsichtigten Cache-Pfad. Die Einstellung ps_caching muss einen installierten Anwendungs-Cache-Adapter benennen; sie konfiguriert keine Sitzungsspeicherung. Ein mit Performance Revolution verwendeter eigener Adapter heißt MPRCacheRedis; nutzen Sie das unterstützte Installationsverfahren der Implementierung.

Konfigurieren Sie PHP- oder Symfony-Sitzungsspeicherung separat einschließlich Sperr- und Fehlerrichtlinie. Kundencookies und PHP-Sitzungen sind unterschiedliche Mechanismen; ein Wechsel zu Redis beseitigt Sperren nicht grundsätzlich.

Die Schreib-APIs der Core-Datenbank können bei aktiviertem Caching die Invalidierung des Adapters aufrufen. Direktes SQL, externe Importe und modulgesteuerte Caches können anderen Wegen folgen. Testen Sie Aktualisierungen von Preisen, Bestand, Produkten, Kategorien und Konfiguration über jeden Schreibweg, den Sie nutzen. Redis selbst weiß nicht, welche PrestaShop-Seiten oder Abfrageergebnisse veraltet sind. Testen Sie außerdem Ablauf, gleichzeitige Anfragen und das Verhalten bei einem Ausfall des Redis-Dienstes.

Die Hilfeseite zu Redis Cache Manager & Monitor behandelt Verbindungsprüfungen, Schlüsselverwaltung und separate Schalter für gespeicherte Daten, Sitzungen und Gastseiten. Ein funktionierender Redis-Dienst ist erforderlich; testen Sie jede aktivierte Integration, die Invalidierung und das Fehlerverhalten auf Staging.

Ganzseiten-Caching

Ein Erstbesucher mit kaltem Browser kann einen Treffer aus einem warmen gemeinsamen Seitencache erhalten. Geeignete Treffer können teure Datenbankarbeit vermeiden und TTFB reduzieren, selbst bei langsamem zugrunde liegendem Abfragepfad. Fehltreffer und ausgeschlossene/private Anfragen brauchen weiterhin eine gesunde Anwendung.

Ein Anwendungsmodul führt auf seinem Cache-Pfad weiterhin PHP aus. Ein korrekt konfigurierter externer Reverse-Proxy- oder FastCGI-Cache kann PHP bei Treffern umgehen. Behandeln Sie deren Zeiten als unterschiedliche Messungen. Definieren Sie eine explizite Eignungsrichtlinie für Anfragemethode, aufgelösten Controller, Abfrageparameter, Host/Shop, Sprache, Währung und jeden Faktor öffentlicher Ausgabe.

Umgehen Sie den Cache für Warenkorb, Bestellprozess, Konto, Anmeldung, Backoffice, API, AJAX und personalisierte Antworten, sofern kein eigens entworfener Isolierungsmechanismus greift. Beachten Sie private/no-store-Antworten und Cookie-Setzung. Eine Sperrliste englischer URL-Fragmente übersieht übersetzte Pfade und Controller in Abfrageparametern.

Testen Sie mit zwei Browsern und verschiedenen Kundenzuständen. Prüfen Sie Cache-Schlüssel, Einwilligungsvarianten und dass private Inhalte niemals zwischen Besuchern übergehen. Testen Sie Invalidierung bei Produkt-, Preis-, Bestands- und Kategorieänderungen, Aktionsbeginn/-ende und externen Importen. Eine TTL erlaubt bewusst veraltete Daten und ist keine vollständige Invalidierung.

Tagbasiertes Leeren und dynamische Fragmente können helfen, wenn sie implementiert sind. ESI, Browser-Hydration und PHP-Platzhalterersetzung sind unterschiedliche Techniken. Zu unterstütztem Anwendungs-Caching, serverseitigen Platzhaltern, Critical-CSS-Zielen und Profiling-Abdeckung siehe die Hilfeseite zu Performance Revolution. Das Modul misst außerdem die realen Seitengeschwindigkeiten Ihrer Kunden und kann geeignete öffentliche Seiten über optionales Cloudflare ausliefern; die öffentlichen Kopien variieren nach Sprache, Währung, Land und Gerät, und betroffene Seiten werden erneuert, wenn sich Preise oder Bestand ändern. Warenkörbe, Bestellprozess, Konten und angemeldete Besuche nutzen den Live-Shop. Prüfen Sie auf Staging, ob es zu Ihrem bestehenden Cache, Theme und Ihren individuellen Integrationen passt.

Checkliste zur Cache-Abnahme

• Wärmen Sie eine geeignete öffentliche Produktseite auf und ändern Sie dann Preis und Bestand über die normalen Aktualisierungswege des Shops, einschließlich ERP- oder Massenimporten, sofern genutzt. Prüfen Sie, wann sich die öffentliche Kopie aktualisiert.
• Wechseln Sie Sprache, Währung und Zielland. Testen Sie Kundengruppenpreise und individuelle Preisanzeigen. Schließen Sie Seiten oder Kontexte aus, deren korrekte Variantenbildung nicht sicher nachgewiesen werden kann.
• Legen Sie etwas in den Warenkorb, melden Sie sich an und öffnen Sie Konto- und Kassenseiten. Prüfen Sie, dass persönliche Inhalte für jeden Besucher stimmen und private Antworten nicht wiederverwendet werden.
• Proben Sie auf Staging Ablauf, gleichzeitige Cache-Fehltreffer und einen Ausfall des Cache-Dienstes. Bestätigen Sie, dass der Rückfallweg korrekt bleibt und die Erholung den Ursprungsserver nicht überlastet.
• Dokumentieren Sie, welche Schicht für jede gecachte Antwort zuständig ist und wie sie invalidiert wird. Bestätigen Sie, dass kein weiterer Proxy und kein CDN nach Aktualisierung des Anwendungscaches eine Kopie behalten kann.

Statisches Caching und Aufwärmen

Frische Browsercache-Einträge können einen Netzwerkumlauf vermeiden. ETag-Validierung sendet normalerweise eine bedingte Anfrage. Nutzen Sie lange Gültigkeitsdauern nur mit einer passenden Bereitstellungsstrategie für versionierte Ressourcen; serverseitiges Leeren entfernt nicht die bereits gespeicherten Dateien aus den Browsercaches aller Besucher. Ein CDN kann öffentliche Ressourcen nahe am Besucher liefern; prüfen Sie TLS, CORS für Schriften, Cache-Header und Invalidierung.

Leeren Sie nur betroffene Ebenen über unterstützte Werkzeuge. Wärmen Sie wichtige geeignete Seiten nach Bereitstellungen mit begrenzter Parallelität und Last auf. Nehmen Sie nicht an, dass aktiviertes Rendering-Caching kompilierte Template-PHP-Dateien nach Redis verschiebt. Origin- und CDN-Edge-Aufwärmen sind getrennte Arbeiten, die Last hinzufügen können. Vergleichen Sie bewusst kalte und warme Läufe, statt Unterschiede zu verdecken.

Der Leitfaden zu Ganzseiten-Cache, Redis und CDN behandelt diese Ebenen ausführlicher.

Varianten und langsames Backoffice bearbeiten

Katalogkapazität hängt neben Produktzahl von Varianten, Zuordnungen, Bildern, Merkmalen, Filtern, Preisen und Importen ab. Es gibt keine einzelne praktische Produktzahlgrenze für jeden Shop. Testen Sie Last auf einer Staging-Kopie mit realistischen Daten und Traffic.

Sechs Größen, acht Farben und fünf Ausführungen ergeben bei vollständiger Erzeugung 240 Varianten. Prüfen Sie die größten Gruppen mit diesen lesenden Abfragen und ersetzen Sie bei Bedarf das Standardpräfix:

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
ORDER BY combinations DESC
LIMIT 20;

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC
LIMIT 20;

Die Bestandszeilenabfrage zählt gespeicherte Zeilen über deren Geltungsbereiche; sie ergibt keinen shopisolierten Gesamtbestand. Berücksichtigen Sie bei der Interpretation Shop-/Gruppenzugehörigkeit.

Entfernen Sie unmögliche Varianten, reduzieren Sie unnötige Dimensionen oder teilen Sie ein sehr großes Produkt, wenn das zum Kaufverhalten passt. Optionen ohne eigenen Bestand oder Preis lassen sich eventuell besser über Produktanpassungen oder einen Konfigurator umsetzen. Prüfen Sie vor Modelländerungen Folgen für URLs, Bilder, Preise und Bestand.

Große Formulare und Importe können Grenzen von max_input_vars, post_max_size, Speicher oder Anfragezeit erreichen. Verarbeiten Sie Bestandsabgleich und Importe in Chargen und bauen Sie nach wesentlichen Änderungen betroffene Such-/Facettenindizes mit unterstützten Werkzeugen neu auf.

Profilieren Sie Verwaltungsseiten separat. Ist nur das Dashboard langsam, testen Sie Statistiken, Feeds und optionale Widgets. Ist der Module Manager langsam, prüfen Sie Metadaten- und externe Dienstanfragen. Marketplace-Integrationen hängen von Version und Installation ab; seit Version 8 wird Marketplace nicht mehr mit dem Open-Source-Projekt gebündelt.

Sind Front- und Backoffice langsam, prüfen Sie gemeinsame PHP-, Datenbank- und Hostingressourcen. Das Symptom beweist keine aufgeblähte Datenbank. Prüfen Sie beschreibbare Cache-Verzeichnisse, wiederholte Neuaufbauten, OPcache, Worker-Warteschlangen, Datenbanklatenz und relevante Modul-Hooks vor dem Entfernen von Daten.

Betrieb nach gemessener Last skalieren

Verfolgen Sie Infrastruktur, Bestandsgenauigkeit und Mitarbeiteraufwand getrennt. Die monatliche Bestellzahl bestimmt weder Hostingtarif noch Pflicht zum Ganzseiten-Cache. Traffic-Bestell-Verhältnisse und gleichzeitige Lastspitzen variieren.

Messen Sie wiederkehrende Aufgaben: Statusbearbeitung, Kommissionierung, Versand, Kundennachrichten, Retouren und Buchhaltungsexporte. Als Planungsbeispiel benötigen 100 monatliche Bestellungen zu je sechs Minuten zehn Arbeitsstunden pro Monat. Nutzen Sie eigene gemessene Zeiten einschließlich Ausnahmebehandlung, bevor Sie Automatisierungen wählen.

Halten Sie den nativen Bestellstatus, Kundenbenachrichtigungen und den internen Workflow-Status eines Moduls auseinander. Advanced Order Fulfilment kann Ereignisse mit eigenen Workflow-Schritten, Teams und Erinnerungen verknüpfen; prüfen Sie native Statusübergänge und Versand-E-Mails an Kunden separat.

Nutzen Sie den nativen Kundenservice-Ablauf für die Nachrichten, die er tatsächlich empfängt. Ein separates Formularmodul kann eigene Einsendungen und Benachrichtigungen speichern; prüfen Sie daher jede Helpdesk-Integration. Für eine formularspezifische Weiterleitung siehe die Hilfeseite zu Better Contact Form.

Gleichen Sie Bestand über Bestellungen, Retouren und weitere Verkaufskanäle ab. Prüfen Sie Massenaktionen und gefilterte Exporte einschließlich Berechtigungen und Benachrichtigungsfolgen. Geben Sie Packern, Support und Administratoren individuelle Konten mit rollengerechtem Zugriff.

Trennen Sie Datenbank- und Webhosts nur bei gemessenem Bedarf an unabhängigen Ressourcen. Berücksichtigen Sie Netzwerklatenz, sichere Verbindung, Sicherung/Wiederherstellung, Verbindungseinstellungen und Bereitstellungstests. Eine Konfigurationsänderung allein ist kein vollständiger Migrationsplan. Beziehen Sie Personal, Software, Infrastruktur, Gebühren und Retouren in die Margenbewertung zusätzlicher Bestellungen ein.

Regelmäßige Überwachung und Bereitstellung etablieren

• Dokumentieren Sie wiederholbare Labortests und reale Nutzerkennzahlen repräsentativer Seitentypen samt dem Verhalten bei Cache-Treffern und Cache-Fehltreffern.
• Überwachen Sie Verfügbarkeit, Fehler, PHP-Worker-Warteschlangen, CPU, Speicher, I/O, Abfragelatenz, Verbindungen und Cache-Kapazität. Setzen Sie Alarme anhand Ihrer Ausgangswerte.
• Prüfen Sie Slow-Query-Zusammenfassungen, Tabellenwachstum und Aufbewahrung. Nutzen Sie bei passendem Betriebsbedarf PMM oder ein Datenbankdashboard; automatische Vorschläge brauchen weiterhin Lasttests.
• Vergleichen Sie nach einer Modul-, Theme- oder Katalogänderung, einem großen Import oder einer Verschiebung des Traffics Ressourcen, Aufrufe, Abfragelast und Interaktionen mit den Ausgangswerten. Bewahren Sie vollständige Berichte und ein kurzes Änderungsprotokoll auf.
• Leeren Sie bei Bereitstellungen betroffene PrestaShop-Ebenen, wenden Sie die dokumentierte Web-OPcache-Richtlinie an, invalidieren Sie geänderte Ressourcen und wärmen Sie nur im kontrollierten Budget auf.
• Prüfen Sie Browserfehler, Bilddarstellung, Navigation, Filter, Warenkorb, Zahlung und Bestätigung durchgängig, und bestätigen Sie, dass Preise, Bestand und Integrationen weiterhin wie zuvor funktionieren.
• Prüfen Sie Feldtrends nach ausreichender Datensammlung. Bewerten Sie einen gleitenden Feldbericht nicht anhand eines Labortests oder weniger Tage.

Wählen Sie die nächste Änderung nach gemessenen Kosten, Risiko und Kundenwirkung. Testen Sie danach erneut und erhalten Sie einen Rückweg. Ein schnellerer Benchmark hilft nur, wenn Katalog, Preise, Datenschutzentscheidungen und Bestellprozess weiterhin korrekt funktionieren.

Fragen vor der Beauftragung einer Geschwindigkeitsoptimierung

Sollten wir zuerst mehr Arbeitsspeicher oder einen größeren Tarif kaufen? Fragen Sie, welche gemessene Wartezeit das beseitigen würde und was die anderen Dienste auf dem Server benötigen. Mehr Arbeitsspeicher behebt keine langsame Abfrage, keinen externen Aufruf und keine Browserarbeit.

Braucht eine große Tabelle einen weiteren Index? Nur wenn ein reales Zugriffsmuster so stark profitiert, dass sich Speicher- und Schreibkosten rechtfertigen. Testen Sie den Kandidaten auf Staging mit der tatsächlichen Last.

Sollten wir zuerst die Datenbank bereinigen? Nur wo gemessene Kosten dorthin deuten, etwa eine wachsende Tabelle in einer langsamen Abfrage oder ein wachsendes Backupfenster, und nur nach einer vereinbarten Aufbewahrungsrichtlinie.

Können wir mit Caching beginnen? Prüfen Sie es, wenn wiederholte öffentliche Arbeit den gemessenen Ansatzpunkt bietet. Erhalten Sie korrekte private Abläufe, testen Sie die Invalidierung und behalten Sie einen akzeptablen ungecachten Weg bei; die Reihenfolge der Änderungen folgt den Befunden.

Wann sollten wir die Prüfung wiederholen? Nach relevanten Modul- oder Katalogänderungen, Importen, Trafficverschiebungen oder einer Verschlechterung der erfassten Abläufe. Behalten Sie genug Monitoring bei, um eine solche Veränderung zu erkennen.