WordPress langsam trotz Optimierung: die Diagnose

Sie haben getan, was alle empfehlen: Caching-Plugin aktiviert, Bilder komprimiert, vielleicht sogar auf ein teureres Hosting gewechselt. Und trotzdem fühlt sich die Seite zäh an. Das ist die häufigste Frustration in unseren KMU-Audits — und sie hat fast nie mit einem fehlenden Trick zu tun. Sie hat mit der Reihenfolge zu tun. Wer am Frontend schraubt, während der Server 1,5 Sekunden für das erste Byte braucht, poliert die Fassade eines Hauses mit Riss im Fundament.

Performance in WordPress ist ein Stapel: TTFB, Autoload, Render-Blocking, Datenbank, Theme. Jede Schicht liegt auf der darunter. Eine späte Schicht zu optimieren, während eine frühere blutet, verschiebt nur Symptome — die Wartezeit bleibt. Dieser Artikel liefert den geordneten Diagnose-Entscheidungsbaum vom Symptom zur Ursache zum Hebel. Wenn Sie die Werte für Ihre eigene Seite noch nicht kennen, liefert der kostenlose Website-Check für TTFB und Render-Blocking in unter einer Minute die Startmesswerte für Schritt 1.

Und vorweg, weil es ehrlich gesagt sein muss: In über 90 % der Fälle endet diese Diagnose nicht bei Headless. Sie endet bei einer reparierten Schicht zwischen TTFB und Theme. Wer wissen will, wie die zugrundeliegenden Metriken sauber erhoben werden, findet das in unserem Leitfaden, wie man die Core Web Vitals von WordPress richtig misst.

Warum bleibt WordPress langsam, obwohl ich schon optimiert habe?

Meist wird in der falschen Reihenfolge optimiert. Caching, Bildkompression und ein neues Theme helfen nichts, wenn der Server 1,5 Sekunden fürs erste Byte braucht. Performance ist ein Stapel — eine späte Schicht zu tunen, während eine frühere blutet, verschiebt nur Symptome. Die Wartezeit bleibt, nur die Diagnose verschiebt sich.

Der häufigste Fehler ist Optimierung ohne Messung. „Ich habe ein Caching-Plugin installiert" ist kein Befund, sondern eine Hoffnung. Jede Schicht im Stapel hat ihre eigene Metrik, und ohne diese Metrik raten Sie. Caching-Plugins kaschieren besonders gern ein TTFB-Problem, statt es zu lösen: Sie liefern die zuvor erzeugte, statische Version einer Seite schneller aus — aber jede ungecachte Route (Login, Warenkorb, interne Suche, eingeloggte Nutzer) trifft weiterhin den echten, langsamen Server.

Google nennt im offiziellen Performance-Leitfaden einen TTFB von 0,8 Sekunden oder weniger als gut, über 1,8 Sekunden als schlecht (web.dev, TTFB). Entscheidend ist der dort genannte Satz: TTFB geht jeder anderen aussagekräftigen Lade-Metrik voraus. Solange die erste Schicht blutet, ist Frontend-Tuning verschwendete Mühe — und genau hier landen die meisten gut gemeinten Optimierungsversuche.

Der Diagnose-Entscheidungsbaum: Symptom zu Ursache zu Hebel

Arbeiten Sie die folgende Tabelle strikt von oben nach unten ab. Jede Zeile nennt das Symptom, die wahrscheinliche Ursache, die konkrete Messung und den Hebel. Reparieren Sie eine Zeile vollständig, bevor Sie zur nächsten gehen — so vermeiden Sie es, an der falschen Schicht zu arbeiten. Die Reihenfolge der Zeilen ist die eigentliche Botschaft, nicht die einzelne Zeile.

Jeder dieser Schritte ist an eine messbare Schwelle gekoppelt, nicht an ein Gefühl. Der Website-Check liefert TTFB, Render-Blocking und Page-Weight als Startwerte für die Zeilen eins und drei — die übrigen brauchen WordPress-interne Werkzeuge, die wir gleich benennen.

Schritt 1: TTFB und Hosting — der Server antwortet zu langsam

TTFB ist die erste Schicht, weil sie jeder anderen Metrik vorausgeht. Google nennt unter 0,8 Sekunden gut; Seiten mit schlechtem LCP verbringen laut Web Almanac rund 2,27 Sekunden allein im TTFB — fast die gesamte Schwelle für ein gutes LCP von 2,5 Sekunden (Web Almanac 2024, Performance). Das ist der grösste Einzelhebel im ganzen Stapel.

