Ist Ihre WordPress-Seite langsam: Ursachen finden und beheben

#Warum Ihre WordPress-Seite langsam ist, obwohl das Hosting nicht schuld ist

Mehr dazu, wie wir die Geschwindigkeit von WordPress verbessern, finden Sie in unserem Leitfaden zur WordPress-Optimierung. Wenn eine WordPress-Seite an Geschwindigkeit verliert, ist die erste Reaktion meist das Upgrade auf einen teureren Hosting-Tarif. Ein besserer Server hilft zwar, aber oft maskiert er nur tieferliegende architektonische Probleme. Geld in Hosting zu stecken, bevor die Applikationsebene optimiert ist, bleibt eine vorübergehende Lösung für ein dauerhaftes Problem.

#Was WordPress außer dem Hosting langsam macht

Ein schnellerer Server hat mehr Leistung, aber wenn Ihre Seite durch schlecht optimierte Ressourcen ausgebremst wird, läuft ineffizienter Code einfach auf einer schnelleren CPU. Dies sind die häufigsten Flaschenhälse:

• Plugin-Ballast und Query-Schulden: Jedes aktive Plugin ist nicht nur eine Datei, sondern eine potenzielle Serie von Datenbankabfragen und externen Abhängigkeiten. Viele dieser Abfragen sind redundant: Sie holen bei jeder Anfrage dieselben Daten, die man einmal hätte cachen können.
• Unverwaltete Bilddateien: Hochauflösende Bilder ohne moderne Formate (wie AVIF oder WebP) sind der Hauptgrund für einen schlechten LCP. Ein Hero-Foto, das direkt aus der Kamera oder einer Bilddatenbank exportiert wurde, ist oft um ein Vielfaches schwerer als dasselbe Bild als AVIF in der Größe, in der es tatsächlich angezeigt wird.
• Fehlender Object Cache: Ständige Datenbankzugriffe für statische Daten zwingen den Server zu redundanter Arbeit. Website-Optionen, Navigationsmenüs und Widget-Einstellungen werden bei jedem Seitenaufruf gelesen, obwohl sie sich selten ändern.
• Latenz durch Drittanbieter-Skripte: Externe Tracker, Fonts und Embeds blockieren oft den Main Thread und verschlechtern Ihre Core Web Vitals. Webfonts von einem fremden Host, Tracking-Pixel sozialer Netzwerke und Live-Chat-Widgets sind die üblichen Verursacher.

#Wie Sie die Felddaten in PageSpeed Insights für eine WordPress-Seite lesen

PageSpeed Insights zeigt auf einem Bildschirm zwei verschiedene Arten von Zahlen, und wer sie verwechselt, hält eine WordPress-Korrektur schnell für wirkungslos. Der Abschnitt mit Felddaten stammt aus dem Chrome User Experience Report (CrUX): echte Chrome-Nutzer, die zugestimmt haben, zusammengefasst über den vorangegangenen Erhebungszeitraum von 28 Tagen und ausgewiesen am 75. Perzentil (Dokumentation zu PageSpeed Insights). Der Lab-Abschnitt ist ein einziger simulierter Seitenaufruf auf einem Gerät mit festen Netzwerkbedingungen, deshalb können die beiden Werte voneinander abweichen.

Drei Folgen für die Diagnose:

• Prüfen Sie, auf welcher Ebene die Daten liegen. Hat eine URL nicht genug eigene Daten, greift PSI auf Daten des gesamten Origins zurück. Bei einem Blogartikel mit wenig Traffic beschreibt der LCP aus den Felddaten dann womöglich die ganze Domain und nicht diese Seite.
• Mit Felddaten priorisieren, mit Lab-Daten debuggen. web.dev empfiehlt, bei vorhandenen Feld- und Lab-Daten die Felddaten zur Priorisierung zu nutzen und die Lab-Daten zum Debuggen (web.dev: warum sich Lab- und Felddaten unterscheiden). Lab-Tests laden die Seite mit leerem Cache und können nicht vorhersagen, wann ein echter Besucher klickt. Deshalb ist die Total Blocking Time im Lab nur ein Näherungswert für INP und kein Ersatz. Unser Leitfaden zur INP-Optimierung beschreibt, was zu tun ist, wenn die Felddaten dorthin zeigen.
• Rechnen Sie mit Verzögerung. Weil das Zeitfenster 28 Tage umfasst, zeigt sich eine heute ausgerollte Korrektur erst nach etwa vier Wochen vollständig in den Felddaten. Ein Lab-Wert, der sich über Nacht verbessert, ist ein gutes Zeichen, aber kein Beweis.

