Ist Ihr Shop langsam? So prüfen Sie es und beheben die Ursachen

"Mein Shop fühlt sich langsam an" ist keine Diagnose, sondern ein Symptom. Und wer auf Basis eines Gefühls handelt, verbringt schnell ein Wochenende damit, ein Cache-Modul zu installieren, das nichts löst. Die erste Aufgabe ist nicht, irgendetwas zu reparieren. Sie besteht darin, mit Zahlen herauszufinden, ob Ihr Shop wirklich langsam ist, wo die Langsamkeit entsteht (Server? Seitengröße? Datenbank? ein einzelnes problematisches Modul?) und wie gravierend sie tatsächlich ist. Messen Sie richtig, ergibt sich die passende Lösung meist von selbst. Messen Sie falsch, optimieren Sie am Ende Bilder in einem Shop, dessen eigentliches Problem eine Time to First Byte von 1,8 Sekunden ist, an der kein Bildtrick etwas ändert.

Dieser Leitfaden ist der Diagnose-Schritt: wie Sie die Geschwindigkeit eines PrestaShop-Shops sauber prüfen, wie Sie die Ergebnisse der Tools lesen und wie daraus eine priorisierte Aufgabenliste wird. Die tiefgehenden Korrekturen, Datenbank-Tuning, Full-Page-Cache, Redis, Hosting, haben jeweils eigene ausführliche Leitfäden. Wir verlinken Sie an den passenden Stellen dorthin, statt hier oberflächliche Kurzversionen von allem hineinzupacken.

Alles hier gilt für PrestaShop 1.6, 1.7, 8.x und 9.x, der Profiler-Schalter befindet sich in diesen Versionen in derselben Datei. In PS8/9 erhalten Sie zusätzlich die Symfony-Debug-Toolbar mit Abfragezahlen pro Request; darauf gehen wir unten ein.

Warum Ihr eigener Geschwindigkeitseindruck der unzuverlässigste Test ist

Sie besuchen Ihren Shop aus dem Büro, über eine kabelgebundene oder starke Verbindung, oft im Backoffice angemeldet, das bedeutet: PrestaShops Debug-Profiler und ein warmer Cache arbeiten zu Ihren Gunsten, und Sie rufen Seiten auf, die Sie heute bereits geladen haben. Ihr Kunde sitzt auf einem Android-Smartphone der Mittelklasse, nutzt mobile Daten und landet kalt auf einer Kategorieseite, auf die Google ihn geschickt hat. Das sind zwei verschiedene Shops. Der Händler, der sagt "bei mir fühlt es sich gut an", und die Analysedaten, die zeigen, dass Kaufabbrüche auf Mobilgeräten ansteigen, sagen beide die Wahrheit, sie messen nur unterschiedliche Maschinen.

Darum gilt vor jedem Tool: Wenn Sie testen, während Sie im Adminbereich angemeldet sind, sehen Sie nicht das, was Kunden sehen. Öffnen Sie das Frontoffice in einem privaten/Inkognito-Fenster oder drosseln Sie den Browser in Chrome DevTools besser auf "Slow 4G". Schon das allein rückt die Diskussion für die meisten Shopbetreiber zurecht.

Die vier Prüfungen, die sich lohnen (und was jede davon wirklich zeigt)

Sie brauchen keine zehn Tools. Sie brauchen vier Messwerte, die zusammen zeigen, ob das Problem beim Server, bei der Seite oder bei den Daten liegt. Denn das sind drei verschiedene Ansatzpunkte.

PageSpeed Insights, lesen Sie die Felddaten, nicht nur die Zahl

Geben Sie Ihre Shop-URL unter pagespeed.web.dev ein, und Sie erhalten einen Mobil- und einen Desktop-Score. Der mobile Score ist der entscheidende: Google indexiert mobile-first, und der meiste Traffic im Shop-Frontend ist mobil. Aber der Score (der große farbige Kreis) ist eine Laborsimulation. Scrollen Sie nach oben zu dem Abschnitt, der möglicherweise "Was Ihre echten Nutzer erleben" sagt. Das sind die CrUX-Felddaten echter Chrome-Besucher, und sie liefern das realistischere Bild. Ein Shop kann in der Laborsimulation 55 Punkte erreichen und die Core Web Vitals im Feld trotzdem bestehen, oder umgekehrt. Lesen Sie beides.

