PrestaShop Architektur

Ist Ihr PrestaShop-Shop langsam? Messen Sie, bevor Sie optimieren

David Miller Veröffentlicht: 23.06.2026 Erstellt: 23.06.2026 Aktualisiert: 02.07.2026 PrestaShop Architektur

93 Aufrufe 11 Min. Lesezeit

Zuletzt aktualisiert: Juni 2026.

Wenn sich ein PrestaShop-Shop langsam anfühlt, ist die häufigste Reaktion zugleich die teuerste: ein Caching- oder Optimierungsmodul installieren, alle Schalter aktivieren und hoffen. Manchmal hilft das. Oft bringt es nichts - und gelegentlich macht es die Lage sogar schlechter, weil der eigentliche Engpass nie dort lag, wo das Modul ansetzt. Geschwindigkeitsprobleme sind zuerst Diagnoseprobleme. Der ehrliche Rat von jedem, der diese Arbeit beruflich macht, lautet immer gleich: messen, bevor Sie optimieren. Finden Sie die tatsächliche Ursache und investieren Sie dann in die Lösung, die genau dort ansetzt - was manchmal bedeutet, gar nichts auszugeben.

Warum Raten so teuer ist

"Mein Shop ist langsam" ist ein Symptom, keine Diagnose. Die Ursache kann an mehreren sehr unterschiedlichen Stellen liegen, und ein Werkzeug, das eine davon behebt, hilft bei den anderen überhaupt nicht:

Ein einzelnes Modul löst auf jeder Produktseite eine N+1-Abfrage aus - eine zusätzliche Abfrage pro Element in einer Schleife, multipliziert mit Ihrem Katalog.
Ein schwergewichtiges Theme lädt Hunderte Kilobyte renderblockierendes CSS und JavaScript, bevor überhaupt etwas angezeigt wird.
Langsame TTFB (Time to First Byte) durch überlastetes Shared Hosting oder einen Datenbankserver, der bereits am Limit von CPU oder IO arbeitet.
Unoptimierte Bilder - Uploads in voller Auflösung werden an Mobilgeräte ausgeliefert, moderne Formate fehlen, passende Größen ebenso.
Kein Full-Page-Cache, sodass PrestaShop jede Seite für jeden Besucher von Grund auf neu aufbaut.
Eine MySQL-Instanz mit zu wenig Arbeitsspeicher, die Tabellenscans ausführt, wo ein Index stehen sollte.

Genau hier liegt die Falle. Wenn Ihr Problem ein renderblockierendes Theme und eine langsame TTFB ist, kann ein Seiten-Cache-Modul bei wiederholten Aufrufen vielleicht ein wenig Zeit sparen, während der erste Eindruck - der, den Google misst - unverändert bleibt. Wenn Ihr Problem eine überlastete Datenbank ist, bringt keine Frontend-Asset-Optimierung die entscheidende Verbesserung. Sie können unbegrenzt Geld in die falsche Ebene stecken und trotzdem keinen schnelleren Shop spüren. Deshalb behandeln wir ein Performance-Audit als ersten Schritt: Es zeigt, welche Ebene Sie tatsächlich Zeit kostet, damit der nächste Kauf (falls überhaupt nötig) richtig ausgerichtet ist.

Was ein Performance-Audit tatsächlich misst

PrestaShop-Performance-Dashboard mit TTFB, LCP, FCP, CLS, Cache-Trefferquote und Web-Vitals-Trend — Ein aufgeraeumtes Performance-Dashboard zeigt die Kennzahlen, auf die sich ein Audit stuetzt — TTFB, LCP, FCP, CLS und Cache-Trefferquote — damit die Optimierung echte Engpaesse trifft.

Ein sauberes Audit ist kein einzelner Speedtest-Wert. Es zerlegt die Seite in ihre echten Bestandteile und zeigt, wo die Zeit verloren geht:

Serverzeit gegenüber Browserzeit

Die erste Trennung lautet TTFB gegenüber Frontend-Rendering. TTFB umfasst alles, was passiert, bevor Ihr Server das erste Byte sendet - PHP-Ausführung, Datenbankabfragen, Cache-Lookups. Frontend-Rendering ist alles, was der Browser anschließend mit der Antwort macht. Eine 3-Sekunden-Seite mit 2,4 s TTFB ist ein Backend-Problem; dieselbe 3-Sekunden-Seite mit 0,2 s TTFB und 2,8 s Rendering ist ein Frontend-Problem. Beide brauchen gegensätzliche Lösungen, und nur die Messung zeigt, welche Situation bei Ihnen vorliegt.

