PrestaShop Performance-Optimierung: Shop beschleunigen

Warum Shop-Geschwindigkeit keine Option ist

Jede zusätzliche Ladezeit von 100 Millisekunden kostet Sie Conversions. Amazon stellte fest, dass eine Verzögerung von 100 ms den Umsatz um 1 % senkt. Google bestätigte, dass Seiten mit einer Ladezeit von mehr als 3 Sekunden 53 % der mobilen Besucher verlieren, bevor diese Ihre Produkte sehen.

Für einen PrestaShop-Shop wirkt sich die Geschwindigkeit direkt auf drei Bereiche aus:

• Conversion-Raten: Ein Shop, der in 2 Sekunden lädt, konvertiert ungefähr doppelt so gut wie einer, der 5 Sekunden braucht. Ihre Kunden warten nicht — sie kaufen bei jemandem, der schneller ist.
• SEO-Rankings: Google verwendet die Seitengeschwindigkeit als Ranking-Faktor. Seit 2021 sind Core Web Vitals Teil des Algorithmus. Ein langsamer Shop wird schlechter gerankt, erhält weniger organischen Traffic und zahlt mehr für Sichtbarkeit.
• Mobile Nutzererfahrung: Über 70 % des E-Commerce-Traffics ist mobil. Langsamere Prozessoren, weniger Arbeitsspeicher, schlechtere Verbindungen. Wenn Ihr Shop auf dem Desktop langsam ist, ist er auf dem Smartphone eine Qual.

Geschwindigkeitsoptimierung ist keine einmalige Aufgabe — sie ist eine fortlaufende Disziplin. Jedes Modul, das Sie installieren, jede Theme-Änderung, jedes Produktbild beeinflusst die Performance. Behandeln Sie Geschwindigkeit als ein Feature, das Sie pflegen, nicht als ein Projekt, das Sie abschließen.

Messen Sie, bevor Sie optimieren

Das Schlimmste, was Sie tun können, ist mit dem „Optimieren“ zu beginnen, ohne zu wissen, wo die tatsächlichen Probleme liegen. Messen Sie immer zuerst.

Die richtigen Werkzeuge

• Google PageSpeed Insights: Kostenlos, nutzt echte Chrome-Nutzerdaten (CrUX). Testen Sie Ihre Startseite, eine Kategorieseite und eine Produktseite — das sind Ihre häufigsten Einstiegspunkte.
• GTmetrix: Zeigt ein Wasserfall-Diagramm, das genau darstellt, was geladen wird, in welcher Reihenfolge und wie lange jede Anfrage dauert. Unschätzbar für das Auffinden von Engpässen.
• WebPageTest: Das detaillierteste verfügbare Tool. Testen Sie von verschiedenen Standorten und Verbindungsgeschwindigkeiten mit Filmstreifen-Ansichten.

Core Web Vitals erklärt

Dies sind die drei Metriken, die Google zur Bewertung der Nutzererfahrung verwendet:

• LCP (Largest Contentful Paint): Die Zeit, bis das größte sichtbare Element fertig geladen ist. Zielwert: unter 2,5 Sekunden. Die meisten PrestaShop-Shops haben hier Probleme — nicht optimierte Bilder und Render-blockierende Skripte sind die Ursache.
• INP (Interaction to Next Paint): Wie lange die Seite braucht, um auf Klicks und Taps zu reagieren. Hat FID im März 2024 abgelöst. Zielwert: unter 200 ms. Umfangreicher JavaScript-Code und schlecht geschriebene Modul-Skripte verursachen einen hohen INP.
• CLS (Cumulative Layout Shift): Wie stark sich das Layout während des Ladens verschiebt. Zielwert: unter 0,1. Bilder ohne Dimensionsangaben, spät ladende Banner und Schriftartwechsel verursachen CLS.

Realistische Zielwerte

Ein funktionsreicher PrestaShop-Shop wird bei PageSpeed niemals 100 Punkte erreichen. Streben Sie an: Mobil 50–70, Desktop 80–95, LCP unter 3 s mobil / 2 s Desktop, Gesamtseitengewicht unter 2 MB, weniger als 80 HTTP-Anfragen.

Jagen Sie keinem perfekten PageSpeed-Score hinterher. Ein Score von 65 mit 3 % Conversion-Rate schlägt einen Score von 98 auf einer abgespeckten Seite, von der niemand kauft. Optimieren Sie für die echte Nutzererfahrung, nicht für eine Zahl.