#Wie Sie prüfen, ob die TTFB auf den Server zeigt

Bei der TTFB bekommt die Frage, ob das Hosting schuld ist, eine messbare Antwort. web.dev definiert die TTFB als Summe aus Weiterleitungszeit, Start des Service Workers, DNS-Abfrage, Verbindungsaufbau mit TLS-Aushandlung und der Anfrage bis zum ersten Byte der Antwort. Als grobe Orientierung gelten 0,8 Sekunden oder weniger als gut und Werte über 1,8 Sekunden als schlecht (web.dev: Time to First Byte optimieren).

Diese Aufschlüsselung ist für WordPress wichtig, weil nicht alles davon PHP ist. Ein Besucher, der auf http:// landet, auf https:// und dann auf den www-Host weitergeleitet wird, zahlt für jeden Sprung, bevor WordPress überhaupt arbeitet. Das Network-Panel der DevTools zeigt jede Weiterleitung als eigene Anfrage, und deren Korrektur gehört in die Server- oder CDN-Konfiguration, nicht in die Datenbank. Im Feld kommt die TTFB aus CrUX oder der JavaScript-Bibliothek web-vitals, im Lab aus dem Network-Panel der DevTools oder aus WebPageTest.

Die Zahl von 200 ms, die in diesem Artikel an anderer Stelle steht, ist ein strengeres Arbeitsziel für eine WordPress-Seite, die aus dem Page Cache ausgeliefert wird. Ein Wert zwischen 200 ms und 0,8 s fällt nach Googles Orientierung nicht durch. Er ist ein Grund zu prüfen, ob der Page Cache überhaupt greift.

#Wie Sie mit Site Health Geschwindigkeitsprobleme in WordPress erkennen

WordPress bringt unter Werkzeuge, Website-Zustand eigene Prüfungen mit, und einige davon betreffen die Geschwindigkeit. Seit WordPress 6.1 prüft Site Health, ob ein vollständiger Page Cache vorhanden ist und ob die Antwortzeit des Servers akzeptabel ist. Die Standardschwelle liegt bei 600 ms, Hoster können sie über den Filter site_status_good_response_time_threshold ändern. Außerdem empfiehlt Site Health einen persistenten Object Cache, sobald die Daten der Website Schwellenwerte überschreiten, die Hoster mit site_status_persistent_object_cache_thresholds überschreiben können (Make WordPress Core, Cache-Prüfungen in 6.1). Beide Prüfungen laufen nur in der Produktivumgebung, eine Staging-Kopie zeigt sie also nicht an.

WordPress 6.6 hat eine Prüfung für automatisch geladene Optionen ergänzt: Sie meldet ein Problem, wenn die bei jeder Anfrage geladenen Optionen zusammen mehr als 800 KB ergeben. Mit derselben Version lädt WordPress einzelne Optionen über 150.000 Bytes nicht mehr automatisch, es sei denn, der Code verlangt es ausdrücklich. Diese Grenze lässt sich mit dem Filter wp_max_autoloaded_option_size anpassen (Make WordPress Core, Autoload-Änderungen in 6.6). Eine fehlgeschlagene Autoload-Prüfung führt meist zu den verwaisten Plugin-Optionen, die im Datenbank-Abschnitt weiter unten beschrieben sind.

#Wie Sie das langsame Plugin mit Query Monitor finden

Query Monitor macht aus „WordPress ist langsam“ eine Komponente mit Namen. Das Datenbank-Panel markiert langsame, doppelte und fehlgeschlagene Abfragen und gruppiert sie nach Abfragetyp, Komponente oder aufrufender Funktion. Eine Abfrage, die ein Plugin bei jeder Anfrage wiederholt, erscheint so unter dem Namen dieses Plugins (Query Monitor auf GitHub). Zwei weitere Panels werden leicht übersehen:

• HTTP-API-Aufrufe: jede serverseitige Anfrage über die HTTP API von WordPress, wobei fehlgeschlagene Anfragen und Antworten ohne Statuscode 200 hervorgehoben werden. Ein Plugin, das während der Seitengenerierung einen entfernten Server kontaktiert, addiert diesen Umweg zur TTFB.
• Hooks und Actions: jeder während der Anfrage ausgelöste Hook mit Callbacks, Prioritäten und Komponenten. Das zeigt, wo sich ein Plugin auf Seiten einhängt, auf denen es keine sichtbare Aufgabe hat.

