50 Prozent weniger Speicherverbrauch pro Request — nicht durch ein neues Hosting-Paket, nicht durch ein CDN, sondern durch eine Frage, die sich jeder WordPress-Betreiber stellen sollte: Warum lädt mein Shop eigentlich bei jedem einzelnen Aufruf jedes einzelne aktive Plugin?
Die Entwickler hinter WooCommerce.com haben genau das getan. Ihre Antwort ist ein System, das pro Route nur noch die Plugins lädt, die diese Route tatsächlich braucht. Das Ergebnis: Der Speicherverbrauch sank um mehr als die Hälfte, die Latenz spürbar mit. Für den DACH-Markt, wo WooCommerce laut Statista und diversen Shop-Analysen zu den meistgenutzten Shop-Systemen im Mittelstand zählt, ist das keine Randnotiz. Es ist ein Bauplan.
Was genau macht WordPress bei jedem Request falsch?
WordPress kennt kein Konzept von Kontext. Ruft ein Besucher eine Produktseite auf, lädt der Core alle aktiven Plugins — auch das Buchhaltungs-Plugin, auch den Newsletter-Connector, auch das Tool für den Admin-Export. Ein Request auf die Startseite initialisiert denselben Code wie ein Webhook-Call aus dem ERP.
Bei einer Installation mit fünf Plugins fällt das nicht auf. WooCommerce.com ist aber keine Installation mit fünf Plugins. Es ist eine der größten WooCommerce-Sites überhaupt: Marktplatz, Shop, Lizenzverwaltung, Entwicklerdoku und Kundenkonto in einem System. Dutzende Plugins, viele davon intern entwickelt, jedes mit eigenen Hooks, eigenen Datenbankabfragen, eigenem Speicherbedarf.
Die Rechnung ist brutal simpel: Jedes Plugin, das beim Request geladen wird, frisst RAM und CPU-Zeit — auch dann, wenn es für diesen Request keinen einzigen Hook ausführt. Multipliziert mit dem Traffic einer Site dieser Größe entsteht ein permanenter Overhead, der weder dem Nutzer noch dem Betreiber etwas bringt.
Wie funktioniert das routenbasierte Laden konkret?
Der Ansatz des WooCommerce.com-Teams: Nicht jeder Request ist gleich, also darf auch die Plugin-Ladung nicht gleich sein. Ein Request wird anhand seiner Route klassifiziert — REST-API-Endpunkt, Admin-Seite, Frontend-Produktseite, Cron-Job, Webhook. Für jede Route existiert eine Liste der Plugins, die sie wirklich benötigt. Nur diese werden geladen.
Technisch heißt das: Früh im Boot-Prozess, bevor WordPress die Plugins initialisiert, entscheidet eine Art Dispatcher, welche Plugin-Dateien überhaupt eingebunden werden. Alles andere existiert für diesen Request schlicht nicht. Kein Autoloading, kein Hook-Registrieren, kein Speicher.
Das klingt nach einem Cache-Trick, ist aber etwas Fundamentales. Caching beschleunigt die Auslieferung von Ergebnissen. Routenbasiertes Plugin-Laden verhindert, dass unnötige Arbeit überhaupt entsteht — auch bei Requests, die nie gecacht werden können: eingeloggte Nutzer, Warenkörbe, API-Calls. Genau die Requests, die einen Shop teuer machen.
Die teuerste Millisekunde ist die, die für Code draufgeht, der für diesen Request gar nicht gebraucht wird.
Warum ist das riskant — und wie wird es sicher?
Die naheliegende Sorge: Plugins sind nicht isoliert. Plugin A registriert Hooks, die Plugin B erwartet. Ein Block-Theme ruft Funktionen auf, die ein scheinbar unbeteiligtes Plugin bereitstellt. Wer einfach Plugins weglässt, produziert Fatal Errors — im schlimmsten Fall mitten im Checkout.
Das Team hat das Problem ernst genommen und mit einem Must-Use-Plugin als Schicht zwischen Core und Plugin-Ladung gelöst, kombiniert mit Beobachtung statt Bauchgefühl. Welche Plugins eine Route tatsächlich nutzt, wird nicht geraten, sondern gemessen. Requests werden analysiert, Abhängigkeiten kartiert, und nur was nachweislich nicht gebraucht wird, fliegt raus.
Dazu gehört eine Schutzlogik: Unbekannte oder neue Routen fallen auf das volle Plugin-Set zurück. Im Zweifel wird mehr geladen, nicht weniger. Das System optimiert nur dort, wo es sich sicher ist. Genau diese Defensivität unterscheidet eine produktionsreife Lösung von einem Performance-Hack aus dem Forum.
Was bedeutet das für deutsche Shop-Betreiber?
Die wenigsten DACH-Shops haben die Größe von WooCommerce.com. Aber viele haben das gleiche Krankheitsbild: 30, 40, 50 aktive Plugins. DATEV-Anbindung, Trusted-Shops-Integration, Consent-Manager, sevDesk-Connector, ein Pagebuilder, drei SEO-Tools — und jeder Request lädt alles davon.
Das hat hierzulande eine besondere Schärfe. Deutsche Hoster im Mittelstandssegment arbeiten oft mit PHP-Memory-Limits von 256 oder 512 MB, und Agenturen reagieren auf Performance-Probleme reflexartig mit mehr Server statt mit weniger Code. Gleichzeitig verschärft Google mit den Core Web Vitals den Druck: Interaction to Next Paint misst seit März 2024 genau die Latenz, die unnötiger PHP-Overhead im Backend mitverursacht. Wer beim TTFB 200 Millisekunden verschenkt, merkt das im Ranking und in der Conversion.
Konkret können Betreiber drei Dinge übernehmen, ohne WooCommerce.coms Infrastruktur nachbauen zu müssen:
- Inventur statt Vermutung: Mit Query Monitor oder einem Profiling-Tool messen, welche Plugins bei welchen Request-Typen überhaupt Hooks ausführen. Die Ergebnisse überraschen fast immer.
- Selektives Deaktivieren: Plugins wie Plugin Organizer oder eigens geschriebene MU-Plugins können Admin-only-Tools aus Frontend-Requests fernhalten. Der Buchhaltungs-Connector muss auf der Produktseite nichts zu suchen haben.
- Plugin-Anzahl als Architekturentscheidung: Jedes neue Plugin ist kein Feature, sondern ein Dauerabo auf Request-Kosten. Vor der Installation gehört die Frage: Was kostet mich das pro Request, pro Monat, pro Jahr?
Reicht Caching nicht längst?
Nein — und die WooCommerce.com-Zahlen zeigen, warum. Full-Page-Caches wie Varnish oder die Cache-Schichten von Hostern wie Raidboxes oder Kinsta greifen bei anonymen Seitenaufrufen. Aber der teure Traffic eines Shops ist der personalisierte: Warenkorb, Checkout, Kundenkonto, REST-API für das Frontend, Webhooks von Zahlungsdienstleistern. All das läuft am Cache vorbei und direkt in den PHP-Prozess.
50 Prozent Speicherersparnis wirkt dort doppelt: Der einzelne Request wird schneller, und derselbe Server verkraftet mehr parallele PHP-Worker. In Stoßzeiten — Black Friday, Newsletter-Versand, Marktplatz-Peaks — entscheidet genau das, ob ein Shop skaliert oder kippt. Wer weniger RAM pro Request braucht, kauft sich Stabilität, ohne eine einzige neue Maschine zu bezahlen.
Object Caching und OPcache helfen zusätzlich, ändern aber nichts am Grundproblem: Code, der geladen wird, kostet. Der einzige Code, der garantiert nichts kostet, ist der, der nie geladen wird.
Die ehrliche Kehrseite
Dieses System ist kein Allgemeinrezept, und die WooCommerce-Entwickler stellen es auch nicht als solches dar. Es setzt voraus, dass ein Team seine Routen kennt, Abhängigkeiten messen kann und bei Fehlern schnell reagiert. Für eine Agentur, die 80 Kundenshops betreut, ist ein zentraler Plugin-Dispatcher ein Wartungsrisiko — ein falsch klassifizierter Request, und der Checkout eines Kunden steht.
Die Messlatte sollte also nicht „baue das nach“ sein, sondern „denke in Request-Kosten“. Die meisten Performance-Probleme deutscher WooCommerce-Shops entstehen nicht durch schlechtes Hosting, sondern durch Plugin-Akkumulation über Jahre. WooCommerce.com hat gezeigt, dass die halbierte Speicherlast nicht an einer Riesen-Infrastruktur hing, sondern an einer konsequenten Frage: Braucht dieser Request dieses Plugin — ja oder nein?
Wer das für seine zehn teuersten Routen beantwortet, hat schon den größten Teil des Gewinns eingefahren. Der Rest ist Skalierung.