WooCommerce-Optimierung Ebene für Ebene: Cache, Redis, Datenbank und Core Web Vitals

Ein langsamer WooCommerce-Shop hat selten nur eine Ursache. Eine Produktseite kann auf PHP, auf die Datenbank oder auf Bilder und Skripte im Browser warten, und ein einzelnes Beschleunigungs-Plugin deckt meist nur einen Teil dieser Ebenen ab. Deshalb sollte die Optimierung Ebene für Ebene erfolgen: von der Serverkonfiguration und dem Cache über die Datenbank bis zur Art, wie Ressourcen geladen werden.

Kontext

WooCommerce verbindet Inhalte, die sich gut cachen lassen, mit Daten, die für einen bestimmten Kunden erzeugt werden müssen. Zur zweiten Gruppe gehören vor allem:

• der Warenkorb und der Bestellprozess;
• das Kundenkonto und die Seiten des Benutzerkontos;
• Oberflächenfragmente, die den Warenkorbinhalt anzeigen;
• individuelle Preise, Rabatte und Daten, die vom angemeldeten Benutzer abhängen.

Hinzu kommen die Ressourcen vieler Plugins, die auch auf Seiten geladen werden, die sie nicht nutzen, sowie eine Datenbank, die mit dem Shop wächst: temporäre Daten, Vorgangshistorie, Produktmetadaten und Reste entfernter Plugins.

Jeder dieser Bereiche kann ein Engpass sein. Startseite, Kategorie, Produktseite, Warenkorb und Bestellung können zudem ganz unterschiedliche Grenzen haben, deshalb lohnt es sich, sie getrennt zu messen.

Lösung

Cache auf der richtigen Ebene

Je nach Serverarchitektur kommen verschiedene Caching-Ebenen zum Einsatz:

• Redis Object Cache: Ergebnisse von Operationen und Abfragen im Speicher, weniger Arbeit für die Datenbank;
• Varnish Cache: Caching von HTTP-Antworten auf Ebene des Reverse Proxy;
• NGINX FastCGI Cache: Caching erzeugter PHP-Antworten direkt auf dem Server;
• Browser Cache: Speicherung statischer Ressourcen im Browser-Cache.

Entscheidend ist die Trennung von statischen und dynamischen Inhalten. Ein falsch konfigurierter Cache in WooCommerce kann veraltete Daten anzeigen, den Warenkorb stören und sogar Sitzungsinhalte anderer Kunden offenlegen.

WP_CACHE und Redis

Die Konstante WP_CACHE in der Datei wp-config.php erlaubt WordPress, die Caching-Mechanismen der entsprechenden Komponenten zu nutzen:

define( 'WP_CACHE', true );

Die Konstante allein startet jedoch weder Redis noch cacht sie Seiten. Nötig sind ein persistenter Object Cache, eine funktionierende Verbindung zum Redis-Server und die Prüfung, ob das Caching tatsächlich wirkt: Anzahl der Lese- und Schreiboperationen, Cache-Trefferquote und Auswirkung auf SQL-Abfragen.

LiteSpeed Cache oder WP Rocket

Die Wahl des Plugins sollte sich aus der Infrastruktur ergeben, nicht aus seiner Beliebtheit. LiteSpeed Cache ist in LiteSpeed- und OpenLiteSpeed-Server integriert, einschließlich Seiten-Caching und Edge Side Includes (ESI). WP Rocket bietet Mechanismen zur Frontend-Optimierung und zum Caching, die in verschiedenen Hosting-Umgebungen funktionieren. Das Ergebnis hängt vom Server, der Cache-Konfiguration, der Anzahl der Produkte, den Plugins und dem Traffic-Profil ab.

Ausnahmen für dynamische Elemente

Wo die Umgebung es erlaubt, lassen sich ausgewählte dynamische Fragmente über ESI unabhängig erzeugen. In anderen Konfigurationen müssen Sie Cache-Ausnahmen, Cookie-Regeln und die Behandlung von WooCommerce-Sitzungen festlegen. Das Ziel bleibt dasselbe: so viel wie möglich cachen, ohne die Korrektheit des Kaufprozesses zu beeinträchtigen.

Bilder

Produktbilder gehören zu den Ressourcen mit dem größten Einfluss auf die Ladezeit. Die Optimierung umfasst:

• die Umwandlung in die Formate WebP und AVIF;
• an verschiedene Geräte angepasste Größen sowie die Attribute srcset und sizes;
• Lazy Loading für Grafiken außerhalb des sichtbaren Bereichs;
• vorrangiges Laden wichtiger Bilder in der ersten Ansicht.

