Core Web Vitals Rescue für KI-gebaute WordPress-Seiten

#Core Web Vitals Rescue für KI-gebaute WordPress-Seiten: das Problem nach dem Build

Ein KI-Assistent kann eine WordPress-Seite an einem Nachmittag online stellen. Er kann nicht sagen, dass das vierte “Speed”-Plugin, das er empfohlen hat, gegen die zweite Cache-Ebene kämpft, die er zwei Prompts früher empfohlen hat. Betreiber finden das meist über einen PageSpeed-Insights-Screenshot mit roten Zahlen heraus, oder weil ein Stakeholder fragt, warum eine schnell aussehende Seite lädt wie im Jahr 2015. Das ist ein Rescue genau für dieses Fehlermuster: Core Web Vitals kaputt, weil der Build per Prompt zusammengesetzt wurde, nicht weil das Unternehmen bewusst ein schweres Theme gewählt hat.

Das ist ein engerer Service als allgemeine Geschwindigkeitsoptimierung. Ein Standard-Performance-Audit geht von bewussten, wenn auch unvollkommenen, architektonischen Entscheidungen über die Zeit aus. Dieser Rescue geht vom Gegenteil aus: einem Assistenten, der zehn separate Anfragen mit zehn separaten Plugin-Installationen in einer einzigen Bausitzung beantwortet hat, und einem Page-Builder, der Markup, CSS und JavaScript jedes Blocks ausliefert, unabhängig davon, was tatsächlich oberhalb des sichtbaren Bereichs erscheint.

#Warum KI-Builds Core Web Vitals zerstören

Drei Mechanismen zeigen sich in fast jedem KI-unterstützten Build, den wir öffnen, meist gemeinsam.

Plugin-Wildwuchs. Große Sprachmodelle führen kein Live-Inventar dessen, was bereits installiert ist. Prompt eins bekommt ein Formular-Plugin. Prompt fünfzehn bekommt ein zweites Formular-Plugin, weil das Modell sich nicht an Prompt eins erinnert. Jede Installation ist einzeln vertretbar; die kumulierte Last ist es nicht. Die anonymisierten Zahlen hinter diesem Muster haben wir in Plugin-Wildwuchs nach einem KI-Build dokumentiert: 38 aktive Plugins sind ein routinemäßiger Startpunkt für einen dreiwöchigen KI-unterstützten Build, kein Ausreißer.

Doppelte Optimierer. Die instinktive Antwort auf eine langsame Seite ist “installiere ein Cache-Plugin”. Ist TTFB eine Woche später noch immer hoch, lautet der nächste Prompt “installiere ein schnelleres Cache-Plugin”, oft ohne das erste zu deaktivieren. Wir finden regelmäßig zwei Full-Page-Caches, zwei Minifier und zwei Bild-Optimierungs-Plugins, die auf derselben Seite gegeneinander arbeiten, manchmal mit sporadisch defektem JavaScript, weil zwei Minifier dieselben Assets unterschiedlich umschreiben.

Render-blockierender Builder-Output. Page-Builder generieren generisches, wiederverwendbares Markup, damit jeder Block in jedem Layout funktioniert. Diese Generik bedeutet, dass jeder Block sein eigenes CSS und JS ausliefert, unabhängig von der Viewport-Position geladen. Ein mit einem Drag-and-Drop-Builder plus Addon-Paket gebauter Hero-Bereich liefert routinemäßig mehr render-blockierendes CSS aus, als die gesamte Seite tatsächlich braucht, was genau das ist, was LCP und INP auf Mobilgeräten ins Rote zieht.

Wir haben das bei einem Mittelstandskunden aus dem Maschinenbau gesehen, dessen WordPress-Seite auf Hetzner-Servern in Nürnberg lief: ein Page-Builder mit zwei zusätzlichen Addon-Paketen lieferte über 380 KB render-blockierendes CSS allein für den Hero-Bereich, obwohl oberhalb der Falz nur eine Headline und ein Werksfoto zu sehen waren. Nach dem Entfernen der Addon-Pakete und dem Umbau des Hero-Bereichs auf einen leichteren Block fiel LCP von 4,8s auf 2,1s auf Mobilgeräten, ohne dass der Hosting-Vertrag angerührt wurde.

#Beweis aus der Praxis: 38 Plugins auf 21, TTFB 1,47s auf 0,68s

Der klarste Beweis ist der anonymisierte Fall, vollständig dokumentiert in Plugin-Wildwuchs nach einem KI-Build. Eine B2B-Dienstleistungsseite, über etwa drei Wochen mit KI-unterstützten Tools gebaut, kam mit:

Hosting und Theme änderten sich nicht. Der Gewinn kam vom Entfernen doppelter SEO-, Cache- und Analytics-Plugins, dem Verschmelzen dreier Formular-Builder zu einem und dem Audit dreier Custom-mu-Plugins, die der Assistent generiert hatte, von denen zwei nach einer Sicherheitsprüfung gelöscht wurden. So sieht ein Core Web Vitals Rescue auf einer KI-gebauten Seite aus: meist Deinstallationen und Verschmelzungen, keine neue Infrastruktur.

#Triage-Tabelle: Symptom, Ursache, Aktion

Führen Sie das vor einem vollständigen Auftrag durch. Es zeigt, ob ein kurzer Durchgang reicht oder der Build einen gestuften Rückbau braucht.

Zeigen die meisten Zeilen auf isolierte Plugin-Duplikation, reicht meist ein fokussierter Rückbau. Treten Custom-KI-Code, Plugin-Wildwuchs und defekte User-Flows gemeinsam auf, planen Sie den umfassenderen Rescue, statt Performance isoliert zu flicken.

