Sie haben Ihre WordPress-Seite optimiert, PageSpeed Insights zeigte grüne Werte, und sechs Monate später ist alles wieder rot. Das ist kein Einzelfall. Core Web Vitals sind kein Zustand, den man einmal herstellt und dann abhakt - sie sind ein Spiegel des laufenden Betriebs. Neue Plugins, Theme-Updates, ein Mitarbeiter der unkomprimierte Fotos hochlädt, ein Caching-Plugin das nach einem Update nicht mehr korrekt arbeitet: all das frisst die hart erarbeiteten Verbesserungen langsam wieder auf.

In diesem Artikel erkläre ich, warum WordPress-Seiten strukturell schlechtere TTFB-Werte haben als andere Plattformen, was INP genau bremst, und wie ein monatlicher Performance-Check als fester Wartungsbaustein konkret aussieht - mit Schwellenwerten, Tools und klaren Prüfpunkten. Wer sich fragt, was so ein Wartungspaket vollständig umfasst und kostet, findet dazu mehr auf der Seite WordPress-Wartung als Service: Leistungen, Umfang und Kosten.

Warum nur 32 Prozent der WordPress-Seiten einen guten TTFB haben

Die Zahl klingt ernüchternd, ist aber gut erklärbar. Laut CrUX-Daten - dem Chrome User Experience Report, den Google aus echten Nutzerdaten erhebt - erreichen nur etwa 32 Prozent aller WordPress-Installationen einen TTFB unter 800 ms, den Google als "gut" einstuft. Praktisch bedeutet das: Zwei von drei WordPress-Seiten starten schon beim ersten Byte mit einem Handicap, das kaum durch Frontend-Optimierungen auszugleichen ist.

Die Hauptursache ist Hosting-Qualität, nicht WordPress selbst. Shared Hosting ohne Server-seitiges Caching liefert TTFB-Werte von 1.200 bis über 2.000 ms. Managed WordPress Hosting mit Full-Page-Cache auf Serverebene und einem CDN erreicht dagegen 150 bis 300 ms. Diese Lücke ist durch kein Plugin zu schließen. Wer ein Hosting-Upgrade erwägt, lohnt sich ein Blick in den Artikel EU-Hosting für WordPress: Serverstandort und DSGVO.

32%WordPress-Seiten mit gutem TTFB lt. CrUX
800 msTTFB-Grenze für "gut" nach Google
44%WordPress-Seiten mit guten Core Web Vitals gesamt (mobil)
200 msINP-Schwellenwert für "gut" nach Google

Was viele übersehen: Ein gutes Hosting ist Voraussetzung, keine Garantie. Selbst auf schnellem Server kann TTFB schleichend schlechter werden, wenn das Caching-Plugin nach einem WordPress-Update in einen Fehlerzustand gerät und plötzlich keine Cache-Dateien mehr ausliefert - das System lädt dann jede Seite dynamisch aus der Datenbank. Das passiert öfter als man denkt, und ohne Monitoring fällt es wochenlang nicht auf.

INP: warum der Main Thread das eigentliche Problem ist

INP (Interaction to Next Paint) löste im März 2024 FID (First Input Delay) als Core Web Vital ab. Es misst, wie lange der Browser braucht, um auf eine Nutzerinteraktion - Klick, Tipp, Tastatureingabe - zu reagieren und die Seite neu zu rendern. Der Grenzwert: unter 200 ms gilt als gut, über 500 ms als schlecht.

WordPress hat beim INP strukturell eine bessere Ausgangslage als beim TTFB: Laut CrUX-Daten bestehen rund 85 bis 86 Prozent der WordPress-Seiten den INP-Test. Das Problem liegt trotzdem nahe. Es reicht ein einziges falsch konfiguriertes Plugin, das JavaScript synchron in den <head> lädt, um den Main Thread so zu blockieren, dass Klicks mit über 300 ms Verzögerung reagieren.

Page-Builder wie Elementor laden standardmäßig JavaScript-Module für alle Widgets - auch für Widgets, die auf der jeweiligen Seite gar nicht vorkommen. Wer Elementor einsetzt und INP-Probleme hat, sollte zuerst unter Elementor > Einstellungen > Experimente die Funktion "Optimiertes Asset-Loading" aktivieren.

