Ist Ihre Website auf WordPress langsam?

#Hosting ist selten die einzige Ursache

Eine langsame WordPress-Seite fühlt sich an wie ein Serverproblem. Oft liegt der Engpass aber in PHP, SQL oder Front-End-Assets. Besseres Hosting hilft nur dann, wenn CPU, Speicher oder I/O wirklich knapp sind. Wenn Theme und Plugins bei jedem Request Dutzende Abfragen feuern oder ein Hero-Bild unkomprimiert ausgeliefert wird, kaufen Sie nur teurere Wartezeit.

Dieser Leitfaden folgt einer Messreihenfolge: zuerst Time to First Byte (TTFB), dann Query Monitor auf Staging, danach Optionen-Autoload und Objekt-Cache, zuletzt die Core Web Vitals LCP, INP und CLS. So trennen Sie Hostingfehler von Codefehlern, bevor Sie irgendetwas umbauen.

Offizielle Referenzpunkte sind die web.dev-Artikel zu TTFB und LCP sowie die WordPress-Dokumentation zur Performance-Optimierung.

#TTFB messen, bevor Sie spekulieren

TTFB ist die Zeit vom Start der Navigation bis zum ersten Byte der Antwort. Sie enthält DNS, TCP, TLS und die serverseitige Arbeit bis zum Response-Start. Sie enthält nicht das Rendering im Browser. Deshalb ist TTFB der saubere Schnitt zwischen Infrastruktur und Front-End.

#Was Sie messen

Arbeiten Sie mit denselben Bedingungen, sonst vergleichen Sie Äpfel mit Birnen:

1. Logged-out und logged-in getrennt. Angemeldete Sessions umgehen oft Full-Page-Caches.
2. HTML-Dokument, nicht ein Bild oder ein CSS-File. TTFB für Assets sagt wenig über PHP aus.
3. Staging mit produktionsnahen Daten und derselben PHP-Version.
4. Cache warm und kalt. Ein warmer Full-Page-Cache kann TTFB stark senken, ohne dass die Applikation schneller geworden ist.

Praktische Werkzeuge: Chrome DevTools (Timing im Network-Panel), curl -o /dev/null -s -w '%{time_starttransfer}\n' URL und Feld- oder Labordaten aus CrUX bzw. PageSpeed Insights. web.dev beschreibt TTFB als Server- und Netzwerkmetrik; nutzen Sie sie genau so.

#Wie Sie das Ergebnis lesen

• Hohe TTFB bei kaltem und warmem Cache: der Server braucht lange, bevor er antwortet. Prüfen Sie PHP-Worker, Datenbanklatenz, Autoload und fehlenden Objekt-Cache.
• Niedrige TTFB, aber schlechte LCP: der Server liefert schnell HTML, das Front-End blockiert. Prüfen Sie Bilder, Fonts und Render-Blocking.
• Niedrige TTFB nur mit Page-Cache, hoch ohne: die Applikation ist teuer, der Cache kaschiert das. Das ist kein Hosting-Sieg, sondern ein Hinweis auf Query- und Plugin-Last.

Schreiben Sie die Zahlen in ein kurzes Runbook (URL, Cache-Zustand, Login-Status, Datum). Ohne Kontext sind Messwerte in zwei Wochen wertlos.

#Query Monitor: der Request unter dem Mikroskop

Query Monitor ist das Standardwerkzeug, um zu sehen, was ein einzelner WordPress-Request wirklich kostet. Installieren Sie es auf Staging, nicht blind auf Production mit öffentlichem Debug-Output.

#Was Sie zuerst ansehen

1. Queries: Anzahl, Gesamtdauer, langsamste Statements, Duplikate.
2. HTTP API: ausgehende wp_remote_get-Aufrufe zu Tracking-, Lizenz- oder CDN-Endpunkten.
3. Hooks: teure Callbacks auf init, wp, template_redirect.
4. Components: welches Plugin oder Theme die teuren Queries auslöst.
5. Conditionals und Template: ob Sie überhaupt die erwartete Template-Hierarchie treffen.