Messen Sie ehrlich. Der TTFB einer gecachten Startseite ist nicht aussagekräftig — er zeigt nur, wie schnell Ihr Cache ein fertiges HTML-Dokument ausliefert. Den echten Server-TTFB sehen Sie auf ungecachten Routen: Warenkorb, Login, interne Suche, eingeloggte Sitzungen. Liegen diese deutlich über 0,8 Sekunden, haben Sie ein Server-Problem, das kein Frontend-Trick löst. Im Browser finden Sie den Wert unter „Server-Timing" in den Chrome DevTools, plattformübergreifend im Website-Check.

Die häufigste Ursache ist billiges Shared Hosting, auf dem hunderte Seiten um dieselbe CPU konkurrieren. Der zweite grosse Hebel ist ein persistenter Object-Cache (typischerweise Redis): Er lässt Optionen und wiederholte Datenbank-Abfragen aus dem Arbeitsspeicher statt von der Platte laden und senkt damit DB-Trips und TTFB spürbar (WordPress-Core, Optimization).

Schritt 2: Autoload-Bloat in wp_options — die schleichende Verlangsamung

Wird WordPress mit der Zeit immer langsamer, ist oft die wp_options-Tabelle schuld. Plugins markieren Optionen als autoload und lassen Datenmüll beim Deinstallieren zurück — dieser wird bei jedem einzelnen Seitenaufruf geladen, gecacht oder nicht. WordPress 6.6 warnt im Site-Health ab 800 KB Autoload und deaktiviert einzelne Optionen über dem Standardwert automatisch.

Konkret: Seit WordPress 6.6 markiert ein Site-Health-Check Autoload-Daten über 800 KB als kritisch für die Performance (WordPress 6.6 Performance Improvements). Zusätzlich deaktiviert der Core das Autoloading einzelner Optionen über dem Standardwert von 150 000 Bytes automatisch, steuerbar über den Filter wp_max_autoloaded_option_size (Options API, Disabling Autoload). Die Core-Dokumentation empfiehlt, die gesamten Autoload-Optionen einer Seite unter 800 KB zu halten (WordPress-Core, Optimization).

Messen Sie über den Site-Health-Check unter „Werkzeuge → Zustand der Website" oder direkt per SQL über eine Abfrage auf autoload='yes'. Der häufigste Auslöser sind verwaiste Optionen gelöschter Plugins — Einträge, die niemand mehr nutzt, aber jede Anfrage verlangsamen.

Autoload-Bloat ist die schleichendste Performance-Bremse in WordPress: Sie wächst mit jedem Plugin, das Sie je installiert haben — und mit jedem, das Sie je entfernt haben.

Der Hebel ist Präzision, nicht Brachialgewalt. Setzen Sie Autoload gezielt auf no für grosse, selten gebrauchte Optionen — leeren Sie nicht blind die ganze Tabelle, sonst zerschiessen Sie womöglich Einstellungen aktiver Plugins. Ein guter Object-Cache (Schritt 1) entschärft das Problem zusätzlich, weil er auch Nicht-Autoload-Optionen schnell verfügbar hält.

Schritt 3 und 4: Render-Blocking und Datenbank-Queries

Erst wenn Server und Autoload sauber sind, lohnt das Frontend. Render-Blocking CSS und JavaScript verzögern den ersten sichtbaren Pixel — und das Problem ist verbreiteter, als die meisten glauben: Laut Web Almanac 2025 bestehen nur 15 % der mobilen und 13 % der Desktop-Seiten den Render-Blocking-Resources-Audit (Web Almanac 2025, Performance). Parallel verschleppen langsame, nicht indizierte oder von Plugins verursachte Datenbank-Queries das TTFB von innen.

Beim Render-Blocking sind zwei Hebel entscheidend: kritisches CSS inlinen (das, was für den sichtbaren Bereich nötig ist, direkt im HTML), und nicht-kritisches JavaScript mit defer oder async aus dem kritischen Pfad nehmen. Das JavaScript-Volumen ist dabei der unterschätzte Faktor: Die mediane mobile Seite lädt 558 KB JavaScript, davon rund 206 KB ungenutzt (Web Almanac 2024, JavaScript). Jedes Kilobyte ungenutztes Skript muss trotzdem geladen, geparst und ausgewertet werden.

Für die Datenbank-Schicht ist das Werkzeug der Wahl Query Monitor: Das Plugin macht langsame, doppelte und von einzelnen Plugins verursachte Abfragen pro Seitenaufruf sichtbar. Ein einziges schlecht geschriebenes Plugin — etwa eines, das bei jedem Aufruf eine nicht indizierte Tabelle durchsucht — kann das gesamte TTFB dominieren. Der Hebel ist dann entweder ein fehlender Index oder, ehrlicher, der Austausch des Plugins.

