Vertrauliche WooCommerce-Performance-Recovery und Core Web Vitals-Optimierung

#Projektüberblick

Diese Fallstudie beschreibt die Performance-Recovery eines EU-B2B-WooCommerce-Distributors mit einem mehrsprachigen Katalog von über 12.000 SKUs. Wegen strenge Vertraulichkeitsvereinbarungen bleibt die Identität des Kunden ungenannt; die technische Vorgehensweise und die Architekturentscheidungen sind dagegen vollständig beschreibbar. Genau Leistungswerte gehören nicht dazu: Sie sind im Vertrag nicht zur Veröffentlichung freigegeben, und Zahlen, die ihre Quelle nicht nennen können, sind schlechter als gar keine Zahlen. Was sich ehrlich sagen lässt, steht im Ergebnisteil.

Vor der Optimierung kämpfte der Shop mit spürbarer Latenz im Checkout während der Lastspitzen, mit mobilen Core Web Vitals im roten Bereich auf den zentralen Templates und mit Datenbank-Blockaden, die sich unter gleichzeitigen Zugriffen zu spürbaren Wartezeiten summierten. Das Geschäft lief trotzdem weiter, denn der Katalog war intakt und die Bestellprozesse funktionierten. Das ist der typische Ausgangszustand solcher Projekte: kein kaputter Shop, sondern ein Shop, der Geld lässt, weil Besucher vor dem Abschluss aufgeben.

#1. Ausgangslage: Einschränkungen und Geschäftsrisiken

Der Kunde betrieb eine B2B-Handelsplattform mit hohem Bestellvolumen und folgenden Parametern:

• Kataloggröße: über 12.000 aktive Produkte mit komplexen Varianten.
• Sprachen: vier aktive europäische Sprachversionen über eine mehrsprachige Übersetzungsmatrix.
• Geschäftsrisiko: Jede Sekunde zusätzlicher Ladezeit korreliert in B2B-Bestellprozessen mit spürbar höheren Abbrüchen, und der Checkout lud während der Rechnungsläufe regelmäßig so langsam, dass Einkäufer parallel telefonisch bestellten. Das ist die unbequemste Form des Problems, weil sie im Reporting als Routinekauf erscheint und nicht als Systemfehler.
• Technisches Risiko: Der Checkout berechnete Preise in Echtzeit über REST-API-Hooks in ein angebundenes ERP-System. Jede Verzögerung im Frontend verstärkte damit die Wartezeit der Backend-Berechnung und umgekehrt.

Dazu kamen Anforderungen, die in deutschen und europäischen B2B-Umgebungen selbstverständlich sind, in Case Studies aber selten auftauchen. Der Shop verarbeitete Geschäftsdaten von Unternehmen, also personenbezogene Daten von Ansprechpartnern, Kontaktdaten und Bestellhistorien. Jede Änderung an Marketing-Skripten und Tracking berührte deshalb die DSGVO-Pflichten des Kunden, insbesondere die Frage, welche Anbieter als Auftragsverarbeiter eingebunden sind und ob die vorhandenen AVV entsprechend angepasst werden mussten. Die Auslagerung von Marketing-Pixeln an die Netzwerkkante war deshalb nicht nur eine Performance-Entscheidung, sondern auch eine datenschutzrechtliche, und sie wurde mit dem Datenschutzbeauftragten des Kunden abgestimmt.

#2. Technische Diagnose

Das Performance-Audit ergab drei grundlegende Engpässe. Wichtig war dabei die Reihenfolge: Erst messen, dann sprechen. Jede Vermutung wurde gegen Messwerte auf einer Kopie der Produktionsumgebung geprüft, nicht gegen eine lokale Installation mit Demodaten.

#Datenbank-Ballast in wp_options

Die Tabelle wp_options hatte im Lauf der Jahre einen erheblichen Umfang angesammelt, vor allem durch Autoload-Einträge von längst deinstallierten Erweiterungen und durch abgelaufene Transients, die niemand geräumt hatte. Autoload bedeutet: Jeder einzelne Seitenaufruf lädt diesen Ballast vollständig in den Speicher, bevor überhaupt mit dem Aufbau der Seite begonnen wird. Bei einem Katalog dieser Größe addiert sich das zu einer messbaren Verzögerung vor jedem Template, auf jeder Seite, bei jedem Besucher. Der Effekt ist tückisch, weil er auf einer leeren Testinstallation unsichtbar bleibt und auf der Produktionsumgebung konstant mitläuft.

#Renderblockierendes JavaScript im Main-Thread