Achten Sie auf Muster statt auf Einzelwerte. Hundert kleine get_option- oder Meta-Queries summieren sich. Drei langsame JOINs auf ungeindexierten Spalten sind ein anderes Problem. Beides fühlt sich für Nutzer ähnlich an, die Fixes unterscheiden sich.

#Typische Funde in deutschen Shop- und Content-Setups

• Ein SEO- oder Cookie-Plugin lädt Konfigurationen und Übersetzungen auf jeder Seite.
• Ein Page-Builder speichert Layouts als Postmeta und liest sie ohne Cache.
• Ein Slider oder Galerie-Plugin lädt alle Anhänge einer Sammlung, obwohl nur drei sichtbar sind.
• WooCommerce-bezogene Shortcodes oder Widgets lösen Produktabfragen auf Startseiten aus, die gar keinen Shop brauchen.

Dokumentieren Sie pro Fund: Query-Snippet, aufrufendes Plugin, betroffene URL-Klasse (Startseite, Archiv, Single). Erst dann deaktivieren oder patchen. Blindes Plugin-Deaktivieren ohne QM-Trace erzeugt nur neue Mythen.

#Autoload-Optionen: der unsichtbare Bootstrap-Preis

WordPress lädt beim Bootstrap alle Zeilen aus wp_options, bei denen autoload aktiv ist. Das ist bequem für kleine Konfigurationswerte und teuer, wenn Plugins große serialisierte Arrays, HTML-Fragmente oder Historien dort ablegen.

#Wie Sie den Umfang prüfen

Auf Staging (read-only reicht):

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 30;

Je nach WordPress-Version und Migration können die Autoload-Werte variieren. Prüfen Sie die tatsächlichen Werte in Ihrer Tabelle. Sortieren Sie nach Größe, nicht alphabetisch. Die größte Option ist oft ein Cache-Blob, den kein Request auf der Startseite braucht.

#Was Sie tun

1. Plugins, die riesige autoloaded Optionen schreiben, aktualisieren oder ersetzen.
2. Daten, die nur im Admin nötig sind, mit autoload => false speichern (add_option / update_option).
3. Verwaiste Optionen deaktivierter Plugins entfernen, nachdem Sie ein Backup haben.
4. Transients und Object Cache nutzen, statt große Runtime-Daten in wp_options zu parken.

Autoload-Bloat erhöht TTFB auf jeder Seite, auch wenn das Front-End schlank aussieht. Deshalb gehört dieser Check direkt hinter die TTFB-Messung und vor kosmetische Asset-Optimierung.

#no_found_rows und sparsame WP_Query-Muster

WP_Query zählt standardmäßig die Gesamtzahl der Treffer (SQL_CALC_FOUND_ROWS bzw. äquivalente Zähllogik), damit Pagination max_num_pages kennt. Auf Listen, bei denen Sie keine Seitenzahlen brauchen, ist das unnötige Arbeit.

$query = new WP_Query(
	array(
		'post_type'              => 'post',
		'posts_per_page'         => 5,
		'no_found_rows'          => true,
		'update_post_meta_cache' => false,
		'update_post_term_cache' => false,
		'fields'                 => 'ids',
	)
);

Hinweise zur Anwendung:

• no_found_rows nur setzen, wenn Sie keine Pagination aus dieser Query brauchen.
• Meta- und Term-Caches abschalten, wenn Sie die Meta- oder Taxonomiedaten nicht rendern.
• fields => 'ids' nutzen, wenn Sie nur IDs weiterreichen und Inhalte selbst laden.
• Ergebnisse mit wp_cache_get / wp_cache_set cachen, wenn die Query auf vielen Views gleich ist.

Dasselbe gilt für get_posts und Secondary Loops in Sidebars. Ein Widget, das auf jeder Seite „neueste fünf Beiträge“ lädt und dabei Found-Rows berechnet, kostet unnötig.

#Objekt-Cache und Redis: wiederholte Arbeit vermeiden

Der WordPress Object Cache hält Laufzeitdaten im Speicher. Ohne persistentes Backend (Redis, Memcached) lebt der Cache nur innerhalb eines Requests. Mit einem persistenten Drop-in überleben Optionen, Query-Ergebnisse und Objekt-Lookups Request-Grenzen.

#Wann Redis hilft