Abfragen pro Seite und die größten Verursacher

PrestaShop-Seiten können von einigen Dutzend bis zu mehreren Hundert SQL-Abfragen ausführen. Das Audit zählt sie pro Seitentyp und sortiert die größten Verursacher - häufig ist es ein einzelnes Modul, das eine Abfrage zwischenspeichern sollte, sie aber bei jedem Hook erneut ausführt. Diese eine Abfrage zu finden, ist oft mehr wert als jede zusätzliche Cache-Schicht darüber.

Modul-Overhead

Jedes in eine Seite eingehängte Modul verursacht Arbeit, und manche hängen sich in jede Seite ein, ob sie dort gebraucht werden oder nicht. Das Audit profiliert, welche Module messbar Ausführungszeit beitragen und welche unnötig feuern. So können Sie die echten Verursacher deaktivieren oder ersetzen, statt zu raten.

Asset-Gewicht und Caching

Er misst das gesamte Seitengewicht, die Anzahl der Requests und wie gut CCC (Combine-Compress-Cache), critical-CSS und verzögert geladenes JavaScript konfiguriert sind - oder ob sie überhaupt konfiguriert sind. Außerdem prüft er den Caching-Stack durchgängig: die Trefferquote des Full-Page-Cache, OPcache für kompiliertes PHP und Redis für den Objekt-/Abfrage-Cache. Ein Cache, der existiert, aber selten trifft, ist fast wertlos; nur die Trefferquote macht das sichtbar.

Hosting-Grenzen, Mobile und Core Web Vitals

Am Ende betrachtet es die Hardware-Realität - CPU, IO und Speicherreserven unter Last - und testet Mobile getrennt von Desktop, weil der Großteil Ihres Traffics und der Google-Messungen mobil ist. Das führt direkt zu den Core Web Vitals: LCP, CLS und INP. Das sind keine Eitelkeitsmetriken; sie sind ein echtes Ranking-Signal. Genau deshalb überschneiden sich Geschwindigkeit und Suche so stark, und deshalb bringen ein technisches SEO-Audit und ein Performance-Audit so oft dieselben Probleme ans Licht.

Ein Selbstcheck in zehn Minuten

Sie müssen nichts bestellen, um einen ersten Eindruck von Ihrem eigenen Shop zu bekommen. Öffnen Sie Ihre Startseite und eine stark genutzte Produktseite in Chrome und testen Sie Folgendes:

Führen Sie eine Waterfall-Analyse aus. Öffnen Sie die DevTools, wechseln Sie zum Tab Netzwerk, laden Sie hart neu und sehen Sie sich den allerersten Request an. Die Zeit "Waiting (TTFB)" zeigt, wie viel serverseitig passiert. Mehr als etwa 600 ms bei warmem Cache weist auf das Backend hin.
Zählen Sie Requests und Gewicht. Die Fußzeile des Netzwerk-Tabs zeigt die Gesamtzahl der Requests und die übertragene Größe. Hunderte Requests oder mehrere Megabyte pro Seite sind ein starkes Signal für Assets/CCC.
Lesen Sie den PrestaShop-Profiler. Aktivieren Sie den Debug-Modus auf einer Staging-Kopie und schalten Sie den Profiler ein - er gibt die Anzahl der Abfragen und die langsamsten Abfragen pro Seite aus. Eine Produktseite mit 250+ Abfragen verdient Aufmerksamkeit.
Drosseln Sie Mobile. Stellen Sie in den DevTools das Gerät auf ein mittelstarkes Mobilprofil mit "Slow 4G"-Drosselung und laden Sie neu. Wenn die Erfahrung hier zusammenbricht, ist genau das, was die meisten Ihrer Besucher tatsächlich erleben.

Diese Zahlen sind illustrative Schwellenwerte, keine Garantien - jeder Shop ist anders. Meist zeigen sie aber schon in die richtige Richtung, bevor jemand einen Euro ausgibt.

TTFB über die Befehlszeile messen

Wenn Sie lieber einen präzisen Serverzeit-Wert erhalten möchten, ohne DevTools zu öffnen, gibt curl die Timing-Aufschlüsselung direkt aus. Der Befehl ist schreibgeschützt - er ruft nur die Seite ab und gibt aus, wie lange jede Phase gedauert hat:

# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
  -w "dns:    %{time_namelookup}s\nconnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\ntotal:   %{time_total}s\n" \
  https://yourdomain.com/your-product-page

Die wichtigste Zahl hier ist TTFB (time_starttransfer): alles bis zum ersten Byte der Antwort. Führen Sie den Befehl ein paar Mal aus, damit ein kalter Cache das Ergebnis nicht verzerrt. Bleibt dieser Wert hoch - deutlich über einer halben Sekunde bei warmem Cache -, liegt Ihr Engpass serverseitig (PHP, Abfragen, Hosting), und keine Frontend-Asset-Optimierung wird ihn beheben. Ist die TTFB niedrig, die Seite fühlt sich im Browser aber trotzdem langsam an, liegen die Kosten stattdessen beim Rendering und den Assets. Genau diese eine Trennung ist der Grund, warum Sie messen sollten, bevor Sie kaufen.

Die ehrliche Wendung: Was das Audit Ihnen empfiehlt

Der ganze Sinn des Messens vorab ist, dass das Urteil oft nicht "kaufen Sie ein Optimierungsmodul" lautet. Ein gutes Audit endet in einer von wenigen klaren Richtungen:

Es liegt am Hosting. Wenn die TTFB selbst bei einem Cache-Treffer hoch ist und der Server am CPU-/IO-Limit arbeitet, kann kein Modul das beheben - Sie brauchen besseres Hosting oder einen abgestimmten Stack. Genau das grenzt ein Hosting-Audit ein.
Es liegt an der Konfiguration. Häufig existieren die Caches, sind aber falsch konfiguriert: CCC halb aktiviert, OPcache zu klein, Redis nicht wirklich angebunden. Das ist eine Einstellungssache, kein Kauf.
Es liegt an einem bestimmten Modul oder Theme. Manchmal ist ein einziges schwergewichtiges Modul oder ein ineffizientes Theme das gesamte Problem, und die Lösung besteht darin, es zu ersetzen oder zu entfernen.
Sie brauchen wirklich ein Werkzeug. Wenn der Engpass bei Frontend-Assets und fehlendem Full-Page-Caching liegt, ist ein fokussiertes Open-Code-Modul wie Performance Revolution der richtige Kauf - sobald Sie wissen, dass genau diese Ebene Sie Zeit kostet, nicht vorher.
Es ist bereits in Ordnung. Gelegentlich zeigt das Audit, dass der Shop gesund ist und die wahrgenommene Langsamkeit von einem einzelnen langsamen Drittanbieter-Skript oder einem regionalen Netzwerkproblem kommt. Das zu wissen, bewahrt Sie davor, etwas zu "optimieren", das gar nicht kaputt ist.

Blind zu kaufen ist der Grund, warum Shops am Ende drei sich überschneidende Caching-Module haben und langsamer sind als zu Beginn. Erst zu diagnostizieren ist günstiger, selbst wenn die Diagnose etwas kostet, weil sie verhindert, dass Sie Geld in die falsche Ebene stecken.

So starten Sie

Wenn Sie statt eines Nachmittags in Eigenregie eine strukturierte Auswertung möchten, ist unser Performance-Audit genau dafür gebaut. Sie geben Ihre Shop-URL ein, zuerst läuft ein kurzer schreibgeschützter Bereitschaftscheck - ohne Übergabe von Admin-Zugangsdaten; wie wir mit Zugriffen umgehen, erklären unsere Hinweise zur Shop-Audit-Bereitschaft - und erst danach wird das Audit bestellt. Es steht neben unseren übrigen Expertenleistungen für die Fälle, in denen sich die Lösung als Hosting-, Konfigurations- oder Entwicklungsarbeit statt als Produkt herausstellt. Wie auch immer das Ergebnis ausfällt: Sie wissen, warum der Shop langsam ist, bevor Sie Geld dafür ausgeben, ihn schneller zu machen - und genau dieser Teil spart tatsächlich Geld.

Häufig gestellte Fragen

Ich habe bereits ein Caching-Modul installiert. Warum ist mein Shop trotzdem langsam?