Server-Optimierung

Kein Frontend-Trick kann einen langsamen Server ausgleichen. Wenn Ihr Server 2 Sekunden braucht, um HTML zu generieren, bevor der Browser überhaupt mit dem Laden von Assets beginnt, haben Sie bereits verloren.

PHP OPcache-Konfiguration

OPcache speichert vorkompilierten PHP-Bytecode im Arbeitsspeicher, sodass PHP Dateien nicht bei jeder Anfrage erneut parsen muss. Für PrestaShop (Hunderte PHP-Dateien pro Seitenaufruf) ist dies Pflicht.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

Die Standardwerte sind für PrestaShop zu niedrig. max_accelerated_files muss mindestens 20000 betragen (Standard ist 4000, aber eine typische PS-Installation hat 10.000–15.000 PHP-Dateien). Setzen Sie memory_consumption auf 128–256 MB — wenn der OPcache-Speicher voll wird, werden Einträge verdrängt und Sie verlieren den Vorteil.

Auf cPanel-Hosts mit validate_timestamps=0 liest OPcache Dateien NIEMALS erneut von der Festplatte. Sie müssen den Cache nach jedem Deployment über einen Web-Reqüst zurücksetzen — CLI-Resets leeren nur den CLI-Cache, nicht den Web-Cache.

MySQL / MariaDB-Tuning

Eine typische PrestaShop-Produktseite führt 50–200 SQL-Abfragen aus. Die wichtigste Datenbankeinstellung ist:

[mysqld]
# Set to 50-70% of available RAM on dedicated DB server
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# MySQL 5.7 / MariaDB only (removed in MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Find problem queries
slow_query_log = 1
long_query_time = 1

# Connection settings
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Die innodb_buffer_pool_size bestimmt, wie viele Datenbankdaten im RAM gehalten werden. Wenn Ihre Datenbank 500 MB groß ist und der Buffer Pool 1 GB beträgt, werden die meisten Abfragen aus dem Speicher bedient. Aktivieren Sie das Slow-Query-Log und prüfen Sie es wöchentlich — Abfragen, die länger als 1 Sekunde dauern, sind Probleme, die bei Spitzenverkehr eskalieren.

Hosting: Shared vs. VPS vs. Dedicated

• Shared Hosting (5–15 $/Monat): Sie teilen CPU und RAM mit Hunderten anderer Websites. Nur akzeptabel für sehr kleine Shops mit weniger als 500 Produkten.
• VPS (20–60 $/Monat): Dedizierte Ressourcen. Der optimale Mittelweg für die meisten Shops. Mindestens 4 GB RAM, 2 CPU-Kerne und SSD-Speicher.
• Dedicated (80–300 $/Monat): Für hochfrequentierte Shops (1000+ Bestellungen täglich) oder Kataloge mit über 100.000 Produkten.

Wenn Sie Shared Hosting nutzen und Ihr Shop langsam ist, bringt der Wechsel zu einem VPS eine größere Geschwindigkeitsverbesserung als alle anderen Optimierungen zusammen.

PHP-FPM und Redis

Verwenden Sie PHP-FPM anstelle von mod_php — es führt PHP als separaten Dienst aus, reduziert den Speicherverbrauch und verbessert das Prozessmanagement. Verwenden Sie Redis für Session- und Cache-Speicherung anstelle des Dateisystems. Konfiguration in app/config/parameters.php:

'ps_cache_enable' => true,
'ps_caching' => 'CacheRedis',

Integrierte PrestaShop-Optimierungen

CCC (Combine, Compress, Cache)

Zu finden unter Erweiterte Einstellungen → Leistung. CCC kombiniert CSS/JS-Dateien zu einzelnen Dateien und minifiziert sie. Immer auf Produktivsystemen aktivieren. Beachten Sie folgende Fallstricke:

• Dateien mit defer- oder async-Attributen bleiben separat (beabsichtigt)
• Externe Dateien (Google Fonts, Stripe.js) werden nie kombiniert
• Schlecht programmierte Module können brechen, wenn CCC die Asset-Reihenfolge ändert — falls das Aktivieren von CCC Ihren Checkout zerstört, deaktivieren Sie es und identifizieren Sie das problematische Modul
• Leeren Sie immer den Cache und testen Sie gründlich nach der Aktivierung

Smarty-Template-Einstellungen

Setzen Sie die Template-Kompilierung auf Produktivsystemen auf „Templates neu kompilieren, wenn die Dateien aktualisiert wurden“. Verwenden Sie niemals „Kompilierung erzwingen“ — das kompiliert jedes Template bei jedem Seitenaufruf neu.