Die häufigsten INP-Killer bei WordPress-Projekten, die ich in 13 Jahren und über 120 Projekten gesehen habe:

  • Consent-Management-Plattformen (CMP), die ihren JavaScript-Bundle synchron im <head> laden
  • Analytics und Tag Manager ohne defer oder async
  • Chat-Widgets externer Anbieter (Intercom, Tidio, HubSpot), die auf allen Seiten laden, auch wo kein Chat gezeigt wird
  • WooCommerce-Filterleisten mit Live-AJAX ohne Debouncing - jeder Tastendruck feuert sofort eine Anfrage
  • Slider-Plugins mit Bibliotheken wie GSAP oder Swiper, die auch auf einfachen Textseiten geladen werden

Ein schneller Diagnoseweg: Chrome DevTools > Performance > Record, Seite laden, dann auf ein Element klicken. Im Flame Chart sieht man genau, welche Skripte den Main Thread belegen. Wer lieber ein WordPress-Plugin nutzt, findet im Artikel Langsame WordPress-Seite: Plugin finden mit Query Monitor einen praxisnahen Einstieg.

Wie Performance sich über Zeit verschlechtert

Ein konkretes Beispiel aus meiner Arbeit: Ein Kunde aus Hamburg betreibt einen WooCommerce-Shop. Anfang 2024 hatten wir gemeinsam optimiert - LiteSpeed Cache konfiguriert, Bilder komprimiert, INP durch Plugin-Bereinigung auf 120 ms gedrückt. Grün auf ganzer Linie.

Zehn Monate später kam er zurück. PageSpeed Mobile: 51 Punkte, TTFB 1.100 ms, INP 380 ms. Was war passiert? In dieser Zeit hatte er drei neue Plugins aktiviert (darunter ein Live-Chat und ein Bewertungs-Widget), ein Fotograf hatte 40 Produktbilder als JPEG ohne Komprimierung hochgeladen - jedes zwischen 3 und 8 MB groß - und nach einem LiteSpeed-Cache-Update hatte der Browser-Cache aufgehört zu funktionieren, weil eine Einstellung zurückgesetzt worden war.

Keines dieser Ereignisse war dramatisch. Zusammen hatten sie die Seite in zehn Monaten auf das Ausgangsniveau vor der Optimierung zurückgebracht.

Typische Performance-Killer im Betrieb

EreignisAuswirkung auf TTFBAuswirkung auf INP
Neues Plugin mit synchronem JSgeringhoch
Unkomprimierte Bilder (über 1 MB)mittel (größere HTML-Responses)mittel (Layout-Shifts, LCP)
Caching-Konfiguration zurückgesetztsehr hochgering
Theme-Update mit neuem CSS-Bundlegeringmittel
Neuer Cookie-Banner ohne defergeringhoch
CDN abgelaufen oder deaktivierthochgering

Der monatliche Performance-Check: konkrete Prüfpunkte

Ein monatlicher Check dauert 30 bis 45 Minuten, wenn man weiß, wo man schaut. Ich gehe dabei immer in derselben Reihenfolge vor.

Monatlicher WordPress Performance-Check

  • Google Search Console öffnen, Bericht "Core Web Vitals" prüfen - gibt es neue URLs in der Kategorie "Schlecht" oder "Verbesserung erforderlich"?
  • PageSpeed Insights für die Startseite, eine Kategorieseite und eine Produktseite ausführen - alle drei, weil Probleme oft nur auf bestimmten Seitentypen auftreten
  • TTFB aus den Felddaten ablesen (nicht nur Labordaten) - liegt er über 800 ms, sofort Caching-Status prüfen
  • Im Cache-Plugin prüfen: Wurden alle Cache-Typen nach dem letzten Update korrekt geleert und neu aufgebaut? Ist Browser-Caching noch aktiv?
  • Im WordPress-Backend: Welche Plugins wurden im letzten Monat aktiviert oder aktualisiert? Gibt es neue mit JavaScript im Frontend?
  • Medienbibliothek: Welche Bilder wurden neu hochgeladen? Dateien über 500 KB identifizieren und nachträglich komprimieren (ShortPixel oder Imagify eignen sich gut)
  • Chrome DevTools Lighthouse einmal auf mobil ausführen - Abschnitt "Diagnostics" zeigt Main Thread Work und Render-Blocking Resources
  • Uptime-Monitoring-Log der letzten 30 Tage sichten - gab es Ausfälle oder Antwortzeiten über 2 Sekunden?

Die Search Console ist dabei der wichtigste Ausgangspunkt, weil sie echte Nutzerdaten zeigt - keine Labormessungen. Wenn dort grüne URLs plötzlich in den gelben oder roten Bereich wandern, ist das ein Alarmsignal das keine weiteren Beweise braucht.

Schwellenwerte, die man auswendig kennen sollte