Über zwei Dutzend Analyse- und Werbe-Pixels, darunter Tag-Manager, Social-Pixel und Session-Recording-Dienste, wurden synchron im Browser geladen und blockierten den Main-Thread deutlich, bevor der eigentliche Seiteninhalt gerendert werden konnte. Das drückte vor allem den Largest Contentful Paint auf den mobilen Templates, mit denen die Einkäufer arbeiteten. Gleichzeitig stellte sich die Frage, die in jedem solchen Projekt gestellt werden muss: Welche dieser Skripte braucht der Kunde überhaupt noch, und für welche davon ist der Betreiber datenschutzrechtlich Verantwortlicher gegenüber den Besuchern?

#Uncached API-Endpunkte und Transient-Flut

Der Shop nutzte dynamische Mini-Cart-Aufklapper, die bei jedem einzelnen Seitenaufruf eine uncached AJAX-Anfrage zur Warenkorb-Aktualisierung auslösten. Unter gleichzeitiger Last fluteten diese Anfragen den PHP-FPM-Prozesspool, wartende Datenbankverbindungen stauten sich, und genau dann, wenn viele Einkäufer gleichzeitig bestellten, wurde der Checkout am langsamsten. Das ist die bekannteste Schwachstelle großer WooCommerce-Installationen: Die Standard-Fragment-Aktualisierung ist für kleine Shops praktisch und für Kataloge dieser Größenordnung eine Lasttest-Bombe.

#3. Architektur und Optimierungsstrategie

Um die Latenz zu beseitigen, ohne Transaktionsrisiken einzuführen oder die ERP-Synchronisation zu beschädigen, wurde eine vierstufige Optimierungsstrategie gefahren. Die Leitentscheidung stand am Anfang: Der Projektstart war kein Neubau. Die erste Verpflichtung lautete, die Korrektheit des Checkouts zu schützen, und erst danach wurden die sicheren Oberflächen in Richtung stärkeres Caching und leichteres Rendering bewegt.

#Datenbank-Hygiene

Zunächst wurden Transient-Daten isoliert und geräumt, verwaiste Optionen entfernt, die deinstallierte Erweiterungen zurückgelassen hatten, und der Autoload-Index radikal ausgedünnt. Die Tabelle wp_options schrumpfte von einem Ballast, der jede Anfrage mitzog, auf eine Handvoll relevanter Einträge. Das war die wirksamste Einzelmaßnahme des Projekts, und sie kostet erstaunlich wenig: Sie verändert keine Inhalte, keine Preise und keine Abläufe, sie entfernt nur tote Last. Der Vorgang lief gegen eine Kopie der Datenbank, mit Sicherung und definiertem Rückweg, denn ein Fehler bei der Autoload-Ausdünnung trifft die ganze Seite und nicht nur ein Template.

#Redis Object Cache mit geschütztem Checkout

Danach zog ein persistenter Redis-Cache ein, der Transients und Abfrageergebnisse hält. Der entscheidende Konfigurationsschritt betraf nicht das Caching selbst, sondern seine Grenzen: Cache-Gruppen für Session-Daten und Checkout-Transaktionen wurden ausdrücklich ausgeschlossen, damit ERP-Preise, Steuern, Bestände und Bestelldaten immer aus der Quelle kommen. Ein Cache, der einen veralteten Preis ausliefert, zerstört mehr Vertrauen, als jede Millisekunde bringt. Genau diese Grenzziehung zwischen cachebaren kommerziellen Seiten und Live-Transaktionsflüssen ist der Kern jeder seriösen WooCommerce-Performance-Arbeit.

#Auslagerung der Marketing-Pixel an die Netzwerkkante

Das alte clientseitige Tag-Manager-Setup wurde ausgemustert, und das Marketing-Tracking wanderte auf Cloudflare Zaraz. Die Pixel laufen seitdem in Edge-Workern auf Serverseite statt im Browser des Besuchers, was den Main-Thread entlastet und den Largest Contentful Paint auf den mobilen Templates hebt. Für den Datenschutz des Kunden hatte der Schritt einen Nebeneffekt, der in der internen Abstimmung genauso viel Gewicht hatte wie die Performance: Die Datenflüsse lassen sich zentral kontrollieren und dokumentieren, die Liste der verarbeitenden Dienste ist überschaubar, und die DSGVO-Bewertung betrifft eine definierte Stelle statt zwei Dutzend verstreuter Skripte.

#Abfangen der Mini-Cart-AJAX-Anfragen