Nutzen Sie es nach Möglichkeit auf einer Staging-Kopie. Query Monitor zeigt seine Ausgabe angemeldeten Administratoren, und angemeldete Anfragen umgehen meist den Page Cache. Die Zahlen beschreiben also den ungecachten Fall: die Arbeit, die der Server für jeden Besucher leistet, den der Cache nicht abdeckt.

#Wie Sie eine langsame WordPress-Seite schneller machen

Die folgenden Schritte sind die, auf die eine Diagnose am häufigsten zeigt.

#1. Selektives Object Caching einsetzen

Anstatt die Datenbank bei jedem Seitenaufruf für die gleichen Daten zu belasten, sollten Sie die Transients API oder einen persistenten Object Cache (wie Redis) nutzen. Das ist besonders wichtig für dynamische Websites, auf denen ein Page Cache nicht immer möglich ist.

Die Transients API arbeitet nach dem Muster „erst prüfen, dann speichern“. WordPress sucht zuerst nach dem Wert unter einem benannten Schlüssel. Ist er vorhanden und nicht abgelaufen, kommt er sofort zurück, ohne die Beitragstabelle anzufassen. Wenn nicht, führt Ihr Code die Abfrage aus, speichert das Ergebnis mit einer Ablaufzeit und gibt es zurück.

function get_performance_optimized_posts() {
    // Versuch, Daten aus dem Cache zu laden
    $posts = get_transient('featured_posts_query');

    if (false === $posts) {
        $posts = new WP_Query([
            'posts_per_page' => 5,
            'no_found_rows'  => true, // Overhead sparen, wenn keine Pagination nötig ist
            'post_status'    => 'publish',
        ]);

        // Cache für 12 Stunden setzen
        set_transient('featured_posts_query', $posts, 12 * HOUR_IN_SECONDS);
    }

    return $posts;
}

Das Argument no_found_rows verdient Aufmerksamkeit. Standardmäßig lässt WP_Query MySQL jede passende Zeile zählen, um Pagination-Links bauen zu können. Ein Widget mit den „letzten fünf Beiträgen“ paginiert nie, also ist diese Zählung reiner Overhead, und das Abschalten nimmt jeder Anfrage, die das Widget ausführt, Arbeit ab.

Wann Transients und wann Redis:

• Transients: für Abfrageergebnisse mit klarer Ablaufzeit. Ohne persistenten Object Cache liegen sie in der Tabelle wp_options; ist einer installiert, hält WordPress sie stattdessen in Redis oder Memcached.
• Redis oder Memcached: für einen persistenten Object Cache, der zwischen HTTP-Anfragen erhalten bleibt. Das lohnt sich bei Websites mit viel Traffic, WooCommerce-Shops und Mitgliederbereichen, wo viele Seiten nicht aus einem vollständigen Page Cache kommen können, weil der Besucher angemeldet ist oder einen Warenkorb hat.

#2. Über einfache Komprimierung hinausgehen

Bilder zu „komprimieren“ ist nur die halbe Arbeit. Setzen Sie auf AVIF-Unterstützung und responsive Bildgrößen, damit mobile Nutzer keine Dateien in Desktop-Größe laden.

Eine mehrstufige Bildstrategie:

1. Format: AVIF zuerst, WebP als Fallback, JPEG oder PNG nur als letzte Möglichkeit.
2. Abmessungen: srcset und sizes verwenden, damit der Browser eine Datei passend zur Bildschirmbreite wählt.
3. Lazy Loading: loading="lazy" für Bilder unterhalb des ersten Viewports, aber nie für das LCP-Bild selbst, das so früh wie möglich laden soll.
4. Bild-CDN: Dienste wie Cloudinary oder imgix können Bilder im Flug skalieren und konvertieren, wenn Sie nicht jede Variante selbst erzeugen möchten.