Als grobe Orientierung für den Laborscore:

• 90–100. Sie sind gut aufgestellt; setzen Sie Ihre Zeit anderswo ein.
• 50–89, in dieser Lücke steckt echtes Geld; ein strukturierter Durchgang lohnt sich.
• Unter 50. Das kostet Sie bereits Traffic und Conversions; behandeln Sie es als dringend.

Ein PageSpeed-Score in den 90ern ist auf einem echten PrestaShop-Shop mit einem umfangreichen Modul-Stack erreichbar. Das ist kein theoretisches Ziel, das nur leeren Demo-Installationen vorbehalten ist. Wir haben genau dokumentiert, wie das auf einem Live-PrestaShop-Shop funktioniert, in PageSpeed 99/100 auf einem echten Shop mit 130 Modulen; das ist der Proof-of-Concept-Begleiter zu diesem Diagnoseleitfaden.

Die drei Core Web Vitals und worauf jedes Scheitern hinweist

Google bewertet die Geschwindigkeit in der realen Welt anhand von drei Metriken. Der Wert liegt nicht in der Zahl selbst, sondern darin, dass die Metrik, die fehlschlägt, Ihnen zeigt, an welcher Stelle Sie ansetzen müssen.

• Largest Contentful Paint (LCP). Zeit, bis der Hauptinhalt sichtbar ist. Ziel: unter 2,5 s. Auf einer PrestaShop-Kategorie- oder Produktseite ist das fast immer das Hero- oder erste Produktbild, oder ein langsamer Server liefert das HTML zu spät. Ein schlechter LCP weist auf Bilder oder TTFB hin.
• Interaction to Next Paint (INP), wie schnell die Seite reagiert, wenn ein Kunde tippt. Ziel: unter 200 ms. Ein schlechter INP weist auf schweres oder doppelt eingebundenes JavaScript hin, meist zu viele Frontoffice-Module, die jeweils eigene Skripte injizieren.
• Cumulative Layout Shift (CLS), wie stark das Layout während des Ladens springt. Ziel: unter 0,1. Ein schlechter CLS weist auf Bilder ohne width/height-Attribute, spät ausgetauschte Webfonts oder einen Slider/Cookie-Banner hin, der Inhalte nach dem Paint nach unten schiebt.

Waterfall und TTFB, die wichtigste einzelne Trennung

Öffnen Sie GTmetrix (oder den Netzwerk-Tab der DevTools Ihres Browsers) und betrachten Sie vor allem eine Zahl: Time to First Byte (TTFB), die Lücke zwischen der Seitenanforderung des Browsers und dem Eintreffen des ersten Bytes der Antwort. Das ist die sauberste Verzweigung in der gesamten Diagnose:

• TTFB auf einer cache-kalten Seite dauerhaft über ca. 500–600 ms → der Engpass liegt serverseitig: PHP-Generierung, Datenbank oder das Hosting selbst. Keine Bildkomprimierung und keine Frontend-Arbeit wird das beheben. Dieser Zweig führt zu Caching-, Datenbank- und Hosting-Korrekturen.
• TTFB niedrig, aber die Seite fühlt sich trotzdem schwer an → der Server erledigt seinen Job; das Gewicht steckt im Frontend. Bilder, Fonts, CSS/JS-Bundles, die nach dem HTML geladen werden.

Dieser eine Messwert erspart mehr verschwendete Arbeit als jeder andere. Händler, die ihn überspringen, verbringen Tage mit CSS-Minifizierung in einem Shop, dessen Problem eine datenbankgebundene TTFB von 1,8 s war.

Der PrestaShop-Debug-Profiler, die Datenbank-/Modulmessung, die kaum jemand ausführt

Das ist die Prüfung, die spezifisch für PrestaShop ist und die die meisten Shopbetreiber nie anfassen, obwohl sie am aussagekräftigsten ist. Öffnen Sie in einer Staging-Kopie config/defines.inc.php und setzen Sie _PS_DEBUG_PROFILING_ auf true. Das ist der Schalter, der die Frontoffice-Profiler-Leiste und ihre Abfragezählung aktiviert. Die genaue Zeile, nach der Sie suchen:

// config/defines.inc.php – staging only, switch back to false when done
define('_PS_DEBUG_PROFILING_', true);

In PrestaShop 8 und 9 haben Sie eine zweite, einfachere Anzeige: Befindet sich der Shop im Dev-Modus, sitzt die Symfony-Debug-Toolbar am unteren Rand jeder Backoffice- und Frontoffice-Seite und zeigt die SQL-Abfragezahl sowie die Gesamtzeit für diesen Request. Außer dem Aktivieren des Debug-Modus ist keine Dateiänderung nötig. Entscheidend ist in beiden Fällen dieselbe Zahl.

Sie müssen _PS_MODE_DEV_ (vollständiger Debug-/Fehlermodus) nur aktivieren, wenn Sie bewusst auch Dev-Fehlerausgaben sehen möchten; für die reine Abfragezahl ist das nicht erforderlich, und es ist riskanter, es eingeschaltet zu lassen. Laden Sie dann eine Kategorie- und eine Produktseite. PrestaShop zeigt eine Profiler-Leiste mit der Ladezeit und, entscheidend, der Anzahl der SQL-Abfragen für diese Seite. Eine gesunde Seite liegt bei einigen Dutzend Abfragen; wenn eine einzelne Produktseite mehrere Hundert oder ein paar Tausend Abfragen auslöst, haben Sie die Ursache Ihrer Langsamkeit gefunden, und es ist fast immer ein bestimmtes Modul mit Abfrageschleifen oder eine nicht indexierte Tabelle, nicht "PrestaShop ist langsam". Schalten Sie beide Schalter wieder aus, bevor Sie fertig sind; lassen Sie sie nie in Produktion aktiviert.

Von der Messung zur priorisierten Aufgabenliste

Diagnose ist nur nützlich, wenn sie eine Reihenfolge der Maßnahmen liefert. Ordnen Sie Ihre Messwerte der passenden Korrektur zu, zuerst nach geringsten Kosten und höchster Wirkung, und folgen Sie dem Link zum Leitfaden, der diese Korrektur ausführlich behandelt, statt sie hier in einem Absatz abzuhandeln:

Die zwei kostenlosen Prüfungen, bevor Sie Geld ausgeben

Ein kostenloser Befehl liefert Ihnen eine erste Trennung zwischen DNS-/Verbindungszeit, Serverwartezeit und Gesamtübertragung. Er ersetzt Lighthouse nicht, zeigt aber, ob Sie bei Hosting/PHP/Datenbank oder beim Frontend-Payload beginnen sollten.

url="https://example.com/"
curl -o /dev/null -s -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s
' ";$url

Bewahren Sie Vorher-/Nachher-Zahlen an einem Ort auf, sonst werden Optimierungen zu Vermutungen.

Zwei Korrekturen kosten nichts, werden mit PrestaShop ausgeliefert und sollten vor jedem Kauf oder Upgrade bestätigt werden, denn sie verändern alle weiteren Messwerte, die Sie erheben.

Prüfen Sie, ob CCC aktiv ist. Gehen Sie zu Erweiterte Einstellungen → Leistung und aktivieren Sie Smarty-Caching sowie "Combine, Compress and Cache" (CCC) für CSS und JavaScript; wenn Ihre Apache/.htaccess-Konfiguration es unterstützt, aktivieren Sie außerdem die Apache-Optimierung / Browser-Cache-Direktiven für statische Assets (diese Option gilt nicht für reine nginx-Server). Viele Shops laufen jahrelang mit deaktivierten Optionen. Schalten Sie sie ein, leeren Sie den Cache und führen Sie PageSpeed erneut aus. Ihre Frontend-Werte können sich schon dadurch verbessern. (Eine Einschränkung: CCC kann gelegentlich mit den Assets eines schlecht gebauten Moduls kollidieren; testen Sie danach die Shop-Oberfläche.)

Prüfen Sie Ihre Modulanzahl. Jedes Frontoffice-Modul fügt jedem Seitenaufruf CSS, JavaScript und PHP hinzu. Öffnen Sie Design → Positionen, um zu sehen, wie viele Module im Frontoffice eingehängt sind, und deinstallieren Sie, nicht nur deaktivieren, alles, was Sie nicht aktiv nutzen. Ein Shop mit 100+ Modulen kämpft gegen die eigene Hardware. Welche Module warum schaden, behandeln wir in was PrestaShop wirklich langsam macht.

