50 Prozent weniger Speicherverbrauch pro Seitenaufruf: Diese Zahl hat das Engineering-Team hinter WooCommerce.com erreicht – nicht mit neuer Hardware, sondern mit einem Gedanken, der so simpel wie folgenreich ist. WordPress lädt bei jedem einzelnen Request sämtliche aktiven Plugins, unabhängig davon, ob die angefragte Seite sie überhaupt benötigt. Auf einer Installation in der Größenordnung von WooCommerce.com summiert sich dieser Ballast zu spürbaren Kosten: mehr Arbeitsspeicher, höhere Latenz, teurere Infrastruktur.
Die Antwort der Entwickler: Plugins werden nur noch dort geladen, wo sie tatsächlich gebraucht werden. Im WooCommerce Developer Blog beschreibt das Team, wie jede Route der Website nur noch die für sie relevanten Erweiterungen initialisiert. Eine Produktseite im Frontend muss nicht die Admin-Werkzeuge mitschleppen, ein API-Call nicht das Frontend-Rendering. Das Ergebnis: über 50 Prozent weniger Speicherverbrauch und messbar kürzere Antwortzeiten – und das, wie das Team betont, ohne die Stabilität der Seite zu gefährden.
Warum lädt WordPress überhaupt alle Plugins bei jedem Aufruf?
Die Architektur von WordPress stammt aus einer Zeit, in der Blogs fünf Erweiterungen hatten, nicht fünfzig. Beim Start jedes Requests werden alle aktiven Plugins eingebunden, weil das System nicht weiß, welche davon später im Ablauf gebraucht werden. Für kleine Seiten ist das verkraftbar. Für einen WooCommerce-Shop mit 30 bis 60 aktiven Erweiterungen – Payment, Versand, Buchhaltung, Marketing-Automation, Warenwirtschaft – bedeutet es, dass jeder Aufruf einer Kategorieseite auch den Code für den Kassenabgleich und das Newsletter-Tracking ausführt.
Für Händler ab einer Million Euro Jahresumsatz ist das keine akademische Frage. Die Time to First Byte entscheidet mit über die Platzierung in den Google Core Web Vitals und damit über organische Sichtbarkeit. Gleichzeitig treibt jede Millisekunde Latenz die Absprungrate im Checkout nach oben. Und wer sein Hosting nach Ressourcenverbrauch dimensioniert, zahlt für Plugin-Ballast schlicht doppelt: in Geschwindigkeit und in Euro.
Was bedeutet der Ansatz für den eigenen Shop?
Die WooCommerce.com-Implementierung ist ein internes Engineering-Projekt und kein fertiges Produkt, das Händler per Knopfdruck aktivieren können. Trotzdem liefert sie eine klare Richtung. Wer heute prüfen will, welche Erweiterungen seine Requests ausbremsen, findet mit Query Monitor ein etabliertes Werkzeug, das Ladezeiten und Datenbankabfragen je Plugin sichtbar macht. Der erste Schritt bleibt der unbequemste: eine ehrliche Bestandsaufnahme. In der Praxis lassen sich in gewachsenen Shops regelmäßig zehn bis zwanzig Prozent der aktiven Plugins deaktivieren, ohne dass ein einziger Prozess darunter leidet – Relikte aus alten Kampagnen, doppelt vorhandene SEO-Tools, nie konfigurierte Marketing-Apps.
Der schnellste Code ist der, der nie ausgeführt wird.
Wer darüber hinausgehen will, kann mit der Agentur des Vertrauens über selektives Plugin-Loading sprechen. Das WordPress-Plugin Plugin Organizer bietet diesen Ansatz seit Jahren an und erlaubt es, Erweiterungen pro URL oder Inhaltstyp zu aktivieren beziehungsweise zu deaktivieren. Die Lösung erfordert sorgfältige Tests – ein Plugin, das im Hintergrund doch gebraucht wird, kann sonst Funktionen still brechen. Genau dieses Risiko hat das WooCommerce-Team adressiert, indem es Sicherungsmechanismen einbaut, die fehlende Abhängigkeiten abfangen, bevor sie im Live-Betrieb Schaden anrichten.
Ein Signal für die Roadmap
Beachtenswert ist der Vorgang auch deshalb, weil WooCommerce hier auf eigener Infrastruktur vorlebt, was sich viele Händler vom Core wünschen: Performance als Standard, nicht als Nachgedanke. Ob das routenbasierte Laden Einzug in den WooCommerce- oder gar WordPress-Core findet, ist offen. Die Richtung aber ist gesetzt – und sie belohnt Shopbetreiber, die ihre Plugin-Landschaft heute schon verschlanken, statt auf das nächste Hosting-Upgrade zu hoffen.