Plattformen
WordPress schneller machen: Ursachen finden und beheben
Was WordPress wirklich ausbremst, von Hosting und Plugins bis zu Bildern und Caching, und in welcher Reihenfolge du es angehst.
Wenn deine WordPress-Seite langsam lädt, steckt fast immer eine von vier Ursachen dahinter: Der Server braucht zu lange, um die Seite zu bauen, es fehlt ein Seiten-Cache, Plugins und Theme erledigen zu viel Arbeit, oder Bilder und Skripte sind zu schwer für den Browser. Um WordPress schneller zu machen, findest du zuerst heraus, welche Ursache bei dir wirklich greift, und arbeitest sie dann der Reihe nach ab: erst die Serverantwort, zuletzt der Feinschliff im Frontend.
Erst messen, dann optimieren
Wer auf Verdacht Plugins deaktiviert oder den Hoster wechselt, verliert viel Zeit. Halte deshalb vorher fest, wo du stehst, damit du später vergleichen kannst.
- Echte Nutzerdaten: Gib deine URL auf corewebvitals.page ein. Hat deine Seite genug Besucher, siehst du dort Felddaten echter Chrome-Nutzer zu LCP, INP und CLS. Genau diese Werte zieht Google für die Page Experience heran.
- Labordaten: Der Lighthouse-Teil darunter simuliert einen einzelnen Seitenaufruf. Er hilft dir, Ursachen zu finden, der Score schwankt aber von Lauf zu Lauf.
- Serverantwort: Prüfe, wie lange allein das HTML braucht.
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/
Wiederhole den Test ein paar Mal und für verschiedene Seitentypen, also Startseite, Blogartikel und Kategorieseite. Dauert schon das erste Byte länger als etwa eine Sekunde, liegt das Problem auf dem Server. Dann hilft dir auch kein Bild-Plugin. Als grobe Orientierung empfiehlt web.dev eine TTFB von höchstens 0,8 Sekunden.
Wie du Labor- und Felddaten richtig liest und einen fairen Vorher-nachher-Vergleich aufsetzt, erklärt der Ratgeber Ladezeit einer Website richtig messen.
Hosting und Serverantwort
Bei jedem ungecachten Aufruf startet PHP, lädt den WordPress-Kern, alle aktiven Plugins und das Theme und schickt Dutzende bis Hunderte Datenbankabfragen ab. Wie schnell das geht, hängt stark vom Server ab.
Woran du erkennst, dass das Hosting bremst
- Die TTFB ist hoch, selbst auf schlichten Seiten mit wenig Inhalt.
- In Stoßzeiten oder direkt nach dem Newsletter-Versand wird die Seite spürbar langsamer.
- Das Backend ist zäh, obwohl dort keine Frontend-Dateien im Spiel sind.
- Im Dashboard deines Hosters siehst du, dass CPU- oder Speicherlimits erreicht werden.
Was du tun kannst
- PHP aktualisieren. Neuere PHP-Versionen sind in der Regel schneller und bekommen noch Sicherheitsupdates. Schau nach, welche Version dein Hoster anbietet, und teste deine Seite mit der neuesten, die deine Plugins unterstützen.
- Persistenten Objekt-Cache einrichten. Redis oder Memcached halten die Ergebnisse wiederkehrender Datenbankabfragen im Arbeitsspeicher. Viele Managed-Hoster bieten das per Schalter an. Am meisten bringt es auf dynamischen Seiten und im Backend.
- Tarif oder Hoster wechseln, wenn der Server für deinen Traffic schlicht zu klein ist. Manchmal ist das tatsächlich die richtige Lösung, denn fehlende CPU-Leistung gleicht kein Plugin-Tuning aus.
Ist die Antwortzeit dein Hauptproblem, geht der Ratgeber TTFB verbessern Schritt für Schritt auf Server, Anwendung und Edge ein.
Seiten-Caching
Für die meisten WordPress-Seiten ist der Seiten-Cache der größte Hebel. Statt dieselbe Seite für jeden Besucher neu mit PHP und MySQL zu bauen, liefert der Cache eine fertige HTML-Kopie aus. Einen guten Überblick über die verschiedenen Cache-Ebenen gibt das WordPress-Entwicklerhandbuch (auf Englisch).
Üblich sind drei Varianten:
| Variante | Wo der Cache liegt | Passt gut für |
|---|---|---|
| Cache-Plugin | Auf deinem Server, als Dateien oder im Speicher | Kleine Seiten, Shared Hosting |
| Cache beim Hoster | Im Webserver oder Proxy des Hosters | Managed WordPress Hosting |
| Edge-Cache / CDN | Auf Servern nah bei deinen Besuchern | Besucher aus mehreren Regionen, Traffic-Spitzen |
Diese Ebenen lassen sich kombinieren. Entscheidend ist, dass anonyme Besucher gecachtes HTML bekommen und persönliche Seiten ausgenommen bleiben.
Was nicht in den Cache gehört
- Eingeloggte Nutzer und wp-admin. WordPress setzt dafür Login-Cookies, und die meisten Caches umgehen bei diesen Cookies den Cache.
- Kommentar-Vorschauen und passwortgeschützte Beiträge.
- Warenkorb, Kasse und Kundenkonto, falls du einen Shop betreibst. Die Regeln dafür findest du im Ratgeber WooCommerce schneller machen.
Prüfen, ob der Cache greift
Schau dir die Response-Header an. Die meisten Caches setzen einen Header, der einen Treffer (HIT) oder Fehlschlag (MISS) anzeigt:
curl -sI https://example.com/ | grep -i -E "cache|age"
Steht bei jedem Aufruf MISS oder fehlt der Header ganz, umgeht irgendetwas den Cache. Häufige Ursachen sind ein Plugin, das bei jedem Besuch ein Cookie setzt, Cache-Control: no-cache von einem Sicherheits-Plugin oder Query-Parameter aus Tracking-Links.
Plugins und Theme
Wie viele Plugins du installiert hast, ist weniger wichtig als das, was sie tun. Ein einziges schlecht gebautes Plugin kann mehr Last erzeugen als zwanzig kleine.
Die teuren Plugins finden
- Installiere Query Monitor auf einer Staging-Kopie. Das Plugin zeigt dir für jeden Seitenaufruf die Datenbankabfragen, langsame Queries, externe HTTP-Anfragen und Hooks, aufgeschlüsselt nach Plugin.
- Achte auf Plugins, die beim Seitenaufruf externe Anfragen stellen, etwa Lizenzprüfungen, Social-Zähler oder extern geladene Schriften. Die Seite wartet dann auf einen fremden Server.
- Deaktiviere verdächtige Plugins auf Staging einzeln und miss danach die TTFB neu. In einem laufenden Shop solltest du das nicht tun.
Typische Bremsen
- Page Builder, die ihr komplettes CSS und JavaScript auf jeder Seite laden, auch dort, wo sie gar nicht genutzt werden.
- Slider, Popups und Chat-Widgets, die gleich mehrere Skripte im sichtbaren Bereich nachladen.
- Plugins für ähnliche Beiträge oder Statistiken, die bei jedem Aufruf aufwendige Abfragen starten.
- Mehrere Plugins für dieselbe Aufgabe, zum Beispiel zwei SEO- oder zwei Cache-Plugins.
Oft bringt ein schlankeres Theme mehr als jedes Optimierungs-Plugin. Bringt dein Theme ein großes Framework mit, von dem du kaum etwas nutzt, läuft dieser Code trotzdem auf jeder Seite.
Bilder und Medien
Bilder machen bei WordPress meist den größten Teil des Seitengewichts aus, und das Titelbild entscheidet oft über deinen LCP-Wert.
- Lade passende Größen hoch. Ein 4.000 Pixel breites Handyfoto hat in einer 800 Pixel breiten Inhaltsspalte nichts verloren. WordPress erzeugt zwar kleinere Varianten und nutzt
srcset, aber nur, wenn das Theme sie sauber ausgibt. - Setze auf moderne Formate. WebP und AVIF sind bei vergleichbarer Qualität deutlich kleiner als JPEG und PNG.
- Lazy Loading nur unterhalb des sichtbaren Bereichs. WordPress setzt
loading="lazy"automatisch. Wird aber das Titelbild verzögert geladen, verschlechtert sich der LCP. Sorg dafür, dass das Hauptbild sofort lädt. - Gib Breite und Höhe an, damit der Browser Platz reserviert und das Layout nicht springt (CLS).
Mehr zu Formaten, Größen und Ladestrategie liest du im Ratgeber Bilder für die Website optimieren.
Datenbank und Hintergrundprozesse
Ältere WordPress-Installationen sammeln mit der Zeit Ballast an, der jeden ungecachten Aufruf bremst.
- Autoload-Optionen: Plugins speichern Einstellungen in
wp_options. Einträge mit Autoload liest WordPress bei jedem Aufruf. Gelöschte Plugins hinterlassen dort oft große Datenmengen. Der Website-Zustand in aktuellen WordPress-Versionen warnt dich, wenn die Autoload-Daten zu groß werden. - Abgelaufene Transients und Revisionen blähen die Tabellen auf. Räum sie mit einem Wartungs-Plugin oder per WP-CLI auf, aber erst nach einem Backup.
- WP-Cron führt geplante Aufgaben standardmäßig bei normalen Seitenaufrufen aus. Auf gut besuchten Seiten schaltest du das in der
wp-config.phpab und lässt die Aufgaben stattdessen über einen echten Cronjob des Servers laufen:
define( 'DISABLE_WP_CRON', true );
- Heartbeat API: Offene Editor-Tabs schicken in regelmäßigen Abständen Anfragen an
admin-ajax.php. Auf schwachem Hosting summiert sich das. Einige Performance-Plugins können das Intervall verlängern.
Die richtige Reihenfolge
Die Reihenfolge spart dir Arbeit, denn die ersten Schritte machen spätere oft überflüssig.
- Messen: TTFB und Core Web Vitals für deine wichtigsten Seitentypen festhalten.
- Serverantwort verbessern: PHP-Version, Objekt-Cache, ausreichend Ressourcen.
- Seiten-Cache aktivieren für anonyme Besucher und die Cache-Header prüfen.
- Schwere Plugins entfernen oder ersetzen und das Theme verschlanken.
- Bilder optimieren: Größe, Format, kein Lazy Loading beim Titelbild.
- Datenbank aufräumen und WP-Cron auf einen Server-Cronjob umstellen.
- Erneut messen, mit denselben Tools und Seiten, und vergleichen.
Kommen deine Besucher aus mehreren Ländern, kostet auch die Entfernung zum Server bei jedem Aufruf Zeit, selbst wenn der Cache auf dem Server gut eingestellt ist. Genau hier setzt ein Edge-Cache an.
So hilft dir fast.site
fast.site arbeitet vor deinem bestehenden WordPress-Hosting. Du behältst deinen Hoster und deine Seite, legst deine Domain im Dashboard an und stellst die Nameserver auf fast.site um. Danach verwaltet fast.site dein DNS. Achte deshalb darauf, dass alle bisherigen Einträge in der DNS-Zone bei fast.site stehen, auch die MX-Einträge für deine E-Mails.
Anonyme Seitenaufrufe liefert dann der Fast Edge Cache™ von Edge-Servern in der Nähe deiner Besucher aus, in den Regionen, die dein Tarif umfasst. Ein Cache-HIT erreicht deinen Server gar nicht erst und nimmt ihm so in Stoßzeiten Last ab. Eingeloggte Sitzungen und wp-admin sollten am Cache vorbeigehen. Am Response-Header fs-cache siehst du für jede Seite selbst, ob HIT, MISS oder BYPASS vorliegt. Nach dem Veröffentlichen leerst du einzelne URLs im Dashboard oder per API, und der Cache-Warmer hält wichtige Seiten vorgewärmt.
Im Frontend wandelt fast.site JPEG und PNG auf Wunsch direkt in WebP um (AVIF je nach Tarif), lädt optional das Titelbild vor und ergänzt fehlende Bildmaße. Details findest du auf der WordPress-Seite und in der Caching-Dokumentation.
Miss deine Seite vorher und nachher mit denselben Tests. Ausprobieren kannst du das mit einer kostenlosen 7-Tage-Testphase, ganz ohne Kreditkarte.
Häufige Fragen
Warum ist WordPress nur langsam, wenn ich eingeloggt bin?
Die meisten Seiten-Caches lassen eingeloggte Nutzer außen vor, also baut PHP jede Seite für dich neu. Adminleiste und Editor-Skripte kommen noch obendrauf. Teste in einem privaten Fenster, dann siehst du, was deine Besucher tatsächlich bekommen.
Machen viele Plugins WordPress langsam?
Die Anzahl ist weniger entscheidend als das, was die Plugins tun. Einige wenige schwere Plugins mit langsamen Abfragen oder externen Anfragen bei jedem Aufruf kosten mehr als viele kleine. Mit Query Monitor auf einer Staging-Seite findest du die Übeltäter.
Reicht ein Cache-Plugin aus?
Für eine kleine Seite mit Besuchern aus der Region reicht ein gut eingestelltes Cache-Plugin auf ordentlichem Hosting oft aus. Kommen deine Besucher aus verschiedenen Regionen oder hast du Traffic-Spitzen, verkürzt ein Edge-Cache vor dem Server zusätzlich die Wege und entlastet deinen Server.
Warum ist das WordPress-Backend so langsam?
Das Backend wird nie gecacht. Es zeigt also die reine Geschwindigkeit von Server, Plugins und Datenbank. Ein zähes Backend deutet meist auf zu knappes Hosting, einen fehlenden Objekt-Cache, zu große Autoload-Optionen oder ein Plugin hin, das bei jedem Aufruf im Backend viel Arbeit erledigt.
Teste fast.site mit deiner eigenen Website
fast.site ergänzt dein bestehendes Hosting um Edge-Caching, Bildoptimierung und DDoS-Schutz. Verbinde deine Domain und miss den Unterschied auf deinen eigenen Seiten.
Gib deiner Website 7 Tage. Lass die Ergebnisse entscheiden.
Starte mit deiner eigenen Domain, deinem echten Traffic und Klarheit darüber, was danach passiert.