Für die tägliche Arbeit reichen diese Werte als Orientierung:

  • TTFB: unter 800 ms (gut), unter 200 ms (sehr gut auf Managed Hosting erreichbar)
  • LCP: unter 2.500 ms (gut), unter 1.200 ms (exzellent)
  • INP: unter 200 ms (gut), unter 100 ms (exzellent)
  • CLS: unter 0,1 (gut), unter 0,05 (exzellent)

Bei mobilen Messungen sind die Werte naturgemäß schlechter als auf Desktop. Google gewichtet die mobilen Felddaten stärker. Eine Seite, die auf Desktop grün ist, aber auf Mobilgeräten rote INP-Werte zeigt, hat ein Problem.

Den CrUX-Verlauf einer Domain kann man kostenlos im PageSpeed Insights Abschnitt "Felddaten" über Zeit beobachten. Google zeigt dort die letzten 28 Tage. Für Trends über mehrere Monate nutzen Sie das Chrome UX Report Dashboard auf Looker Studio (kostenfrei, Google-Konto nötig).

Caching: der unsichtbare Einzel-Fehlerpunkt

Caching ist die wirkungsvollste Maßnahme für TTFB und gleichzeitig die fragile. Ein richtig konfiguriertes Full-Page-Cache kann TTFB von 1.500 ms auf unter 200 ms drücken. Aber Cache-Konfigurationen können durch Plugin-Updates, WordPress-Core-Updates oder schlicht durch einen Konflikt mit einem neuen Plugin stillschweigend aufhören zu funktionieren.

Vorteile

  • Full-Page-Cache reduziert TTFB dramatisch - Faktor 5 bis 10 ist realistisch
  • Browser-Caching reduziert Folgeseitenladevorgänge stark
  • Object-Caching (Redis) entlastet die Datenbank bei WooCommerce-Shops spürbar
  • Einmalig richtig konfiguriert, läuft er weitgehend selbstständig

Nachteile

  • Cache muss nach Plugin-Updates manuell oder automatisch geleert werden
  • Falsch konfigurierter Cache liefert veraltete Preise oder Lagerbestände aus
  • Konflikte mit Membership-Plugins oder Login-Seiten können zu falschen Ausgaben führen
  • Kein Cache-Plugin ersetzt gutes Hosting - auf langsamem Server bringt Caching weniger

Aus der Praxis: LiteSpeed Cache ist auf LiteSpeed-Servern die erste Wahl und liefert in Tests 2026 eine gute Basis. WP Rocket bleibt auf Apache- und Nginx-Servern die zuverlässigste Option, wenn man keine Zeit für tiefes Feintuning hat. NitroPack schneidet in aktuellen Benchmarks mit 54 Prozent Core-Web-Vitals-Bestehensrate führend ab, ist aber cloudbasiert und schickt Ihre Seiteninhalte durch externe Server - für DSGVO-bewusste Betreiber ein Punkt zum Überdenken.

Bilder: der unterschätzte Dauerbrenner

In jedem längeren Wartungsvertrag sehe ich dasselbe Muster: Die initiale Optimierung komprimiert alle vorhandenen Bilder, konfiguriert WebP-Ausgabe und lazy loading. Dann beginnt der laufende Betrieb. Sechs Monate später hat jemand 80 neue Produktfotos hochgeladen - direkt aus Lightroom exportiert, jedes 4 bis 12 MB groß, keine automatische Komprimierung aktiv.

Das Ergebnis ist nicht nur schlechtes LCP, sondern auch erhöhter Hosting-Speicher und langsamere Backups. Ein Bild-Optimierungs-Plugin, das automatisch beim Upload komprimiert, ist keine optionale Komfortfunktion, sondern Wartungsinfrastruktur.

ShortPixel und Imagify bieten beide automatische Komprimierung beim Upload an. ShortPixel verrechnet nach Bildanzahl (Credits), Imagify nach Datenmenge. Für einen Shop mit vielen monatlichen Uploads lohnt ein Abo-Modell. Wer nachträglich optimieren möchte, kann mit dem WP-CLI-Befehl wp media regenerate und dem jeweiligen Plugin-CLI alle vorhandenen Bilder neu verarbeiten lassen.

Neue Plugins: das Nadelöhr, das niemand beachtet

Jedes neu aktivierte Plugin ist eine potenzielle Performance-Baustelle. Das bedeutet nicht, keine Plugins nutzen zu sollen - WordPress lebt davon. Aber jeder Plugin-Aktivierung sollte ein schneller Test folgen: PageSpeed Insights vor und nach der Aktivierung, und ein Blick in die Query Monitor-Ausgabe ob neue Datenbankabfragen hinzugekommen sind.