Weil Caching nur der Ebene hilft, auf der es sitzt. Ein Full-Page-Cache bringt nichts gegen ein langsames erstes Byte durch eine überlastete Datenbank, und ein Frontend-Optimierer kann keinen Server reparieren, der am CPU-Limit arbeitet. Ebenfalls häufig: Ein Cache ist installiert, trifft aber kaum - CCC halb konfiguriert, OPcache zu klein, Redis nicht wirklich angebunden. Die TTFB-Trennung oben zeigt Ihnen, ob Ihr Engpass überhaupt in einer Ebene liegt, die Caching beeinflussen kann. Oft ist das nicht der Fall, und deshalb hat das Modul "nichts gebracht".

Was ist eine "gute" TTFB für PrestaShop?

Als grobe Orientierung gilt: unter etwa 200 ms ist gesund, etwa 200-600 ms ist akzeptabel, und dauerhaft mehr als etwa 600 ms bei warmem Cache weist auf ein serverseitiges Problem hin, dem man nachgehen sollte. Das sind Bereiche, keine harten Grenzen - eine umfangreiche Produktseite darf legitimerweise mehr Arbeit leisten als die Startseite. Der nützliche Vergleich ist Ihr eigener Shop kalt gegenüber warm und Ihre TTFB im Verhältnis zur Rendering-Zeit, die der Browser danach hinzufügt. Dieses Verhältnis, nicht eine einzelne Zahl, zeigt, wohin Sie investieren sollten.

Kann ein Performance-Audit garantieren, dass mein Shop schneller wird?

Nein, und seien Sie vorsichtig bei allen, die das versprechen. Ein Audit zeigt Ihnen, warum der Shop langsam ist und welche Lösung dazu passt - es führt die Lösung nicht aus und garantiert keinen Wert. Liegt die Ursache beim Hosting, hängt die Beschleunigung vom neuen Stack ab; liegt sie bei einem schwergewichtigen Modul, davon, ob Sie es ersetzen können; ist bereits alles in Ordnung, lautet das ehrliche Ergebnis: "Geben Sie nichts aus." Der Wert liegt darin, die Ausgabe richtig auszurichten, nicht in einem versprochenen Millisekundenwert.

Verlangsamt das Audit meinen Live-Shop oder bringt es ihn in Gefahr?

Nein. Der Bereitschaftscheck und die Messungen sind schreibgeschützt - sie laden Seiten so, wie ein Besucher es tun würde, und zeichnen Zeiten auf; nichts wird geschrieben oder verändert. Der Profiler-Schritt im Selbstcheck ist der eine Punkt, den Sie auf einer Staging-Kopie statt live ausführen sollten, weil der Debug-Modus interne Details offenlegt und zusätzlichen Overhead verursacht. Das Audit selbst benötigt keinen Debug-Modus auf Ihrer Produktionsseite.

Worin unterscheidet sich das davon, einfach PageSpeed Insights auszuführen?

PageSpeed misst das Frontend-Rendering einer URL und bewertet es anhand der Core Web Vitals - wirklich nützlich und absolut einen Test wert. Was es nicht sehen kann, ist Ihr Server: Anzahl der Abfragen, welches Modul bei jedem Hook feuert, Ihre Cache-Trefferquoten oder ob die Datenbank die eigentliche Grenze ist. Eine Seite kann bei PageSpeed gut abschneiden und unter echter Kataloglast trotzdem langsam sein, oder schlecht abschneiden aus einem Grund, den kein Modul beheben kann. Das Audit deckt die Backend-Hälfte ab, für die PageSpeed blind ist.

David Miller

Founder, mypresta.rocks

David Miller ist PrestaShop-Spezialist mit über einem Jahrzehnt praktischer Erfahrung und Gründer von mypresta.rocks, einem Software-Studio im polnischen Tychy. Er entwickelt und pflegt einen Katalog von 152 PrestaShop-Modulen – darunter 21 „Revolution"-Suiten für SEO, Checkout, Sicherheit, Performance, Marketing, Suche, Support und Lagerverwaltung –, die reale Shops Tag für Tag verbessern und für PrestaShop 1.7.8, 8.x und 9.x getestet sind. Darüber hinaus betreut er Produktivshops mit einem Jahresumsatz in Millionenhöhe, sodass seine Arbeit an echten Verkäufen gemessen wird und nicht an Demos. Seine Erfahrung deckt die gesamte Bandbreite des E-Commerce ab – Performance, Sicherheit, SEO und Marketing – und reicht über PrestaShop hinaus bis zu WooCommerce, Shopify und maßgeschneiderten Systemen. Im Blog schreibt er über die technische Seite von PrestaShop: was die Plattform wirklich tut, was in der Produktion bricht und welche Lösungen sich bewähren.