Über 50 Prozent weniger Speicherverbrauch pro Request — das hat WooCommerce.com erreicht, ohne ein einziges Plugin zu deinstallieren oder die Infrastruktur aufzurüsten. Der Trick ist so einfach wie konsequent: WordPress lädt bei jedem Request standardmäßig jedes aktive Plugin. Auf einer Plattform von der Größe WooCommerce.coms kostet das enorme Ressourcen — für Plugins, die der konkrete Request gar nicht braucht. Die Entwickler haben dieses Prinzip gebrochen und laden pro Route nur noch die Erweiterungen, die tatsächlich erforderlich sind.
Für Shop-Betreiber im DACH-Raum ist das mehr als eine Randnotiz aus dem Entwickler-Blog von WooCommerce. Es ist ein Beleg dafür, dass das größte Performance-Problem deutscher WordPress-Shops nicht der Server ist, sondern eine Architekturentscheidung aus den Anfangstagen von WordPress — und dass sie sich lösen lässt.
Warum lädt WordPress jedes Plugin bei jedem Request?
Die Antwort liegt im Kern des Systems. WordPress durchläuft bei jedem Aufruf denselben Boot-Prozess: Core laden, Must-Use-Plugins laden, dann alle aktiven Plugins aus dem Ordner wp-content/plugins einbinden, erst danach das Theme. Diese Reihenfolge ist seit über einem Jahrzehnt unverändert und war damals sinnvoll — typische Sites hatten fünf, zehn Plugins.
Heute sieht die Realität anders aus. Ein produktiver WooCommerce-Shop kommt schnell auf 40 bis 70 aktive Plugins: Zahlungsdienstleister wie PayPal und Stripe, Steuer-Plugins für deutsche Umsatzsteuerregeln, Trusted-Shops-Anbindung, SEO-Erweiterungen, Caching, Sicherheit, Forms, Tracking. Jede dieser Erweiterungen registriert Hooks, lädt PHP-Klassen, initialisiert Objekte und frisst Speicher — auch dann, wenn der Request nur eine statische Blogseite ausliefert.
Die Kosten summieren sich unbemerkt. Ein Plugin, das 20 MB Speicher belegt und 80 Millisekunden Initialisierungszeit kostet, tut das bei jedem einzelnen Request — ob Produktseite, REST-API-Call oder Heartbeat-Aufruf im Admin. Bei 60 Plugins reden wir über Megabytes pro Prozess, multipliziert mit der Anzahl gleichzeitiger PHP-Worker. Wer schon einmal gesehen hat, wie ein Shop unter Last nicht wegen der Datenbank, sondern wegen Speicherlimits der PHP-Prozesse in die Knie geht, kennt das Problem.
Wie WooCommerce.com das Plugin-Loading pro Route steuert
Der Ansatz des WooCommerce-Teams beruht auf einer einfachen Erkenntnis: Ein API-Request an den Endpoint für Bestellungen braucht andere Plugins als ein Request an die öffentliche Shop-Seite oder an ein Marketing-Landingpage-Template. Also wird früh im Boot-Prozess entschieden, welche Route bedient wird — und nur die zugehörige Plugin-Teilmenge geladen.
Technisch greift das Team dafür in die Phase ein, bevor WordPress die aktiven Plugins einbindet. Die aktive Plugin-Liste liegt in der Option active_plugins — und genau dort setzt die Filterlogik an. Anhand der angefragten Route wird eine Allowlist bestimmt, alle anderen Plugins werden für diesen einen Request aus der Liste entfernt. Der Zustand in der Datenbank bleibt unverändert: Global sind alle Plugins weiterhin aktiv, nur der konkrete Request sieht eine reduzierte Menge.
Zwei Details machen das Verfahren praxistauglich. Erstens bleiben Must-Use-Plugins unberührt — sie laden vor dem Filter und dienen gerade als Träger für diese Art von Infrastruktur-Code. Zweitens braucht jede Route eine explizit gepflegte Plugin-Zuordnung. Wer hier schlampig arbeitet, produziert Bugs der unangenehmen Sorte: Funktionen, die lokal funktionieren und in Produktion fehlschlagen, weil ein Plugin auf einer Route fehlt, das ein anderes Plugin voraussetzt.
Was bringt das konkret für Speicher und Latenz?
Die vom WooCommerce-Team berichteten Werte: über 50 Prozent weniger Speicherverbrauch pro Request, dazu messbar reduzierte Latenz. Beides folgt derselben Logik — weniger geladener Code bedeutet weniger PHP-Parsing, weniger registrierte Hooks, weniger Objekte im Speicher.
50 % Speicherreduktion wirkt sich auf die Skalierung direkt aus. PHP-FPM-Worker sind durch ihren Speicherverbrauch limitiert: Halbiert sich der Verbrauch pro Prozess, verdoppelt sich rechnerisch die Zahl paralleler Requests auf derselben Hardware. Für einen Shop im Sale oder unter Kampagnenlast ist das der Unterschied zwischen „hält durch“ und „502 Bad Gateway“.
Weniger geladener Code pro Request ist die billigste Form der Skalierung — sie kostet kein zusätzliches Hosting-Budget, nur Disziplin.
Die Latenzverbesserung fällt bescheidener aus, ist aber konstant: Jede Millisekunde, die der Boot-Prozess früher durchlief, kommt jeder Antwort zugute. Gerade bei API-Endpoints und AJAX-Requests, wo kein Page-Cache greift, schlägt das voll durch.
Warum ist das für deutsche WooCommerce-Shops riskant — und trotzdem richtig?
Die ehrliche Antwort zuerst: Selektives Plugin-Loading ist kein Feature, das man mal eben aktiviert. Es ist eine Architekturentscheidung mit laufenden Pflegekosten. Jedes neue Plugin muss den richtigen Routen zugeordnet werden, jede Plugin-Abhängigkeit muss bekannt sein. Ein deutsches Steuer-Plugin, das im Hintergrund bei jedem Request Hooks registriert, bricht unter einer falschen Allowlist möglicherweise leise zusammen — und der Fehler fällt erst bei der Steuerprüfung auf.
Dazu kommt ein DACH-spezifisches Problem: Viele hier verbreitete Erweiterungen — von Germanized über Trusted-Shops-Integrationen bis zu DATEV-Anbindungen — sind genau die Kategorie Plugin, die sich quer durch alle Routen zieht. Rechtstexte im Footer, Widerrufslogik im Checkout, Cookie-Consent überall. Die naive Annahme „Blogroute braucht nur fünf Plugins“ scheitert an deutscher Compliance-Realität schneller als an jeder Technik.
Trotzdem lohnt die Richtung. Denn die Alternative ist der Status quo: Shops, die 60 Plugins laden, um eine Landingpage auszuliefern, und deren Betreiber dann ein größeres Hosting-Paket buchen statt die Architektur zu hinterfragen. Wer in Deutschland bei Mittwald, Raidboxes oder einem vergleichbaren Managed-Hoster unterwegs ist, zahlt für PHP-Worker real Geld — Speicherreduktion ist dort keine akademische Übung, sondern eine direkte Einsparung.
Was Shop-Betreiber jetzt konkret tun sollten
Die komplette WooCommerce.com-Lösung nachzubauen, ist für die meisten Shops überdimensioniert. Aber die Denkweise dahinter lässt sich sofort anwenden.
- Plugin-Bestand auditieren: Jedes Plugin, das nicht messbar zum Umsatz, zur Rechtssicherheit oder zur Stabilität beiträgt, fliegt raus. Bei den meisten Shops sind das 15 bis 25 Prozent des Bestands.
- Conditional-Loading prüfen: Tools wie Plugin Organizer oder eigene Must-Use-Plugins erlauben bereits heute, Plugins auf bestimmte Routen zu beschränken — etwa ein Formular-Plugin nur auf Seiten, die Formulare enthalten.
- Messen vor Optimieren: Query Monitor zeigt, welche Plugins pro Request wie viel Speicher und Ladezeit kosten. Ohne diese Zahlen ist jede Optimierung Rätselraten.
Der WooCommerce.com-Fall zeigt vor allem eines: Das Performance-Problem großer WordPress-Installationen ist gelöst — nicht durch schnellere Server, sondern durch das Laden von weniger Code. Wer das als Betreiber ernst nimmt, gewinnt Speicher, Latenz und Skalierungsreserven, ohne einen Euro mehr für Infrastruktur auszugeben. Die Frage ist nur, wann Conditional Plugin Loading seinen Weg von einem Maßgeschneiderten Enterprise-Hack in eine standardmäßige Best Practice findet. Die ersten Hoster, die das als verwaltetes Feature anbieten, werden dafür dankbare Kunden haben.