• Hohe Wiederholung derselben Optionen und Post-Objekte (typisch für stark frequentierte Content-Sites).
• Viele kleine Reads, die einzeln billig, in Summe teuer sind.
• Staging und Production mit gleichem Cache-Key-Schema und klarer Invalidierung.

#Wann Redis nicht magisch wirkt

• Ein einzelner Request mit einer monströsen Query bleibt langsam; Redis speichert das Ergebnis nur, wenn Ihr Code es cacht.
• Fehlkonfigurierte Keys oder TTL führen zu Stale Content oder zu Cache-Stampeden.
• Full-Page-Cache und Object Cache lösen unterschiedliche Probleme. Der eine liefert HTML, der andere entlastet PHP/MySQL dazwischen.

Die WordPress-Performance-Doku betont Caching und schlanke Abfragen als Teil der Optimierung. Kombinieren Sie persistentes Object Caching mit Query-Hygiene: erst Duplikate und Autoload bereinigen, dann Redis einschalten. Sonst cachen Sie nur den Müll effizienter.

Prüfen Sie mit Query Monitor vor und nach dem Drop-in: Query-Anzahl und Dauer auf denselben URLs. Wenn sich nichts bewegt, cacht Ihr Code die teuren Pfade nicht oder der Drop-in greift nicht.

#LCP, INP und CLS: was Nutzer wirklich spüren

Core Web Vitals beschreiben die Nutzerwahrnehmung. Sie ersetzen TTFB nicht, sie ergänzen sie.

#LCP (Largest Contentful Paint)

LCP misst, wann das größte sichtbare Element im Viewport fertig gemalt ist. Häufig ist das ein Hero-Bild, eine Überschrift oder ein großer Block. web.dev beschreibt Ursachen wie langsame Ressourcen, Render-Blocking und späte Element-Entdeckung.

In WordPress typisch:

• Hero ohne width/height oder ohne priorisiertes Laden.
• Theme lädt das Hero-Bild erst nach DOM-Manipulation.
• Webfonts blockieren Text-LCP.
• Zu großes Originalbild trotz „Responsive“-Markup.

Maßnahmen ohne erfundene Zahlen: modernes Bildformat, sinnvolle Dimensionen, fetchpriority nur für das echte LCP-Element, kritisches CSS schlank halten, Fonts mit font-display und begrenzter Familie.

#INP (Interaction to Next Paint)

INP bewertet, wie lange es nach Interaktionen dauert, bis der nächste Paint kommt. Lange Main-Thread-Aufgaben aus schweren Admin-Bar-Skripten, Chat-Widgets oder unnötigem JavaScript auf öffentlichen Seiten verschlechtern INP.

WordPress-Praxis:

• Skripte nur enqueueen, wo sie gebraucht werden.
• Third-Party-Tags hinter Consent und nach Interaktion laden, nicht blind im Footer jeder URL.
• Builder-Runtime prüfen: oft läuft Editor-JS auch auf dem Frontend.

#CLS (Cumulative Layout Shift)

CLS summiert Layout-Sprünge. Classic WordPress-Fallen: Bilder ohne Reservierung, Cookie-Banner, die den Inhalt nach unten schieben, Ads und Webfonts, die spät umbrechen.

Fix-Muster: Aspect-Ratio-Boxen, feste Slots für Banner, keine späten DOM-Einfügungen oberhalb des Folds ohne reservierten Platz.

#Hosting versus Code: Entscheidungsbaum

Nutzen Sie diese Reihenfolge, bevor Sie den Tarif wechseln:

1. TTFB kalt/warm, logged-out. Page-Cache aktiv und TTFB hoch? Infrastruktur oder Origin hinter dem Cache prüfen.
2. Query Monitor auf denselben URLs. Viele langsame Queries oder HTTP-Calls? Code und Plugins.
3. Autoload-Größe. Mehrere große Optionen? Bootstrap-Problem, kein reines Hosting-Thema.
4. Object Cache. Persistentes Caching fehlt bei hoher Read-Last? Infrastruktur-Feature, das Code voraussetzt.
5. LCP/INP/CLS. TTFB gut, Vitals schlecht? Front-End und Assets.

