WordPress langsam? Erst messen, dann schrauben
Ein träges WordPress kostet doppelt: Deine Redaktion wartet im Admin-Bereich auf jeden Speichervorgang, und deine Besucher springen ab, bevor die Seite steht. Die gute Nachricht: Beides hat fast immer konkrete, messbare Ursachen. Blindes Plugin-Deaktivieren ist der falsche Weg.
In diesem Artikel zeige ich dir, wie wir als WordPress-Agentur vorgehen: erst eine Diagnose in zehn Minuten, dann die häufigsten Bremsen im Backend und im Frontend, danach der Blick aufs Hosting. Und am Ende die ehrliche Frage: Wann lohnt sich Optimieren nicht mehr?
Vielleicht erkennst du dich in einem dieser Symptome wieder:
- Das Speichern eines Beitrags dauert mehrere Sekunden, Gutenberg reagiert träge.
- Die Mediathek lädt spürbar langsam oder bricht mit Timeouts ab.
- Die Startseite braucht auf dem Handy gefühlt ewig, obwohl der Admin-Bereich flott ist.
- Nach jedem neu installierten Plugin wird alles ein wenig zäher.
Erste Diagnose in 10 Minuten
Bevor du irgendein Optimierungs-Plugin installierst: Finde heraus, wo die Zeit tatsächlich verloren geht. Drei Werkzeuge reichen für eine belastbare erste Einschätzung.
- Query Monitor installieren: Das kostenlose Plugin zeigt dir pro Seitenaufruf alle Datenbankabfragen, Hooks und HTTP-Calls – aufgeschlüsselt nach Plugin. Alles über 200 Millisekunden pro Abfrage gehört auf deine Watchlist.
- Browser-DevTools öffnen: Im Netzwerk-Tab siehst du die Time to First Byte (TTFB). Liegt sie über einer Sekunde, arbeitet der Server zu lange: Das Problem sitzt in PHP, Datenbank oder Hosting. Ist die TTFB gut, aber die Seite lädt trotzdem lange, bremsen Bilder, CSS und JavaScript.
- Hosting-Check machen: Unter Werkzeuge → Website-Zustand siehst du PHP-Version, Memory-Limit und ob ein persistenter Object Cache aktiv ist. Drei Angaben, die über einen Großteil deiner Performance entscheiden.
Das Ergebnis dieser zehn Minuten ist eine Richtungsentscheidung: Ist nur das Backend langsam, liegt es an Plugins, Datenbank oder fehlendem Object Cache. Lahmt das Frontend trotz guter TTFB, gehst du an Theme und Assets. Ist beides träge, fängst du beim Hosting an.
Wichtig dabei: Miss Backend und Frontend getrennt. Ein Page Cache kann ein katastrophal langsames PHP jahrelang verstecken – auffallen tut es erst, wenn sich jemand einloggt oder der Cache kalt ist.
Die häufigsten Backend-Bremsen
«WordPress Backend langsam» ist die Suchanfrage, hinter der die meisten konkreten Probleme stecken. Vier Ursachen sehen wir in Kundenprojekten immer wieder: Plugins, Autoload-Optionen, WP-Cron und Datenbank-Müll. In dieser Reihenfolge prüfen wir sie auch bei Audits.
Plugins: Hooks, Assets und externe API-Calls
Nicht die Anzahl der Plugins ist das Problem, sondern was sie tun. Security-Scanner, Statistik-Tools und Page Builder registrieren Hooks auf jeder Admin-Seite, laden eigene Skripte ins Dashboard oder rufen bei jedem Aufruf externe Dienste an. Query Monitor zeigt dir schwarz auf weiß, welches Plugin welche Zeit frisst.
Ein Sonderfall sind Schnittstellen: Wenn ein Plugin bei jedem Speichern synchron ein CRM oder ERP anspricht, wartet deine Redaktion auf die Antwort des Fremdsystems. Wie sich solche Anbindungen sauber und asynchron lösen lassen, habe ich im Artikel über die WordPress-Integration mit CRM, ERP und PIM beschrieben.
Und: Veraltete Plugins bremsen nicht nur, sie sind ein Sicherheitsrisiko. Viele Unternehmen spielen Updates aus Angst vor Fehlern nicht ein. Genau dafür bieten wir einen Wartungsservice für WordPress-Websites an: Updates mit Backup und Test, statt Stillstand aus Vorsicht.
Autoload: die unterschätzte wp_options-Tabelle
WordPress lädt bei jedem einzelnen Request alle Optionen mit dem Flag autoload = yes aus der Datenbank – auch im Backend. Deinstallierte Plugins hinterlassen dort oft Datenreste, die für immer mitgeladen werden. Seit WordPress 6.6 warnt der Website-Zustand, sobald diese Autoload-Daten 800 KB überschreiten.
Mit diesem SQL-Statement misst du die Autoload-Last deiner Installation:
SELECT
SUM(LENGTH(option_value)) AS autoload_size_bytes,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_size_mb,
COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes';Liegt der Wert deutlich über 800 KB: verwaiste Optionen identifizieren und nach einem Backup löschen, bei großen Einträgen das Autoload-Flag auf no setzen. Das bringt zuweilen mehr als jedes Caching-Plugin.
Gut zu wissen: Seit Version 6.6 nimmt WordPress neue Optionen über 150 KB von sich aus vom Autoload aus. Das hilft aber nur für die Zukunft – die Altlasten deiner Installation räumt es nicht auf.
WP-Cron: der Scheinplaner
WP-Cron ist kein echter Cronjob: WordPress prüft bei jedem Seitenaufruf, ob geplante Aufgaben anstehen, und führt sie im selben Request aus. Auf gut besuchten Seiten zahlt also irgendein Besucher oder deine Redaktion die Rechnung für Backups, Importe und geplante Beiträge. Auf schwach besuchten Seiten passiert das Gegenteil: Aufgaben laufen erst, wenn der nächste Besucher kommt.
Die Lösung ist ein Zweizeiler: DISABLE_WP_CRON in der wp-config.php setzen und wp-cron.php per echtem System-Cron aufrufen, in unseren Setups alle fünf Minuten. Damit laufen schwere Aufgaben planbar im Hintergrund statt mitten im Redaktionsalltag. Ob bei dir Aufgaben hängen, zeigt dir das kostenlose Plugin WP Crontrol: Es listet alle geplanten Events samt nächster Laufzeit.
Datenbank-Müll: Revisionen, Transients, verwaiste Metadaten
Jahrelang gewachsene Installationen schleppen Zehntausende Beitragsrevisionen, abgelaufene Transients und verwaiste Post- und User-Metadaten mit. Jede Abfrage läuft dadurch über größere Tabellen, oft ohne passende Indizes.
Revisionen begrenzt WordPress von Haus aus nicht: Ein Beitrag, der fünfzig Mal überarbeitet wurde, liegt fünfzig Mal in wp_posts. Mit der Konstante WP_POST_REVISIONS begrenzt du künftige Revisionen auf einen festen Wert. Abgelaufene Transients räumt WordPress zwar täglich per Cron auf – aber nur, wenn WP-Cron zuverlässig läuft: siehe oben.
Für den Bestand gilt: Query Monitor zeigt dir die langsamen Abfragen. Danach heißt es aufräumen, Indizes ergänzen und Plugins mit ineffizienten Queries ersetzen oder per Custom-Code ablösen.
Wenn das Frontend lahmt
«WordPress lädt langsam» betrifft deine Besucher: und damit Rankings und Conversions. Google bewertet das Ladeerlebnis über die Core Web Vitals. Die Zielwerte: Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden, Cumulative Layout Shift unter 0,1 – jeweils für 75 Prozent der Seitenaufrufe.
Messen kannst du das kostenlos mit PageSpeed Insights, getrennt nach Mobil und Desktop. Den Überblick über alle Seiten liefert der Core-Web-Vitals-Bericht in der Google Search Console: Dort siehst du Felddaten echter Chrome-Nutzer statt einer Labormessung.
Theme und Page-Builder
Page Builder wie Elementor oder Divi laden auf jeder Seite ihr komplettes CSS- und JavaScript-Arsenal und erzeugen tief verschachtelte HTML-Strukturen. Das drückt direkt auf LCP und INP. Und INP leidet vor allem unter JavaScript: Jedes Tracking-Skript und jeder Slider verlängert die Reaktionszeit auf Klicks.
Der Test ist simpel: Aktiviere auf einer Staging-Umgebung testweise ein Standard-Theme wie Twenty Twenty-Five und miss erneut. Bricht die Ladezeit deutlich ein, kennst du den Schuldigen. In unseren Projekten ist der Wechsel auf ein schlankes Block-Theme regelmäßig der größte einzelne Hebel im Frontend.
Bilder: der größte LCP-Hebel
Unkomprimierte Bilder sind der häufigste Grund für schlechte LCP-Werte. Meist ist das LCP-Element deine Hero-Grafik oder das Beitragsbild: Optimiere zuerst dieses eine Bild, bevor du dich in der Mediathek verlierst. Die Maßnahmen sind bekannt und wirken zuverlässig: moderne Formate wie WebP oder AVIF, korrekte Bildgrößen per srcset, Lazy Loading für alles unterhalb des sichtbaren Bereichs und ein CDN für die Auslieferung. WordPress bringt vieles davon inzwischen von Haus aus mit – du musst es nur konsequent nutzen.
Caching: was es kann und was nicht
Ein Page Cache liefert fertige HTML-Seiten aus, ohne PHP und Datenbank zu bemühen: Für anonyme Besucher ist das der stärkste Beschleuniger. Server-seitiges Caching beim Hoster schlägt dabei fast jedes Caching-Plugin.
Konkret heißt das: Prüfe zuerst, ob dein Hoster server-seitiges Caching anbietet, bevor du ein Plugin wie WP Rocket oder W3 Total Cache installierst. Zwei Caching-Schichten übereinander erzeugen mehr Fehler als Tempo.
Aber sei ehrlich zu dir: Ein Page Cache hilft weder eingeloggten Nutzern noch dem Backend, und im WooCommerce-Checkout ist er wirkungslos. Dort braucht es den persistenten Object Cache über Redis oder Memcached. Die Faustregel: Page Cache fürs Frontend, Object Cache für alles Dynamische.
Hosting als Faktor
Manche Bremsen kannst du nicht wegoptimieren, weil sie im Fundament stecken. Billiges Shared Hosting teilt sich CPU, RAM und Datenbank mit Dutzenden anderen Kunden: Da hilft das beste Plugin-Audit nichts.
Der wichtigste Einzelfaktor ist die PHP-Version: PHP 8.1 erhält seit Ende 2025 keine Updates mehr, PHP 8.2 bekommt nur noch bis zum 31. Dezember 2026 Sicherheits-Fixes. Wir setzen bei Kunden auf PHP 8.3 oder 8.4 mit aktiviertem OPcache – neuere Versionen sind schneller und länger versorgt.
Dazu kommen aus unserer Projektpraxis: ein memory_limit von 256 bis 512 MB, Redis oder Memcached als Object Cache und eine Datenbank auf schnellem NVMe-Speicher. Ein Managed-WordPress-Hoster bringt das meiste davon mit; prüfe es vor Vertragsschluss.
Ein einfacher Anhaltspunkt bleibt die TTFB aus deiner Diagnose: Liegt sie trotz Page Cache und aufgeräumtem Backend über einer Sekunde, ist meist das Hosting der Deckel.
Alle Backend-Maßnahmen im Überblick:
| Bereich | Typische Probleme | Konkrete Maßnahme |
|---|---|---|
| Plugins | Zu viele Hooks, unnötige Assets im Backend, externe API-Calls | Mit Query Monitor identifizieren, unnötige Plugins deaktivieren oder nur kontextbezogen laden |
| wp_options | Tausende autogeladene Optionen, mehrere MB Autoload-Size | Autoload-Größe messen, verwaiste Optionen nach Backup löschen, Autoload-Flag reduzieren |
| PHP/Hosting | Zu wenig Memory, kurze max_execution_time, kein OPcache | Memory-Limit erhöhen, Ausführungszeit anpassen, OPcache aktivieren und konfigurieren |
| Datenbank | Langsame Queries, fehlende Indizes, unnötig viele Datensätze pro Request | Langsame Queries mit Query Monitor finden, Indizes ergänzen, Plugins optimieren oder ersetzen |
| Caching | Nur nicht-persistentes Object Caching, hohe DB-Last im Backend | Redis oder Memcached einführen, `object-cache.php`-Drop-in nutzen |
Wann Optimieren nicht mehr reicht: der Headless-Ausweg
Zuweilen stößt du an eine Grenze, die kein Tuning verschiebt: Das Theme ist über Jahre gewachsen, der Page Builder diktiert das Markup, und jede Optimierung kämpft gegen den Stack statt mit ihm. Dann ist die ehrliche Antwort nicht das nächste Caching-Plugin, sondern eine Architektur-Entscheidung.
Headless heißt: WordPress bleibt als Redaktionssystem, das Frontend wird als eigenständige Anwendung gebaut – etwa mit Next.js, statisch generiert und über ein CDN ausgeliefert. Deine Redaktion behält den gewohnten Admin-Bereich, deine Besucher bekommen Ladezeiten, die mit klassischem Theme-Rendering kaum erreichbar sind. Die Chancen und Risiken von Headless WordPress mit Next.js habe ich in einem eigenen Vergleich beschrieben.
Aber Headless ist kein Allheilmittel: Es kostet Entwicklungsbudget, Vorschau und Plugins funktionieren anders, und für eine Fünf-Seiten-Website lohnt es sich schlicht nicht. Welche Kriterien für welchen Weg sprechen, zeigt der Artikel WordPress, Headless oder Baukasten: Entscheidungskriterien für Unternehmen.
Nächste Schritte
Meine Empfehlung: Investiere zuerst die zehn Minuten Diagnose. Query Monitor, TTFB und Website-Zustand sagen dir, ob du ein Plugin-Problem, ein Datenbank-Problem oder ein Hosting-Problem hast – und in dieser Reihenfolge würde ich auch optimieren.
Wenn du dabei Unterstützung willst: Als technische WordPress-Agentur analysieren wir dein Setup, entschlacken es und sagen dir offen, ob Optimierung oder ein neuer Unterbau der wirtschaftlichere Weg ist – etwa im Rahmen einer CMS-Beratung. Buch dir dafür ein kostenloses Erstgespräch: 30 Minuten, konkrete Einschätzung, keine Verkaufsshow.