#Gestufte Rückbaureihenfolge

Performance-Arbeit folgt einer festen Reihenfolge, damit ein Fix nicht vom nächsten Batch zunichte gemacht wird und Sicherheitslücken in Custom-Code nicht durch das Entfernen der Plugins offengelegt werden, die sie leise umgangen haben.

1. Neue Installationen einfrieren. Keine Plugin-Antwort, bis das Audit-Ledger existiert.
2. Doppelte Cache- und Optimierungs-Plugins zuerst entfernen. Zwei gegeneinander arbeitende Full-Page-Caches sind die häufigste Ursache für inkonsistente PageSpeed-Ergebnisse; das vor allem anderen beheben.
3. Custom-KI-Code auditieren, bevor kommerzielle Plugins darum herum gelöscht werden. Hängt ein generiertes mu-Plugin still von einem Plugin ab, das Sie gerade entfernen, bricht das Löschen des Plugins zuerst die Seite.
4. Überlappende Tools in Batches von fünf bis acht verschmelzen, Checkout und Formulare nach jedem Batch testen, TTFB und Abfragezahl messen.
5. Render-Pfad-Probleme auf den verkehrstragenden Templates beheben: nicht kritisches JS verzögern, explizite Bild- und Font-Maße ergänzen, Addon-Nutzung des Builders im Hero reduzieren.
6. Neu messen und ein Plugin-Budget festlegen, damit die nächste KI-unterstützte Änderung dieselben Lücken nicht wieder öffnet.

#Mess-Checkliste: LCP, INP, CLS und TTFB

Alle vier zusammen verfolgen. Ein PageSpeed-Wert allein verschleiert, welche konkrete Metrik den geschäftlichen Einfluss tatsächlich treibt.

• LCP (Largest Contentful Paint) - Ziel unter 2,5s. Auf dem tatsächlichen Hero-Template messen, nicht auf einer leichten Testseite.
• INP (Interaction to Next Paint) - Ziel unter 200ms. Auf einer Seite mit Formular oder Filter testen, wo Nutzer tatsächlich interagieren.
• CLS (Cumulative Layout Shift) - Ziel unter 0,1. Mit vorhandenem Cookie-Banner und lazy-geladenen Bildern testen, da diese häufige CLS-Quellen auf KI-gebauten Seiten sind.
• TTFB (Time to First Byte) - Ziel unter ~800ms ungecacht auf einer Standardseite. Mit curl oder WebPageTest über fünf Durchläufe messen und den Median verwenden, nicht eine einzelne Probe.
• Datenbankabfragen pro Aufruf - mit Query Monitor verfolgen; alles über etwa 120 auf einer Content-Seite markieren.

Messen Sie auf Startseite, der schwersten Landingpage und Checkout oder Kontakt. Eine Seite, die auf der Startseite schnell und im Checkout langsam aussieht, ist ein häufiges KI-Build-Muster, weil builder-schwere Seiten selten diejenigen sind, die zuletzt jemand getestet hat.

#Was Sie nicht tun sollten

• Kein weiteres Optimierer-Plugin installieren, um eine langsame Seite zu beheben, die durch zu viele Plugins verursacht wurde. So kommen Seiten überhaupt erst auf 40 Plugins.
• Keine zwei Full-Page-Caches “sicherheitshalber” betreiben. Einen wählen und richtig konfigurieren.
• Custom-KI-generierte mu-Plugins nicht löschen, bevor Sie auditiert haben, worauf sie sich stützen. Manche patchen still eine Lücke, die ein anderes Plugin offen gelassen hat.
• Keinen synthetischen 100er-PageSpeed-Wert jagen zulasten echter LCP/INP/CLS auf den umsatztragenden Templates.
• Checkout- und Kontaktseiten nicht ungemessen lassen, weil “die Startseite ist ja in Ordnung”. Builder-schwere Nebenseiten sind meist der Ort, an dem die schlechtesten Zahlen leben.

#Wie der Auftrag abläuft

Schritt 1 - Basis. Wir messen LCP, INP, CLS und ungecachtes TTFB auf repräsentativen Templates, plus eine vollständige Plugin- und Datenbank-Inventur.

Schritt 2 - Audit. Jedes Plugin wird seiner tatsächlichen Aufgabe zugeordnet; Duplikate und render-blockierender Builder-Output werden markiert.

Schritt 3 - Gestufter Rückbau. Batches von fünf bis acht Plugins, deaktiviert, getestet, gemessen, dann gelöscht. Keine Massenlöschungen in Produktion.

Schritt 4 - Render-Pfad-Fixes. Nicht kritische Skripte verzögern, Bild- und Font-Ladeverhalten beheben, auf eine Cache-Ebene konsolidieren.

Schritt 5 - Neumessung und Budget-Festlegung. Gleiche Templates, gleiche Tools, dokumentiertes Vorher/Nachher, plus eine Regel, dass kein neues Plugin ohne Ablösung oder Verschmelzung eines bestehenden ausgeliefert wird.

#Verwandte Services und Vertiefungen

Dieser Rescue steht neben der breiteren Sanierungsarbeit, die wir an generierten Seiten leisten:

Blog-Vertiefung: Plugin-Wildwuchs: wenn ein KI-Build Sie 40 Plugins tief zurücklässt - der vollständige anonymisierte Fall hinter den oben verwendeten Zahlen.

Die Preisgestaltung ist individuell und wird nach dem Basis-Audit festgelegt. Kontaktieren Sie uns mit der Seite und einer kurzen Notiz, wie sie gebaut wurde.