Wo ein Modul seinen Platz verdient, und wo nicht

Wenn Ihre Diagnose klar auf die Server-Antwortzeit zeigt. Hohe TTFB, jede Seite wird für jeden Besucher neu erzeugt. Dann ist das genau der Fall, für den ein Full-Page-Cache gebaut ist. Statt dass PHP und die Datenbank dieselbe Kategorieseite Tausende Male am Tag neu aufbauen, liefert ein Full-Page-Cache fertiges HTML aus, und der Server kommt kaum ins Schwitzen. Unser Modul Performance Revolution ist unsere Antwort auf genau diesen Messwert: Es speichert ganze Seiten im Cache, sodass die TTFB sinkt, ohne dass Sie ein Theme neu schreiben oder den Hoster wechseln müssen. Was bedeutet das also für Sie? Die Seiten, die Ihre Kunden und Google kalt abrufen, werden schnell ausgeliefert, Installation und Konfiguration erfolgen im Backoffice statt über eine Entwicklerrechnung, und, weil es der serverseitige Engpass ist, den Sie gemessen haben, zeigt sich die Verbesserung bei jedem Besucher, nicht nur bei den Glücklichen mit warmem Cache.

Die ehrliche Grenze: Ein Full-Page-Cache behebt eine langsame Serverantwort. Er verkleinert kein 5-MB-Hero-Bild und repariert kein springendes Layout. Das sind Frontend-Probleme, die Ihr Waterfall angezeigt hat, und sie gehören zur Bildoptimierung, nicht zum Caching. Stimmen Sie die Korrektur auf den Messwert ab. Wenn Ihre Cache-Backend-Messung stattdessen Redis verlangt, deckt unser Modul Redis Cache Manager & Monitor diesen Zweig ab, und der ausführliche Redis-Leitfaden erklärt, wann das die richtige Entscheidung ist.

Messen, beheben, erneut messen, über Wochen, nicht Tage

Halten Sie Ihre Ausgangswerte fest, bevor Sie etwas anfassen: mobilen PageSpeed-Score, die drei Core Web Vitals aus der Search Console, TTFB und Ihre Conversion-Rate vom Warenkorb zur Bestellung. Ändern Sie eine Sache und messen Sie dann erneut, aber geben Sie Felddaten Zeit. Der Core Web Vitals-Bericht der Search Console arbeitet mit einem gleitenden 28-Tage-Fenster; eine Korrektur, die Sie heute ausliefern, ist im Feld also erst nach Wochen vollständig sichtbar. Eine Optimierung anhand von drei Tagen Daten zu beurteilen, ist der Weg, auf dem Händler eine Änderung zurückrollen, die eigentlich funktioniert hat. Kombinieren Sie die Geschwindigkeitszahlen mit Verhalten: Google Analytics GA4 zeigt Seitenladezeiten, und Microsoft Clarity zeigt, ob langsame Seiten mit Rage Clicks und schnellen Ausstiegen zusammenfallen, die menschliche Seite eines schlechten LCP.

Warum sich dieser Nachmittag lohnt

Performance-Arbeit ist nicht glamourös, aber sie hat eine Qualität, die Marketing selten hat: Sie hilft jedem Besucher, jedes Mal, ohne dass eine Kampagne verwaltet werden muss. Die oft zitierte Zahl, dass jede zusätzliche Sekunde Ladezeit Conversions kostet, variiert je nach Studie und Shop, behandeln Sie sie als Richtungshinweis, nicht als Versprechen, und messen Sie Ihr eigenes Vorher/Nachher, statt einer Blogzahl zu vertrauen. Verlässlich ist die Methode: nicht raten, prüfen; die TTFB lesen, um Server und Seite zu trennen; die fehlschlagende Metrik den Reparaturbereich benennen lassen; zuerst die zwei kostenlosen Korrekturen erledigen; und erst dann Geld für den Engpass ausgeben, den Sie tatsächlich gemessen haben. Ein sauber diagnostizierter Shop wird mit einem Bruchteil des Aufwands schnell, den ein nach Bauchgefühl optimierter Shop verschlingt.