Besonders aufmerksam sein sollte man bei Plugins, die:

  • JavaScript in den <head> laden (statt <footer>)
  • externe Skripte von Third-Party-Domains einbinden
  • bei jedem Seitenaufruf Datenbankabfragen im zweistelligen Bereich auslösen
  • Shortcodes nutzen die auch auf Seiten laden wo der Shortcode gar nicht verwendet wird

Das klingt nach viel Aufwand - ist es aber nicht, wenn man es zur Gewohnheit macht. Zehn Minuten nach einer Plugin-Aktivierung genügen für einen ersten Plausibilitätscheck. Wer wissen will, welches Plugin konkret bremst, findet dazu eine ausführliche Anleitung im Artikel Langsame WordPress-Seite: Plugin finden mit Query Monitor.

Wenn Sie auf der Suche nach einem Entwickler sind, der Performance-Wartung als Teil eines laufenden WordPress-Betreuungspakets anbietet, zeige ich auf der Seite Webseiten von dawidweb.com was solch ein Paket konkret beinhaltet und was es kostet.

Performance-Wartung als Vertragsbestandteil

Performance ist kein Projektleistung die man abschließt. Sie ist ein Betriebszustand den man hält. Das bedeutet konkret: Jeder professionelle Wartungsvertrag sollte Performance-Monitoring explizit benennen und nicht als selbstverständlich voraussetzen.

Aus meiner Erfahrung mit KMU in Deutschland funktioniert folgendes Modell gut:

  • Monatlicher automatisierter Report aus PageSpeed Insights API (ein Skript, das die wichtigsten URLs prüft und Ergebnisse per Mail schickt)
  • Manueller Check mit Kommentar beim Kunden alle 30 Tage
  • Sofortiger Check nach jedem Plugin-Update das als kritisch markiert ist
  • Jährliches Peformance-Audit mit vollständiger Neuanalyse aller Seiten-Typen

Die Kosten für diesen Zusatz im Wartungsvertrag bewegen sich bei 20 bis 40 Euro monatlich - verglichen mit den 300 bis 800 Euro die eine einmalige Optimierung kostet, die ohne Pflege nach einem Jahr verfallen ist, ist das wirtschaftlich eindeutig.

Wer prüfen möchte was günstige Pauschalpakete wirklich leisten, und wo deren Grenzen liegen, findet dazu mehr unter WordPress-Wartung als Service: Leistungen, Umfang und Kosten.

Häufige Fragen

Warum verschlechtern sich meine Core Web Vitals, obwohl ich sie einmal optimiert hatte?

Neue Plugins, Theme-Updates, manuell hochgeladene Bilder ohne Komprimierung und ein Caching-Plugin, das nach einem Update nicht mehr korrekt konfiguriert ist - all das summiert sich. Performance ist kein Einmal-Projekt, sondern ein laufender Prozess, der regelmäßige Prüfung braucht.

Was ist ein guter TTFB-Wert für WordPress?

Google stuft TTFB unter 800 ms als 'gut' ein. Praktisch sollten Sie auf Managed Hosting mit Server-seitigem Caching und CDN unter 200 ms anstreben. Shared Hosting ohne Caching liegt häufig über 1.500 ms und macht gute LCP-Werte fast unmöglich.

Was verursacht schlechte INP-Werte bei WordPress?

Zu viel JavaScript auf dem Main Thread. Die häufigsten Quellen sind Page-Builder mit vielen geladenen Widget-Modulen (zum Beispiel Elementor), Consent-Management-Plattformen die synchron laden, Analytics-Skripte ohne defer-Attribut und externe Chat-Widgets.

Wie oft sollte ich eine WordPress-Seite auf Performance prüfen?

Mindestens einmal im Monat sollten TTFB und Core Web Vitals in der Google Search Console sowie PageSpeed Insights geprüft werden. Nach jedem größeren Plugin-Update oder Redesign auch außer der Reihe.

Welche Tools brauche ich für einen monatlichen Performance-Check?

Google PageSpeed Insights für aktuelle Felddaten, Google Search Console (Bericht 'Core Web Vitals'), Query Monitor für langsame Datenbankabfragen und schwere Plugins, und Chrome DevTools (Lighthouse) für eine detaillierte Analyse des Main Threads.

Lohnt sich ein Wartungsvertrag mit Performance-Monitoring?

Ja. Eine einmalige Optimierung kostet zwischen 300 und 800 Euro, verfällt aber ohne Pflege binnen eines Jahres. Ein monatlicher Wartungsvertrag ab etwa 50 bis 80 Euro, der Performance explizit einschließt, schützt diese Investition dauerhaft.


, , , , ,