WordPress wird nicht einfach „langsam“, weil ein Schalter auf „falsch“ steht. Es sind meist viele kleine Schalter, die zusammenkommen: Datenbankzugriffe, PHP-Ausführungen, Theme-Logik, Third-Party-Skripte, Bilder oder Cache-Ebenen. Wer Performance nachhaltig verbessern will, braucht einen Messrahmen, der vor- und nachher vergleichbar machen lässt.
Was Core-Web-Vitals und TTFB tatsächlich messen
Core-Web-Vitals (CWV) sind auf Nutzererlebnis optimiert. Meist stehen drei Metriken im Fokus: Largest Contentful Paint (LCP) für Ladeerlebnis, Interaction to Next-Paint (INP) für Reagierbarkeit, Cumulative-Layout-Shift (CLS) für visuelle Stabilität.
Zielwerte zu kennen ist für den Praktiker nützlich. Für LCP gilt als „gut“ ein Wert von 2,5 Sekunden oder weniger, gemessen am 75. Perzentil realer Seitenaufrufe. Für INP wird ein Wert von 200 Millisekunden oder weniger gut beschrieben, wieder bezogen auf das 75. Perzentil.
TTFB (Time to First Byte) ergänzt diese Sicht, weil es die Zeit bis zum ersten Byte der Serverantwort misst. Vereinfacht gesagt, wie schnell geben Server, Anwendung und Datenbank die erste Reaktion zurück. Im Hosting-Kontext kommt die Frage auf, ob schneller Storage überhaupt noch eine Rolle spielt. Als Einstieg für NVMe basiertes Webhosting in der Schweiz sollten Storage-Profile zunächst explizit definiert werden.
WordPress-Bremsen: Die üblichen Verdächtigen und ihre Reihenfolge
Läuft WordPress nicht so, wie gewünscht, dann sind die Ursachen meist an drei großen Rädchen zu finden. Anwendung, Inhalte, Infrastruktur.
- Anwendung: PHP und Datenbankarbeit
Zahlreiche Themes und Plugins bauen unnötige Queries auf, laden viel zu große Options oder machen Remote Requests. Hier hat ein persistent konfigurierter Object Cache häufig großen Effekt, weil WordPress Objektdaten von teurer langsamer Quelle in eine schnelle Ablage verschiebt und über Requests hinweg bereitstellt.
Praktischer Effekt: weniger Datenbanklast, stabilere TTFB, weniger Schwankungen bei angemeldeten Nutzern oder dynamischen Seiten. - Inhaltsebene: LCP-Kandidat und Bildgewicht
LCP-Kandidat ist oft ein Hero-Bild oder ein großer Textblock. Ist dieses Element groß und wird spät geladen, leidet LCP.
Konkret: Bildformat, responsive Größen, Lazy Load nur da, wo es LCP-Kandidaten nicht betrifft, kritisches CSS für Above the Fold. - Infrastruktur: CPU, PHP Runtime, Storage, Netzwerk
Hier gehören PHP-Version, OPcache, Datenbank-Parameter, http-Protokoll, Caching am Edge und Storage-Eigenschaften hinein. Wenn Datenbank I/O dominiert, hilft schneller Storage. Wenn aber JavaScript den Main Thread blockiert, bringt Storage kaum etwas.
NVMe richtig einordnen
NVMe ist ein Speicherprotokoll, das für eine sehr parallele Datenübertragung mit geringem Overhead konzipiert wurde. Im Vergleich zu SATA kann es eine größere Anzahl an Command Queues unterstützen, was besonders in I/O-intensiven Workloads von Vorteil ist.
Für WordPress spielt dies eine Rolle, wenn zahlreiche Datenbankzugriffe tatsächlich auf der Festplatte stattfinden. Dies kann zum Beispiel geschehen, wenn die Caching-Einstellungen zu gering sind, eine hohe Gleichzeitigkeit herrscht oder die Workloads kaum Cache-Treffer aufweisen. In solchen Situationen kann NVMe dazu beitragen, die I/O-Wartezeiten zu verringern, was wiederum die Time to First Byte (TTFB) positiv beeinflussen kann.
Jedoch gibt es auch klare Grenzen. Wenn ein Plugin beispielsweise 25 externe Anfragen sendet oder wenn ein Theme sehr große CSS- und JS-Dateien bereitstellt, wird NVMe nicht der Engpass sein. Dann steigt zwar die Server-Geschwindigkeit, die Nutzer-Metriken sind aber zäh, weil die Frontend-Arbeit überwiegt.
Ein Messplan, der etwas taugt
Ein Plan, der etwas taugt, braucht keinen Overhead, aber Regeln.
- Schritt 1: Baseline aufnehmen
Drei URLs auswählen: Startseite, eine typische Inhaltsseite, eine dynamische Seite (z.B. Suche, Shop-Kategorie). Pro URL aufschreiben: LCP, INP, CLS, TTFB, Seitengewicht, Anzahl Requests. Zielwerte in der Core-Web-Vitals-Übersicht sind dabei der Referenzrahmen. - Schritt 2: TTFB Ursachen trennen
TTFB ist nicht nur Server. Sondern auch Netzwerk und TLS. Daher macht es Sinn, einmal aus zwei Perspektiven zu schauen: einmal vom eigenen Browser aus, einmal von einem externen Test-Standort. Große Unterschiede weisen auf Netzwerk- oder Regionseffekte hin. - Schritt 3: Änderungen in Paketen anpacken
Nicht zehn Dinge auf einmal, sondern ein Paket pro Iteration. Beispiel Paket A: Object Cache plus Datenbank-Entlastung. Beispiel Paket B: Hero-Bild optimieren plus kritisches CSS. Beispiel Paket C: Drittanbieter-Skripte reduzieren oder verzögern. - Schritt 4: Re Test und Dokumentation
Nach jeder Änderung die gleichen Werte erneut abfragen. WordPress-Performance-Arbeit wird in der Community zunehmend anhand messbarer Kennzahlen betrachtet. Zum Beispiel in Rückblicken zu Core-Web-Vitals-Effekten. Das ist ein geeigneter Maßstab: Änderungen zählen nur, wenn sie messbar sind.
Konkrete nächste Schritte
- Drei repräsentative Seiten auswählen und eine Baseline aus LCP, INP, CLS und TTFB erstellen.
- Den größten Hebel identifizieren: hohe TTFB oder hohe Frontend-Last.
- Ein erstes Paket umsetzen, oft ist ein persistenter Object Cache ein sinnvoller Kandidat, weil WordPress damit teure Zugriffe vermeidet
- Danach Bilder und LCP-Kandidat prüfen und nur den sichtbaren Hauptinhalt priorisieren.
- Erst wenn Datenbank und I/O als Engpass erkennbar sind, Hosting-Kriterien wie NVMe als Performance-Baustein bewerten und die Auswahl daran knüpfen.
Wer diesen Ablauf einhält, bekommt keine „gefühlte“ Beschleunigung, sondern eine nachvollziehbare Verbesserung mit Zahlen. Das ist die Grundlage, um die WordPress-Performance dauerhaft stabil zu halten, auch wenn Plugins, Inhalte und Traffic wachsen.