Häufig gestellte Fragen

Mein PageSpeed-Score ist gut, aber der Shop fühlt sich trotzdem langsam an. Was übersehe ich?

Sie lesen wahrscheinlich den Laborscore und spüren die Feldrealität, oder umgekehrt. Der große farbige Kreis ist ein einzelner simulierter Ladevorgang; was Ihre Kunden tatsächlich erleben, steht in den CrUX-Felddaten weiter oben im Bericht und im Core Web Vitals-Bericht der Search Console. Prüfen Sie außerdem, ob Sie testen, während Sie im Backoffice angemeldet sind, ein warmer Cache und die Admin-Sitzung schmeicheln Ihren Zahlen. Testen Sie in einem Inkognito-Fenster mit auf "Slow 4G" gedrosseltem Netzwerk, und die Lücke erklärt sich meist von selbst.

Ist eine hohe TTFB immer ein Hosting-Problem?

Nein, und das anzunehmen ist hier der teuerste Fehler. Eine hohe TTFB sagt nur, dass die Langsamkeit serverseitig liegt, sie sagt nicht, ob die Ursache die Datenbank, ein schweres Modul oder die Hardware ist. Führen Sie den Profiler aus: Wenn eine Seite Hunderte oder Tausende SQL-Abfragen auslöst, ist es die Datenbank oder ein Modul in einer Schleife, und ein größerer Server führt dieselben langsamen Abfragen nur etwas schneller aus. Trennen Sie beides, bevor Sie Geld ausgeben. Was PrestaShop wirklich langsam macht zeigt, wie Sie sie unterscheiden.

Behebt ein Full-Page-Cache einen schlechten PageSpeed-Score?

Er behebt eine langsame Serverantwort, hohe TTFB auf Seiten, die für jeden Besucher neu erzeugt werden, und sonst nichts. Er verkleinert kein 5-MB-Hero-Bild, repariert kein springendes Layout (CLS) und entwirrt kein renderblockierendes JavaScript; das sind Frontend-Probleme, die Ihr Waterfall angezeigt hat. Stimmen Sie die Korrektur auf den Messwert ab: Cache für den TTFB-Zweig, Bildoptimierung für den LCP/CLS-Zweig.

Wie lange dauert es, bis ich einer Änderung vertrauen kann?

Labortools reagieren sofort, aber der Core Web Vitals-Bericht der Search Console arbeitet mit einem gleitenden 28-Tage-Fenster; eine Korrektur, die Sie heute ausliefern, ist im Feld also erst nach Wochen vollständig sichtbar. Eine Optimierung anhand von drei Tagen Felddaten zu beurteilen, ist der Weg, auf dem Händler eine Änderung zurückrollen, die eigentlich funktioniert hat. Führen Sie den Labortest sofort erneut aus, um einen Plausibilitätscheck zu erhalten, und geben Sie den Felddaten dann ihren Monat, bevor Sie ein Fazit ziehen.

Ist es sicher, den Profiler in meinem Live-Shop zu aktivieren?

Machen Sie das auf einer Staging-Kopie. _PS_DEBUG_PROFILING_ legt Interna und die Leiste für jeden offen, der die Seite aufruft, und _PS_MODE_DEV_ kann Fehlerdetails preisgeben, beides gehört nicht in die Produktion. Aktivieren, Messwerte erfassen, beide wieder auf false setzen. In PS8/9 liefert die Symfony-Toolbar im Dev-Modus dieselbe Abfragezahl mit derselben Einschränkung: nur Staging.

Weiterführende Lektüre

• Performance Revolution, das Full-Page-Cache- und Critical-CSS-Modul für den High-TTFB-Zweig, mit Vorher-/Nachher-Metriken in einem Panel
• Was PrestaShop wirklich langsam macht, Datenbank vs. Module vs. Hosting, sobald Ihre TTFB-Messung "serverseitig" sagt
• Performance-Tuning: von Datenbankabfragen zum Full-Page-Cache, die tiefgehende Korrektur für eine hohe SQL-Abfragezahl
• Datenbankbereinigung im Zeitverlauf, für eine TTFB, die mit dem Alter des Shops schleichend steigt