Zu viele WordPress-Plugins

#Die Seite, die wir übernommen haben

Plugin-Überladung kündigt sich selten an. Kein einzelnes Plugin ist der Schurke. Die Seite funktioniert, langsam, bis jemand sie misst und feststellt, dass die Kosten kumulativ sind: jedes Plugin fügt Abfragen, Skripte, Styles, eine Update-Pflicht und ein Stück Angriffsfläche hinzu, und dreißig davon zusammen verwandeln eine einfache Content-Seite in etwas, das fast acht Sekunden zum Rendern braucht.

#Der größte Übeltäter war ein Aufrufzähler

Das größte einzelne Problem war kein schwerer Page Builder und kein Bild. Es war ein Aufrufzähler. Die Seite zählte Artikelaufrufe, indem sie bei jedem Seitenaufruf einen Wert in wp_postmeta erhöhte, synchron, innerhalb der Anfrage. wp_postmeta ist eine allgemeine Schlüssel-Wert-Tabelle, aus der WordPress ständig liest; sie ist nicht für einen hochfrequenten Schreibvorgang bei jedem Besuch gebaut. So laufen gelassen, hatte genau dieser eine Mechanismus wp_postmeta auf 322 MB der 705 MB großen Datenbank anwachsen lassen.

Der Schaden ist nicht nur die Festplatte. Eine aufgeblähte, heiße wp_postmeta verlangsamt einen großen Teil der normalen WordPress-Abfragen, weil so viel des Systems aus ihr liest. Eine Funktion also, an die niemand dachte, eine Aufrufzahl, besteuerte still jede Seite. Das Entfernen des synchronen Schreibvorgangs und das korrekte Zählen der Aufrufe brachte diese Tabelle auf eine vernünftige Größe zurück und nahm jeder Anfrage Last ab.

#Überladung ist auch eine Sicherheitsgeschichte

Die Plugin-Anzahl kostete nicht nur Geschwindigkeit. Sie vergrößerte die Angriffsfläche auf die vorhersehbaren Arten:

• Ein offener xmlrpc.php-Endpunkt, ein klassischer Vektor für Brute-Force und Amplifikation.
• Auf der Produktion angezeigte PHP-Fehler, die Serverpfade preisgaben (Information Disclosure).
• Plugins mit bekannten Schwachstellen, weil verwaiste oder nicht aktualisierte Plugins keine Patches mehr erhalten.

Deshalb ist das Reduzieren der Plugin-Anzahl eine Sicherheitsmaßnahme, nicht nur eine Performance-Maßnahme. Jedes Plugin, das Sie entfernen, ist Code, dem Sie nicht mehr vertrauen, den Sie nicht mehr beobachten und aktualisieren müssen. Es ist dieselbe Logik, die hinter einem ordentlichen WordPress-Sicherheitsaudit steht: weniger Fläche, weniger Wege hinein.

#Was es tatsächlich behoben hat

Die Behebung war unspektakulär und wirksam:

• Jedes Plugin daraufhin prüfen, was es tatsächlich tut, dann die Überschneidungen und die verwaisten entfernen und kleine Plugin-Aufgaben durch wenige Zeilen Theme-Code ersetzen.
• Den Aufrufzähler neu schreiben, sodass er nicht mehr bei jeder Anfrage in wp_postmeta schreibt, was die Datenbank wieder schrumpfen ließ.
• Über 1.5 GB statische PDFs vom Anwendungsserver zu Cloudflare R2 Objektspeicher verlagern, damit der VPS keine großen Dateien ausliefert, die ihn nichts angehen.
• Einen Redis-Objekt-Cache hinzufügen, damit wiederholte Abfragen den Speicher statt der Datenbank treffen, was den VPS mit 3 vCPU entlastet.
• xmlrpc.php schließen, die Fehleranzeige auf der Produktion abschalten und die verbleibenden Plugins auf gepatchte Versionen bringen.

Nichts davon ist clever. Es ist Disziplin, angewandt auf einen Stack, der keine hatte, und es ist der Großteil dessen, was echte Core-Web-Vitals-Arbeit sich als zu sein herausstellt, sobald man über den Laborwert hinausschaut.

#Warum KI-gestützte Builds das immer wieder erzeugen

Plugin-Überladung gab es schon vor KI. Aber KI-Assistenten verschlimmern sie auf eine bestimmte Weise: wenn die Antwort auf jede Anforderung lautet “installiere dafür ein Plugin”, häuft sich die Schuld schneller an, weil das Vorschlagen eines Plugins für einen Assistenten der Weg des geringsten Widerstands ist, genau wie für eine Person in Eile. Sie enden mit demselben 30-Plugin-Stack, nur an einem Nachmittag zusammengesetzt. Deshalb sitzt dieser Teardown innerhalb unserer breiteren Arbeit zur Rettung KI-erstellter Websites: ob die Überladung von einer Person oder einem Prompt kam, die Bereinigung ist identisch, auditieren, entfernen, durch gezielten Code ersetzen und messen.

#Glossar

• wp_postmeta - eine zentrale WordPress-Tabelle, die Schlüssel-Wert-Metadaten für Beiträge speichert; sehr häufig gelesen, sodass ihr Aufblähen die ganze Seite verlangsamt.
• Objekt-Cache (Redis) - ein In-Memory-Speicher, der die Ergebnisse wiederholter Datenbankabfragen hält, damit sie nicht jedes Mal die Datenbank treffen.
• Objektspeicher (Cloudflare R2) - Speicher für statische Dateien wie PDFs und Bilder, unabhängig vom Anwendungsserver ausgeliefert.
• LCP (Largest Contentful Paint) - wie lange es dauert, bis das größte sichtbare Element gerendert wird; ein zentrales Maß der gefühlten Ladegeschwindigkeit.

#Das Fazit

Wenn Ihre WordPress-Seite über ein oder zwei Dutzend Plugins hinausgewachsen ist, sind die Kosten fast nie ein offensichtlicher Schuldiger. Es ist die Anhäufung, plus ein oder zwei stille Mechanismen, ein Aufrufzähler, ein nicht indexiertes Log, ein synchroner API-Aufruf, die im Hintergrund echten Schaden anrichten. Die Behebung ist, die Plugins zu zählen, den Mechanismus zu finden, der bei jeder Anfrage schreibt, und das schwere statische Gewicht vom Anwendungsserver zu verlagern. Eine Seite bei 7.7 Sekunden ist nicht hoffnungslos. Es ist meist ein Stack, den niemand auditiert hat, was ein sehr anderes und viel günstigeres Problem ist, als es aussieht.