<!-- Beispiel für ein sauber aufgebautes responsives Bild -->
<picture>
  <source type="image/avif" srcset="bild-400.avif 400w, bild-800.avif 800w, bild-1200.avif 1200w">
  <source type="image/webp" srcset="bild-400.webp 400w, bild-800.webp 800w, bild-1200.webp 1200w">
  <img src="bild-800.jpg" alt="Beschreibung" loading="lazy" width="800" height="450"
       srcset="bild-400.jpg 400w, bild-800.jpg 800w, bild-1200.jpg 1200w"
       sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px">
</picture>

Die expliziten Attribute width und height sind genauso wichtig wie das Format. Damit reserviert der Browser den Platz, bevor die Datei ankommt, und genau das hält den CLS niedrig.

#3. Output-Buffering optimieren

Falls Sie kein dediziertes Caching-Plugin nutzen, können Sie die Gzip-Komprimierung auf PHP-Ebene umsetzen, auch wenn das über die .htaccess oder die Nginx-Konfiguration meist effizienter ist.

// Basis-Komprimierung, falls keine Server-Konfiguration möglich ist
add_action('init', function() {
    if (!ob_start("ob_gzhandler")) ob_start();
});

#4. Zuerst die Plugins prüfen

Ein Plugin-Audit bringt meist den größten Effekt für den geringsten Aufwand. Websites sammeln über Jahre Plugins, jedes für eine Kampagne oder eine Funktion installiert, und niemand prüft, was sie bei jeder Anfrage kosten.

So läuft das Audit ab:

1. Query Monitor installieren: Es zeigt, wie viele Datenbankabfragen jedes Plugin auslöst, wie viel Speicher es braucht und wie lange seine Hooks auf der aktuellen Seite dauern.
2. Die schweren finden: nach Anzahl der Abfragen und Zeit sortieren und nach Plugins suchen, die viel Arbeit auf Seiten verrichten, auf denen sie keine sichtbare Aufgabe haben.
3. Alternativen abwägen: Für jedes schwere Plugin fragen, ob ein leichteres dasselbe leistet oder ob die Funktion klein genug ist, um sie mit ein paar Zeilen im Theme umzusetzen.
4. Deaktivieren, was nicht gebraucht wird: doppelte Sicherheits-Plugins, ungenutzte Formular-Builder, ein Slider-Plugin für eine einzige Seite.

Plugins, die oft mehr kosten, als sie bringen:

• Page Builder (Elementor, Divi), die ihre Assets auch auf Seiten laden, die nicht damit gebaut wurden.
• Social-Sharing-Plugins, die auf jeder Seite Skripte laden.
• SEO-Plugins, bei denen jedes optionale Modul aktiviert ist.
• Statistik-Plugins, die jeden Besuch in die WordPress-Datenbank schreiben.

#5. Die Datenbank aufräumen

Mit der Zeit sammelt die WordPress-Datenbank Daten, die Abfragen verlangsamen:

• Beitragsrevisionen: WordPress speichert bei jedem Speichern eine Revision, ein oft bearbeiteter Beitrag schleppt also eine lange Reihe alter Kopien mit.
• Abgelaufene Transients: Sie können in wp_options liegen bleiben, bis etwas sie entfernt.
• Verwaiste Optionen: Deinstallierte Plugins hinterlassen oft ihre Einstellungen, manchmal mit aktiviertem autoload, sodass sie bei jeder Anfrage geladen werden.
• Verwaiste Metadaten: Beitrags-, Benutzer- und Kommentar-Metadaten, die auf nicht mehr existierende Datensätze verweisen.

// Beitragsrevisionen in wp-config.php begrenzen
define('WP_POST_REVISIONS', 5);

// Oder ganz abschalten (nicht empfohlen für Websites mit mehreren Redakteuren)
define('WP_POST_REVISIONS', false);

Werkzeuge dafür:

• WP-Optimize: geplantes Aufräumen von Revisionen, Transients und verwaisten Daten.
• phpMyAdmin: für manuelle Abfragen, wenn Sie genau wissen, was Sie löschen.
• WP-CLI: wp transient delete --expired und wp db optimize auf der Kommandozeile, die sicherste Variante bei großen Tabellen.

Erstellen Sie vor jedem Aufräumen ein Datenbank-Backup. Eine falsche Abfrage gegen wp_postmeta lässt sich nicht mit einem Rückgängig-Knopf beheben.

#6. Ein CDN vor die Website schalten

Ein CDN (Content Delivery Network) kopiert Ihre statischen Dateien auf Server weltweit, sodass Besucher sie von einem nahe gelegenen Standort laden statt von Ihrem Ursprungsserver.