Die Standard-Fragment-Aktualisierung von WooCommerce wurde abgeschaltet und durch einen eigenen Mechanismus auf Basis des sessionStorage des Browsers ersetzt. Der Warenkorb-State aktualisiert sich jetzt nur noch, wenn ein Besucher tatsächlich etwas in den Warenkorb legt. Das beseitigt tausende unnötige Datenbankrunden pro Tag und nimmt dem Checkout genau an der Stelle Druck, an der gleichzeitige Bestellvorgänge sonst zusammenstoßen.

#4. Umsetzungsprozess: Phasen, Testumgebung und Wiederherstellungspfad

Die Arbeit lief in kurzen Phasen: Baseline-Messung, Skript-Audit, Bild- und Layout-Fixes, Cache-Strategie, Checkout-Isolierung, Validierung in der Testumgebung, Produktivstart, danach Messung nach der Veröffentlichung. Jede Phase hatte einen Wiederherstellungspfad. Das ist wichtiger als jede dramatische Launch-Story, wenn der Umsatz des Kunden durch denselben Checkout läuft, der gerade optimiert wird.

Die Testumgebung lag nahe an der Produktion, und das ist die Voraussetzung für alles Übrige. Eine Performance-Optimierung, die gegen eine leere Installation geprüft wird, prüft nichts: Weder die Datenverteilung im Katalog noch das Cache-Verhalten unter realen Einstiegspfaden noch das Zusammenspiel mit dem ERP. Für den Datenschutz wurde die Testumgebung mit anonymisierten Datenkopien betrieben, damit die personenbezogenen Daten der Geschäftspartner des Kunden nicht in einer zweiten Umgebung mit breiterem Personenkreis lagen. Der Zugriff auf die Testumgebung war auf die beteiligten Personen begrenzt und wurde protokolliert; was dort über technische und organisatorische Maßnahmen geschützt wird, war vor dem ersten Datenimport schriftlich vereinbart.

Die Phasen waren bewusst klein gehalten. Nach jeder Phase folgte dieselbe Reihenfolge: Messung in der Testumgebung, Abgleich gegen die Baseline, Freigabe durch den Kunden, Produktivstart, Beobachtung der echten Zahlungsvorgänge über einen definierten Zeitraum, erst danach die nächste Phase. Zweimal wurde eine Phase in der Testumgebung verworfen, weil das Verhalten im Checkout nicht dem erwarteten Bild entsprach. Das klingt nach Verzögerung, ist aber das Gegenteil: Eine verworfene Phase kostet einen Tag, ein falsch ausgelieferter Preis im Live-Betrieb kostet das Vertrauen der Einkäufer, und das kommt nicht durch die nächste Korrektur zurück.

Die Änderungen selbst wurden dokumentiert: jede Konfiguration, jede Ausnahme im Cache, jeder abgeschaltete Hook, mit Begründung und Rückweg. Diese Dokumentation wurde bei der Übergabe an das Team des Kunden übergeben und ist heute der Referenzpunkt, wenn neue Erweiterungen geprüft werden.

#5. Ergebnisse: was sich ehrlich sagen lässt

An dieser Stelle stehen üblicherweise eine Tabelle mit Vorher-Nachher-Werten und ein Prozentsatz darunter. Sie steht hier bewusst nicht. Der Vertrag erlaubt die Veröffentlichung genauer Messwerte nicht, und wir schreiben keine Zahlen in eine Case Study, die sich nicht gegen eine datierte Quelle verteidigen lassen. Die ehrliche Form für dieses Projekt lautet:

Die Performance wurde rund 30 Tage nach dem Produktivrollout gemessen. Die Core Web Vitals der zentralen Templates gingen ins Grüne, also aus dem roten Bereich heraus, in dem sie zuvor vor allem auf mobilen Geräten lagen. Die Zeit bis zum ersten Byte sank im europäischen Verkehrsmix deutlich, also über alle vier Sprachversionen und ihre unterschiedlichen Entfernungen zum Server hin gemessen, nicht nur für den günstigsten Standort. Und die Lastspitzen, die zuvor den PHP-FPM-Pool überfordert hatten, trafen auf eine Auslieferung, die sie ohne Datenbank-Blockaden aufnahm.

Was sich zusätzlich ohne jede Zahl sagen lässt: Die Bestellvorgänge blieben während der gesamten Optimierung korrekt. Kein Preis brach, keine Bestellung ging verloren, kein Rechnungslauf musste abgebrochen werden. Bei einem Projekt, dessen wichtigste Randbedingung die Unantastbarkeit des Checkouts war, ist das kein Nebenresultat, sondern das Ergebnis.