Hosting ist der richtige Hebel bei erschöpften PHP-Workern, schwacher Disk-I/O, weit entfernter Datenbank oder fehlendem Opcode-Cache. Code ist der richtige Hebel bei Autoload-Bloat, N+1-Queries, synchronen Remote-Calls und ungebremsten Assets. Viele langsame Sites brauchen beides - aber nacheinander und messbar, nicht parallel und hoffnungsbasiert.

#Schlanke Caching-Patterns im Theme

Wenn kein Full-Page-Cache greift (angemeldete Nutzer, dynamische Fragmente), helfen gezielte Fragment-Caches:

function wpp_get_cached_latest_posts() {
	$cache_key = 'wpp_latest_posts_v1';
	$cached    = wp_cache_get( $cache_key, 'wpp' );

	if ( false !== $cached ) {
		return $cached;
	}

	$query = new WP_Query(
		array(
			'posts_per_page' => 5,
			'post_status'    => 'publish',
			'no_found_rows'  => true,
		)
	);

	wp_cache_set( $cache_key, $query, 'wpp', HOUR_IN_SECONDS );

	return $query;
}

Invalidieren Sie den Key bei save_post, wenn sich die Ergebnismenge ändern soll. Ohne Invalidierung merken Redakteure zuerst „die Startseite aktualisiert sich nicht“, nicht „der Cache funktioniert“.

Ausgabe-Kompression gehört auf Webserver-Ebene (gzip/Brotli), nicht als improvisiertes ob_gzhandler in init, sobald Nginx oder der Host das bereits erledigen. Doppelte Kompression und Output-Buffering-Fallen kosten mehr als sie bringen.

#Bilder und Plugins ohne Tool-Religion

Bilder bleiben ein häufiger LCP-Treiber. Komprimieren Sie Uploads (Plugin oder Build-Pipeline), liefern Sie passende Größen aus und vermeiden Sie, dass Page-Builder Originaldateien im Hero einbetten. Welches Plugin Sie wählen, ist zweitrangig gegenüber dem Ergebnis: kleinere Bytes, korrekte Dimensionen, ein priorisiertes LCP-Bild.

Plugins auditieren Sie mit Query Monitor, nicht mit Bauchgefühl. Deaktivieren Sie Kandidaten einzeln auf Staging und messen Sie Queries sowie TTFB erneut. Behalten Sie Plugins, die ihren Job mit wenigen Queries erledigen. Entfernen Sie solche, die auf jeder öffentlichen URL Admin-Logik und Remote-Checks mitbringen.

#Checkliste für den nächsten Staging-Lauf

1. TTFB für Startseite und eine langsame Innen-URL, kalt und warm, logged-out notieren.
2. Query Monitor: Top-Queries, HTTP-API, verantwortliche Components speichern.
3. Autoload-Top-30 nach Byte-Größe exportieren und Eigentümer-Plugin zuordnen.
4. Listen-Queries auf no_found_rows und Cache-Flags prüfen.
5. Object-Cache-Drop-in Status prüfen (WP_REDIS_HOST bzw. Host-Panel) und denselben QM-Lauf wiederholen.
6. LCP-Element in DevTools Performance/Experience identifizieren; INP- und CLS-Verdachtsquellen (JS, Banner, Bilder) markieren.
7. Erst dann Hosting-Ticket oder Theme-Patch priorisieren.

Mehr Kontext zu strukturierter Sichtbarkeit und technischen Signalen finden Sie in unserer Übersicht zur SEO- und GEO-Optimierung.

#Kurzfassung

Eine langsame WordPress-Website ist ein Messproblem, bevor sie ein Hostingproblem ist. TTFB zeigt, ob der Server überhaupt rechtzeitig antwortet. Query Monitor zeigt, wer die Zeit frisst. Autoload und fehlende no_found_rows-Disziplin erklären Bootstrap- und Listenlast. Redis hilft, wiederholte Arbeit zu vermeiden, ersetzt aber keine Query-Hygiene. LCP, INP und CLS erklären, warum Nutzer trotz akzeptabler TTFB stocken. Arbeiten Sie diese Schichten der Reihe nach ab - dann wissen Sie, ob der nächste Schritt Code, Cache oder Infrastruktur heißt.