Das LCP-Bild (Largest Contentful Paint) sollte nicht durch Lazy Loading verzögert werden. Die Attribute width und height sowie CSS aspect-ratio lassen den Browser früh Platz für eine Grafik reservieren, was die mit CLS gemessenen Layoutverschiebungen begrenzt. alt-Attribute verbessern die Barrierefreiheit und helfen Suchmaschinen, beschleunigen den Shop aber nicht; rein dekorative Elemente können ein leeres alt haben.

CSS und JavaScript

Die Arbeit umfasst das bedingte Laden von Skripten und Stylesheets nur dort, wo sie gebraucht werden, das Entfernen von ungenutztem CSS, Minifizierung, das Reduzieren render-blockierender Ressourcen, defer oder async, wo die Abhängigkeiten es zulassen, und Ordnung bei externen Analyse- und Marketing-Tools. In WooCommerce muss dabei die Reihenfolge der Skripte für Warenkorb, Produktvarianten und Bestellung erhalten bleiben.

Lokale Schriften

Schriften aus externen Quellen fügen Netzwerkverbindungen hinzu und können die Textdarstellung verzögern. Hilfreich sind lokal gespeicherte Dateien im Format WOFF2, weniger Schnitte und Stärken, ein passender font-display-Wert und Preload der wichtigsten Schriften, wenn es einen messbaren Vorteil bringt:

@font-face {
  font-family: "Shop Sans";
  src: url("/fonts/shop-sans.woff2") format("woff2");
  font-display: swap;
}

Datenbank

Besondere Aufmerksamkeit verdient die Tabelle wp_options, vor allem die automatisch geladenen Einträge. Prüfen sollten Sie Größe und Struktur der Autoload-Daten, veraltete Datensätze und verwaiste Metadaten, abgelaufene Transients, die Leistung von SQL-Abfragen, Tabellenindizes und die Last, die der Action Scheduler erzeugt.

Werkzeuge wie WP-Optimize helfen, aber eine automatische Bereinigung ersetzt keine Analyse der Datenstruktur. In größeren Shops helfen WP-CLI, eigene PHP- und SQL-Skripte und die Analyse von Abfragen, die Ursachen von Problemen zu finden.

Komprimierung und Header

Komprimierung mit GZIP oder Brotli, abgestimmt auf Infrastruktur und Ressourcentypen, verringert die übertragene Datenmenge. Bei dieser Gelegenheit lohnt es sich, die Antwort-Header und die Caching-Richtlinie für statische Ressourcen zu prüfen.

Messung und Monitoring

Optimierung beginnt mit einer Messung und endet mit einer Überprüfung. Nützlich sind PageSpeed Insights und Lighthouse, die Kennzahlen LCP, INP, CLS und TTFB sowie Query Monitor und PHP-Profiling. Ergebnisse synthetischer Tests sollten Sie nach Möglichkeit mit Daten echter Nutzer vergleichen.

Nach dem Deployment zählt laufendes Monitoring: PHP- und WordPress-Fehlerprotokolle, HTTP-Server-Logs, langsame SQL-Abfragen, Fehler in WooCommerce und Action Scheduler, Probleme mit externen APIs, PHP-FPM-Last und Speicherverbrauch sowie Fehler beim Bestellen und bei Zahlungen. Logs müssen geschützt und nicht öffentlich zugänglich sein.

Einschränkungen

• Es gibt keine Konfiguration für jeden Shop. Ein kleiner Shop mit wenig Traffic braucht einen anderen Ansatz als eine Plattform mit Tausenden von Produkten, B2B-Preislisten, ERP-Anbindung und hohem Traffic.
• Jede Änderung am Cache erfordert eine Prüfung von Warenkorb, Kundenkonto und Bestellung, denn dort sind Fehler am teuersten.
• Vor einer Datenbankbereinigung sollten Sie ein Backup erstellen und die Abhängigkeiten prüfen, um Bestelldaten und Geschäftsprozesse nicht zu beschädigen.
• Ein guter PageSpeed-Wert ist kein Selbstzweck. Synthetische Tests zeigen nicht alle Probleme, die in den Logs sichtbar werden.

Ein schneller WooCommerce-Shop entsteht, indem man die echten Engpässe findet und sie auf der richtigen Ebene der Architektur beseitigt, nicht durch ein Plugin oder eine einzelne Einstellung.