Zur Einordnung der Messmethodik gehört ein Satz, den Auftraggeber verdient: Die Werte stammen nicht aus einem Labor-Lauf, sondern aus dem Feld, also aus den realen Seitenaufrufen der vier Sprachversionen über den Zeitraum der Messung hinweg. Labor-Messungen auf einer sauberen Verbindung sehen fast immer besser aus als der Verkehr, den ein Shop tatsächlich erreicht, besonders in den mobilen Netzen, über die ein Teil der Einkäufer arbeitet. Die Unterscheidung ist deshalb wichtig, weil sie zeigt, dass die Verbesserung dort angekommen ist, wo das Geschäft sie braucht, und nicht nur in einem Prüftool.

#6. Übergabe, Dokumentation und Wartung

Nach dem Rollout ging das Projekt in die Betreuung über. Zur Übergabe gehörten die dokumentierte Cache-Politik mit allen Ausnahmen, ein Beschreibung der Grenze zwischen cachebaren und uncachebaren Inhalten, die Konfiguration des Redis-Clusters, die Verwaltung der Marketing-Pixel inklusive der datenschutzrechtlichen Vereinbarungen mit den jeweiligen Anbietern und ein Messrhythmus, der die Core Web Vitals periodisch prüft. Wartung bedeutet bei einem Shop dieser Größenordnung vor allem Disziplin: Neue Erweiterungen werden gegen die dokumentierte Cache-Politik geprüft, bevor sie in den Produktivbetrieb gehen, denn die häufigste Rückkehr der Performance-Probleme ist nicht ein technischer Defekt, sondern eine Erweiterung, die unbeobachtet eigene Autoload-Einträge und eigene AJAX-Anfragen mitbringt. Dazu kommt ein kurzer periodischer Blick auf die Datenbank selbst: Autoload-Ballast wächst leise zurück, wenn niemand hinsieht, und erreicht nach einigen Jahren den alten Zustand, ohne dass irgendeine Warnung erscheint. Ein fester Prüfrhythmus von wenigen Minuten pro Quartal verhindert das zuverlässig.

#7. Lehren für Auftraggeber

Aus diesem Projekt bleiben drei Sätze, die auf die meisten großen WooCommerce-Installationen zutreffen. Erstens: Echte Performance-Recovery sitzt in der Datenbank-Hygiene und im Schutz des Main-Threads, nicht in einem neuen Theme. Zweitens: Die Auslagerung von Drittanbieter-Skripten an die Netzwerkkante und das Abschalten dynamischer Warenkorb-Schleifen sind die wirksamsten Hebel für grüne Core Web Vitals bei großen Katalogen, und sie sind zugleich die Hebel mit dem geringsten Risiko für den Bestellprozess. Drittens: Wer den Checkout als uncachebar behandelt und isoliert, bevor er den Katalog optimiert, kann beides haben, Geschwindigkeit und Korrektheit, statt sich zwischen ihnen zu entscheiden.

Ein vierter Satz betrifft die Einkaufsseite des Projekts. Fragen Sie jeden Anbieter, der Ihnen Vorher-Nachher-Werte für einen vertraulichen Shop präsentiert, nach der datierten Quelle. Zahlen, die diese Frage nicht beantworten, sind Marketing, keine Messung.

#Wann dieses Szenario auf Ihr Projekt passt

Dieses Szenario passt zu Ihnen, wenn Sie einen etablierten WooCommerce-Shop betreiben, der funktioniert, aber unter Last spürbar nachlässt; wenn der Checkout wegen ERP-Anbindung, B2B-Preisen oder Compliance-Anforderungen nicht angetastet werden darf; wenn Ihre Core Web Vitals auf mobilen Templates im roten Bereich stehen und Sie die Ursache nicht in einem einzelnen Plugin lokalisieren können; und wenn Sie Änderungen brauchen, die sich jederzeit zurückrollen lassen, weil der Bestellprozess nicht stillstehen darf.

Es passt nicht, wenn das eigentliche Problem ein veraltetes Datenmodell ist, das sich nicht mehr pflegen lässt, wenn das Theme nach Jahren der Overrides neu gebaut werden muss, oder wenn Sie ohnehin eine Headless-Migration planen. In diesen Fällen ist eine Recovery nur eine Verlängerung einer Frist. Welcher Weg für Ihre Situation der richtige ist, lässt sich nach einer ersten Sichtung des Stacks und der langsamsten Templates beantworten.

Wenn Ihr Shop sich in einer dieser Situationen befindet, schildern Sie uns den aktuellen Stack, die langsamsten Templates und die geschäftliche Randbedingung. Wir sagen Ihnen ehrlich, ob der richtige erste Schritt eine Recovery, eine Migration oder ein kleinerer Audit ist. Kontaktieren Sie uns über unsere deutsche Kontaktseite, und Sie erhalten zuerst eine Einschätzung statt eines Angebots.