Wichtig ist hier die Reihenfolge innerhalb der Schicht: Eine DB-Query, die Query Monitor mit 400 Millisekunden ausweist, fällt in die TTFB-Bilanz aus Schritt 1 hinein — sie verlangsamt den Server von innen, nicht das Frontend. Wer den Object-Cache aus Schritt 1 bereits gesetzt hat, hat viele dieser Query-Wiederholungen schon entschärft, weil identische Abfragen aus dem Arbeitsspeicher kommen. Erst die nach dem Object-Cache verbleibenden Queries sind echte Optimierungskandidaten.

Wer das JavaScript- und Bild-Gewicht systematisch angehen will, findet in unserem Beitrag zur Bildoptimierung als einzelner Performance-Hebel eine vertiefte Anleitung — Bilder sind oft der grösste Brocken im Page-Weight, aber eben nur eine von mehreren Schichten.

Schritt 5 und die ehrliche Grenze: Wann zahlt Caching nicht mehr?

Das Theme ist die letzte Schicht — aufgeblähte Page-Builder erzeugen DOM- und Skript-Last, die kein Cache wegoptimiert. Die architektonische Grenze ist erreicht, wenn jede ungecachte Interaktion langsam bleibt und Caching nur noch statische Sonderfälle rettet. Dann — und erst dann — lohnt der Blick auf eine andere Architektur. Die meisten Seiten erreichen diesen Punkt nie.

Theme- und Page-Builder-Last lässt sich nicht wegcachen, nur reduzieren. Ein Page-Builder, der für eine simple Landingpage 3 000 DOM-Knoten und ein Dutzend Skripte erzeugt, bleibt schwer — der Page-Cache liefert dieses schwere HTML nur schneller aus, macht es aber nicht leichter. Prüfen Sie die DOM-Grösse im Lighthouse-Bericht; alles jenseits einiger tausend Knoten ist ein Warnsignal.

Die ehrliche Caching-Grenze sieht so aus: Dynamische, personalisierte Seiten bleiben trotz Cache zäh. Ein Shop mit eingeloggten Kunden, ein Mitgliederbereich, eine Seite mit nutzerindividuellen Inhalten — hier greift der Page-Cache kaum, weil fast jede Antwort einzigartig ist. Wenn Sie die Schritte 1 bis 4 sauber abgearbeitet haben und die Seite immer noch nicht trägt, ist das ein Architektur-Befund, kein Optimierungs-Befund.

An diesem Punkt — und nur an diesem — wird eine entkoppelte Architektur relevant. Headless WordPress ist kein Performance-Trick, sondern eine Architektur-Entscheidung mit Break-even: eine Investition, die sich rechnet, wenn die Seite geschäftskritisch ist, viel publiziert oder personalisiert. Wann dieser Break-even erreicht ist, rechnen wir nüchtern durch im Beitrag dazu, wann sich Headless WordPress am Break-even lohnt — und wer die Grundlagen sucht, findet sie in der Erklärung, was Headless WordPress überhaupt ist. Dass schnellere Seiten messbar mehr Umsatz bringen, ist gut belegt — die Zahlen dazu stehen im Beitrag, warum Ladezeit direkt den Umsatz beeinflusst.

Aber bleiben wir ehrlich: Über 90 % der Fälle in unseren Audits sind in den Schritten 1 bis 4 gelöst. Wer mit „Headless" beginnt, bevor er den TTFB gemessen hat, kauft eine Architektur, um ein Hosting-Problem zu umgehen. Und das ist die unbequeme Wahrheit, die in keinem „10 Tipps für schnelleres WordPress"-Artikel steht: Die wenigsten Seiten brauchen einen neuen Trick. Sie brauchen die Disziplin, die vorhandenen Schichten in der richtigen Reihenfolge zu messen — und den Mut, einen Hosting-Wechsel oder das Entfernen eines Plugins als die eigentliche Lösung zu akzeptieren, auch wenn es weniger spektakulär klingt als eine Architektur-Umstellung.

Nächster Schritt

Die Diagnose ist nur so gut wie ihre erste Messung. Bevor Sie irgendetwas optimieren, holen Sie sich die Startwerte: Der Website-Check liefert TTFB, Render-Blocking und Page-Weight in unter einer Minute und sagt Ihnen, bei welcher Zeile der Tabelle Sie einsteigen.

Wenn Sie die Werte haben und unsicher sind, ob Sie noch in Schritt 1 bis 4 stecken oder bereits an der architektonischen Grenze, ordnen wir das in einem Erstgespräch ein — ohne Verkaufsdruck und mit der ehrlichen Antwort, wenn ein Hosting-Wechsel oder ein Plugin-Audit reicht. Was wir konkret prüfen und liefern, steht auf der Seite zu unseren Leistungen.