Debug-Modus — Prüfen Sie das zuerst

Der Debug-Modus deaktiviert sämtliches Caching, erzwingt die Template-Neukompilierung und protokolliert alles. Stellen Sie sicher, dass er deaktiviert ist:

// In app/config/defines.inc.php — MUST be false on production
define('_PS_MODE_DEV_', false);

Wir haben Shops erlebt, die monatelang im Debug-Modus liefen. Ihr Problem mit dem „langsamen Shop“ verschwand, als diese einzige Einstellung korrigiert wurde.

Unnötige Module deaktivieren

Jedes aktivierte Modul klinkt sich in PrestaShops Event-System ein. Eine Neuinstallation enthält über 80 Module. Jedes einzelne lädt PHP-Klassen, kann CSS/JS auf jeder Seite registrieren, führt Hook-Callbacks aus und kann Datenbankabfragen ausführen — selbst wenn es leeren Inhalt zurückgibt.

Gehen Sie zu Module → Modul-Manager und deinstallieren Sie alles, was Sie nicht aktiv nutzen. Wenn drei Analytics-Module dasselbe tun, behalten Sie eines.

Bildoptimierung

Bilder machen typischerweise 60–80 % des gesamten Seitengewichts aus. Hier haben die meisten Shops das größte Verbesserungspotenzial.

WebP und korrekte Abmessungen

WebP-Bilder sind 25–35 % kleiner als JPEG bei keinem sichtbaren Qualitätsverlust. PrestaShop 8.x unterstützt WebP nativ. Für ältere Versionen verwenden Sie serverseitige Konvertierung oder ein Modul.

Die häufigste Verschwendung: 2000×2000 px-Bilder in 300 px-Thumbnails ausliefern. Konfigurieren Sie die Bildtypen unter Design → Bildeinstellungen so, dass sie den tatsächlichen Anzeigegrößen Ihres Themes entsprechen. Laden Sie keine 4000 px-Quellbilder „für alle Fälle“ hoch — 1200 px reichen für den Produktseiten-Zoom auf Retina-Displays völlig aus.

Lazy Loading

Verzögern Sie das Laden von Bildern unterhalb des sichtbaren Bereichs, bis der Nutzer dorthin scrollt:

<img src="product.jpg" loading="lazy" width="300" height="300" alt="Product Name">

Verwenden Sie Lazy Loading NICHT für Bilder im sichtbaren Bereich (Logo, Hero-Banner, erste Produktreihe) — diese beeinflussen den LCP und müssen sofort geladen werden.

Bildregeneration

Nach dem Ändern von Bildabmessungen regenerieren Sie vorhandene Bilder über Design → Bildeinstellungen oder per CLI:

php bin/console prestashop:image:regenerate --type=products

Frontend-Optimierung

HTTP-Anfragen minimieren

Prüfen Sie Ihr Wasserfall-Diagramm in GTmetrix. Über 100 Anfragen bedeuten Probleme. Häufige Ursachen: Module, die eigene CSS/JS-Dateien laden, Google Fonts mit mehreren Schriftgewichten, Social-Media-Widgets und mehrere Analytics-Tools.

Critical CSS

Browser stoppen das Rendering, bis alle CSS-Dateien im <head> heruntergeladen sind. Critical CSS extrahiert nur die Styles, die für den initialen sichtbaren Bereich benötigt werden, und bettet sie inline ein. Das vollständige Stylesheet wird asynchron geladen. Dies kann die gefühlte Ladezeit auf Mobilgeräten um 1–3 Sekunden reduzieren, erfordert aber eine Neugenerierung bei jeder Änderung des Theme-CSS.

JavaScript: Defer und Async

Verwenden Sie defer für die meisten Modul-Skripte (lädt parallel herunter, wird nach dem HTML-Parsing ausgeführt). Verwenden Sie async nur für unabhängige Skripte wie Analytics. In PrestaShop 1.7+:

$this->context->controller->registerJavascript(
    'module-my-script',
    'modules/mymodule/views/js/front.js',
    ['position' => 'bottom', 'priority' => 200, 'attribute' => 'defer']
);

Schriftarten-Optimierung

Benutzerdefinierte Schriftarten fügen unbemerkt 200–400 KB an Downloads hinzu. Best Practices:

• Schriftarten selbst hosten anstatt Google Fonts zu nutzen (eliminiert einen zusätzlichen DNS-Lookup)
• Subsetting auf nur die benötigten Zeichen (Latin-only-Subsets sind 60–80 % kleiner)
• font-display: swap verwenden, damit Text sofort in einer Fallback-Schriftart sichtbar ist
• Auf 2 Schriftgewichte beschränken — Regular (400) und Bold (700) decken die meisten Anforderungen ab
• WOFF2-Format verwenden — beste Komprimierung, universelle Browser-Unterstützung

@font-face {
    font-family: 'YourFont';
    src: url('/themes/your-theme/assets/fonts/yourfont.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

CDN-Grundlagen

Ein CDN liefert statische Dateien von Servern aus, die Ihren Besuchern geografisch nahe sind. Cloudflare ist die beliebteste kostenlose Option. Konfigurieren Sie eine CDN-Domain unter Erweiterte Einstellungen → Leistung → Medienserver für Bilder, CSS und JS.

Datenbank-Optimierung

PrestaShop-Datenbanken wachsen unbemerkt. Tabellen, die beim Launch noch performant waren, werden nach zwei Jahren angesammelter Daten zu Problemen.

Alte Warenkörbe bereinigen

ps_cart und ps_cart_product wachsen mit jedem Besucher — einschließlich Bots und abgebrochener Sitzungen. Nach einem Jahr können diese Tabellen Millionen von Zeilen enthalten.

-- Delete cart products for old abandoned carts (not linked to orders)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Delete the empty carts
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
LEFT JOIN ps_cart_product cp ON c.id_cart = cp.id_cart
WHERE o.id_order IS NULL AND cp.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Erstellen Sie immer ein Datenbank-Backup, bevor Sie DELETE-Abfragen ausführen. Testen Sie immer zuerst auf einer Staging-Umgebung. Das LEFT JOIN + IS NULL-Muster stellt sicher, dass mit Bestellungen verknüpfte Warenkörbe niemals gelöscht werden.

Logs und Verbindungen bereinigen

-- Application logs
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Visitor tracking
DELETE FROM ps_connections_page WHERE id_connections IN (
    SELECT id_connections FROM ps_connections
    WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Orphaned güst records
DELETE g FROM ps_güst g
LEFT JOIN ps_connections c ON g.id_güst = c.id_güst
WHERE c.id_güst IS NULL;

-- Search stats, 404 logs, email logs
DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Suchindex bereinigen

Wenn Sie eine externe Suchlösung (Elasticsearch, Algolia) verwenden, sind diese Tabellen unnötiger Ballast:

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Tabellen und Indizes optimieren

Nach umfangreichen Löschvorgängen Speicherplatz zurückgewinnen:

OPTIMIZE TABLE ps_cart, ps_cart_product, ps_connections,
    ps_connections_page, ps_güst, ps_log;

Fehlende Indizes für häufige Abfragen hinzufügen:

-- Check existing indexes first: SHOW INDEX FROM ps_cart;
ALTER TABLE ps_cart ADD INDEX idx_cart_date (date_add);
ALTER TABLE ps_connections ADD INDEX idx_conn_date (date_add);
ALTER TABLE ps_orders ADD INDEX idx_orders_ref (reference);
ALTER TABLE ps_product ADD INDEX idx_product_ref (reference);

Verwenden Sie EXPLAIN bei langsamen Abfragen, um zu prüfen, ob Indizes genutzt werden — wenn die Spalte „type“ den Wert „ALL“ zeigt, bedeutet das einen Full Table Scan.

Caching-Strategien

Full Page Cache

Die wirkungsvollste verfügbare Verbesserung. Ohne Full Page Cache führt jede Anfrage Hunderte PHP-Dateien und über 100 Abfragen aus (200–500 ms). Mit Full Page Cache wird dieselbe Seite in 5–20 ms ausgeliefert.

Varnish ist der Industriestandard. nginx FastCGI Cache ist einfacher, wenn Sie bereits nginx verwenden:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PS:100m inactive=60m;

set $skip_cache 0;
if ($http_cookie ~* "PrestaShop-") { set $skip_cache 1; }
if ($reqüst_uri ~* "/cart|/order|/my-account|/admin") { set $skip_cache 1; }

location ~ \.php$ {
    fastcgi_cache PS;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

Die Herausforderung ist die Cache-Invalidierung — das Leeren zwischengespeicherter Seiten, wenn sich Produkte, Preise oder Lagerbestände ändern. Diese Komplexität ist der Grund, warum viele Shops auf Full Page Caching verzichten.

Object Caching und Browser Caching

Object Caching (via Redis) speichert aufwendige Abfrageergebnisse im Arbeitsspeicher. Weniger wirkungsvoll als Full Page Cache (30–50 % Reduktion der Abfragezeit), aber deutlich einfacher — PrestaShop übernimmt die Invalidierung automatisch.

Browser Caching-Header teilen den Browsern Ihrer Besucher mit, statische Dateien lokal zu speichern:

# Apache (.htaccess)
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Häufige Performance-Killer

• Zu viele Module (50+): Jedes fügt Autoloader-Overhead, Hook-Callbacks, CSS/JS und Abfragen hinzu. Ein Shop mit 30 Modulen übertrifft immer einen mit 80. Es gibt kein Modul ohne Kosten.
• Module, die überall Assets laden: Ein Popup-Modul, das nur auf der Startseite feuert, aber 150 KB JavaScript auf jeder Seite lädt, ist reine Verschwendung. Prüfen Sie Ihren Wasserfall auf irrelevante Modul-Assets.
• Schwere Startseiten-Slider: 3–5 hochauflösende Bilder plus eine JS-Bibliothek = 1–5 MB für eine Komponente, mit der weniger als 1 % der Nutzer über den ersten Slide hinaus interagieren. Verwenden Sie stattdessen ein einzelnes statisches Hero-Bild.
• Nicht optimierte Custom Themes: Volles Bootstrap geladen für 3 Komponenten, unminifiziertes CSS/JS, keine Bildabmessungen, synchrone Skripte. Fordern Sie Performance-Audits von Theme-Entwicklern.
• Fehlende Datenbank-Indizes: Eine Abfrage mit korrektem Index dauert 10 ms. Ohne Index dauert sie 5 Sekunden — und Sie bemerken es erst, wenn der Traffic seinen Höhepunkt erreicht.

Checkliste zur Performance-Überwachung

Schnellprüfung (5 Minuten)

• PageSpeed Insights für Startseite, Kategorieseite und Produktseite ausführen
• Überprüfen, dass _PS_MODE_DEV_ auf false steht
• Bestätigen, dass Smarty NICHT auf „Kompilierung erzwingen“ eingestellt ist
• Prüfen, dass CCC aktiviert ist
• Über phpinfo() verifizieren, dass OPcache aktiv ist

Monatliche Wartung (30 Minuten)

• Abgebrochene Warenkörbe in ps_cart / ps_cart_product bereinigen (älter als 3 Monate)
• ps_log, ps_connections, ps_connections_page, ps_güst bereinigen
• OPTIMIZE TABLE auf bereinigten Tabellen ausführen
• Slow-Query-Log überprüfen
• Ungenutzte Module deinstallieren

Quartalsbericht (2 Stunden)

• Vollständiger GTmetrix-Test von mehreren Standorten — Vergleich mit dem Vorquartal
• Core Web Vitals in der Google Search Console überprüfen
• Modul-Assets auf unnötiges CSS/JS prüfen
• Bildgrößen überprüfen — sicherstellen, dass keine überdimensionierten Uploads vorliegen
• Server-Ressourcenauslastung prüfen (CPU, RAM, Disk-I/O)
• Auf einem echten Mobilgerät testen, nicht nur per Emulation
• Browser-Caching-Header verifizieren
• PHP-Fehlerprotokolle prüfen (Fehler verbrauchen Ressourcen)

Nach jedem Deployment

• PrestaShop-Cache leeren
• OPcache zurücksetzen, falls validate_timestamps=0
• Einen schnellen PageSpeed-Test auf Regressionen durchführen
• Browser-Konsole auf JavaScript-Fehler prüfen
• Den Checkout-Ablauf vollständig End-to-End testen

Starten Sie hier

Performance-Optimierung ist ein Prozess, kein Ziel. Beginnen Sie mit den vier wirkungsvollsten Maßnahmen: Serverkonfiguration korrigieren, Bilder optimieren, unnötige Module deaktivieren und die Datenbank bereinigen. Diese allein lösen 80 % der Performance-Probleme in den meisten PrestaShop-Shops.

Messen Sie vor und nach jeder Änderung. Führen Sie ein Protokoll. Die beste Optimierung ist die, die Ihre Kunden bemerken — schnelleres Laden von Bildern und ein reaktionsschneller Checkout übersetzen sich direkt in Vertrauen, Zufriedenheit und Conversions.