Was ein CDN einer WordPress-Seite bringt:

• Niedrigere TTFB für statische Dateien: Dateien kommen vom nächstgelegenen Edge-Standort.
• Weniger Last auf dem Ursprungsserver: Bilder, CSS und JavaScript treffen Ihren Server nicht mehr.
• DDoS-Schutz: Die meisten CDNs fangen Angriffstraffic ab, bevor er Sie erreicht.

Ein sinnvoller Cloudflare-Startpunkt für WordPress:

1. SSL/TLS auf „Full (strict)“ stellen, damit der Verkehr bis zu Ihrem Server verschlüsselt ist.
2. Cache-Regeln für statische Dateien anlegen und den Cache für /wp-admin/, angemeldete Nutzer sowie die Warenkorb- und Checkout-Seiten von WooCommerce umgehen.
3. Brotli-Komprimierung aktiviert lassen.
4. In bezahlten Tarifen Polish für die automatische Bildoptimierung erwägen oder sie weiter in WordPress erledigen, wenn Sie bereits AVIF erzeugen.

#Wie Sie die WordPress-Performance überwachen

Performance-Arbeit ist keine einmalige Aufgabe. WordPress-Seiten ändern sich ständig durch neue Inhalte, Plugin-Updates und Konfigurationsänderungen, und ohne Monitoring sinkt die Geschwindigkeit langsam wieder. Für Alarmierung und dauerhafte Setups auf größeren Websites gibt es unseren Leitfaden zum Performance-Monitoring für WordPress.

Sinnvolle Monitoring-Werkzeuge:

• Google PageSpeed Insights: Stichproben der Core Web Vitals für eine einzelne URL.
• Google Search Console: Felddaten echter Chrome-Nutzer, gruppiert nach URL-Mustern.
• GTmetrix: ein detailliertes Wasserfalldiagramm aller Anfragen der Seite.
• Query Monitor: Datenbank- und Hook-Debugging auf einer Staging- oder Entwicklungskopie.

Drittanbieter-Skripte verdienen hier eine eigene Prüfung. In der EU verlangt die Datenschutzrichtlinie für elektronische Kommunikation (2002/58/EG, Artikel 5 Absatz 3) eine Einwilligung, bevor nicht notwendige Cookies gespeichert werden (Text auf EUR-Lex). Tracking-Skripte sollten also erst laden, wenn der Besucher zustimmt. Richtig umgesetzt hält das sie auch aus dem ersten Seitenaufruf aller Besucher heraus, die das Banner noch nicht angeklickt haben.

Kennzahlen, die Sie beobachten sollten:

Die Schwellen für LCP, INP und CLS sind Googles veröffentlichte „gute“ Werte, gemessen am 75. Perzentil der Seitenaufrufe (web.dev: Web Vitals). INP hat FID im März 2024 als Core Web Vital ersetzt, ein Bericht, der noch FID zeigt, ist also veraltet. Der TTFB-Wert ist die Arbeitsschwelle dieses Artikels dafür, wann man sich den Server ansehen sollte, kein Core Web Vital von Google.

#Checkliste für eine langsame WordPress-Seite

Wenn Ihre Seite langsam ist, raten Sie nicht, messen Sie nach. Nutzen Sie Query Monitor, um teure Datenbankabfragen zu finden, und PageSpeed Insights für blockierende Skripte.

• Prüfen Sie die Anzahl der Abfragen: Sind es mehr als 100 Abfragen pro Seitenaufruf?
• Prüfen Sie den Hero-Bereich: Wird das Hauptbild als AVIF oder WebP statt als PNG/JPEG ausgeliefert?
• Testen Sie die TTFB: Liegt sie über 200 ms, dann lohnt der Blick auf Hosting oder Datenbank-Optimierung.
• Prüfen Sie Drittanbieter-Skripte: Wie viele externe Skripte laden, und wie lange blockieren sie den Main Thread?

Oft ist die Ursache das „eine einfache Plugin“, das niemand mehr deaktiviert hat. Meist ist es aber nicht ein großes Problem, sondern das vergessene Plugin, ein PNG im Hero-Bereich und eine träge TTFB gleichzeitig. Wenn Sie diese Kette nicht selbst aufdröseln wollen, übernimmt das unsere WordPress-Entwicklung mit Performance-Audit oder ein gezieltes Core-Web-Vitals-Audit.