WordPress langsam? 9 Gründe und wie du sie behebst

Deine WordPress-Website braucht vier, fünf Sekunden zum Laden, das Admin-Panel ist träge, und der Kunde schreibt, dass es „bei ihm nur so läuft“. Das ist eines der häufigsten Probleme, mit denen Website-Besitzer zu uns kommen. Die gute Nachricht: In neun von zehn Fällen ist die Ursache eine von mehreren bekannten und kann innerhalb einer Stunde gefunden werden.

Nachfolgend findest du neun Gründe, warum WordPress langsam ist, beginnend mit den häufigsten. Bei jedem Punkt erklären wir, wie du ihn erkennst und selbst beheben kannst.

Inhaltsverzeichnis

1. Wie du überprüfst, ob WordPress wirklich langsam ist
2. Ist Shared Hosting schuld?
3. Hast du zu viele Plugins?
4. Sind deine Bilder zu groß?
5. Ist der Cache der Website aktiviert?
6. Welche PHP-Version verwendet deine Website?
7. Ist deine Datenbank überladen?
8. Ist dein Theme oder Page Builder zu schwerfällig?
9. Blockieren externe Skripte das Laden?
10. Frisst wp-cron Ressourcen?
11. Wo fängst du mit der Fehlerbehebung an?
12. FAQ

Wie findest du heraus, ob deine WordPress-Website wirklich langsam ist?

Bevor du etwas änderst, miss es. Ohne Messung weißt du nicht, ob eine Verbesserung tatsächlich etwas gebracht hat, und „es fühlt sich schneller an“ ist kein Ergebnis.

Drei Tools sind ausreichend:

• PageSpeed Insights (pagespeed.web.dev) zeigt dir die Google-Ergebnisse für mobile und Desktop-Geräte sowie die Core Web Vitals an. Am wichtigsten ist der LCP, also die Zeit, nach der das größte Element der Seite sichtbar wird. Ein gutes Ergebnis liegt unter 2,5 Sekunden.
• GTmetrix oder WebPageTest stellen den Ladevorgang in einem Wasserfalldiagramm dar. Darin siehst du, welche Datei am längsten lädt.
• TTFB (Time To First Byte), die Zeit bis zum ersten Byte der Serverantwort. Du kannst dies mit beiden Tools oder im Netzwerk-Tab deines Browsers (F12) überprüfen. Wenn der TTFB 600 ms überschreitet, liegt das Problem entweder beim Server oder bei PHP. Wenn der TTFB niedrig ist und die Seite trotzdem lange lädt, sind clientseitige Dateien schuld: Bilder, Skripte, Schriftarten.

Diese Unterscheidung ist entscheidend. Ein hoher TTFB weist auf Hosting-Probleme, fehlendes Caching, alte PHP-Versionen, eine überladene Datenbank oder wp-cron hin. Ein niedriger TTFB bei gleichzeitig langsamer Ladezeit deutet auf Bilder, ein überladenes Theme und externe Skripte hin. Plugins können beides beeinträchtigen.

Miss die Startseite und eine Unterseite, zum Beispiel einen Blogbeitrag oder eine Produktseite. Speichere die Ergebnisse, du wirst nach jeder Änderung darauf zurückkommen.

Ist das Shared Hosting schuld?

Das ist die häufigste Ursache, die Website-Betreiber meistens nicht vermuten, denn „ich bezahle doch für Hosting“.

Bei klassischem Shared Hosting liegt deine Website auf einem Server zusammen mit Hunderten anderen. Prozessor, Arbeitsspeicher und Festplatte werden geteilt. Wenn ein Nachbar einen Traffic-Anschub hat, einen Newsletter verschickt oder seine Website angegriffen wird, verlangsamt sich auch dein WordPress. Hinzu kommen PHP-Prozesslimits. Wenn mehrere Personen gleichzeitig einen Shop besuchen, warten weitere Anfragen in der Warteschlange.

Wie du es erkennst: Der TTFB springt. Morgens 300 ms, abends 2 Sekunden, ohne Änderungen an der Website. Im Hosting-Panel siehst du Meldungen über die Überschreitung des Ressourcenlimits (oft als „resource limit reached“ oder „508“ bezeichnet).

Wie du es behebst: Die Website-Optimierung hilft nur teilweise. Wenn der Server durch andere überlastet ist, musst du das Hosting auf eines umstellen, bei dem dir Ressourcen zugewiesen sind. Bei Saplo ist jede Box ein separater Container mit eigenem RAM und Speicherplatz. Box S hat 1 GB RAM, Box M 2 GB, Box L 6 GB, und niemand von außen verbraucht diesen Speicher. Details zu den Plänen findest du in der Preisliste.

Hast du zu viele Plugins?

Die reine Anzahl der Plugins ist kein Problem. Eine Website mit vierzig leichten Plugins kann schneller laufen als eine Website mit zehn schweren. Das Problem sind Plugins, die bei jedem Seitenaufruf viele Datenbankabfragen durchführen oder ihre Skripte auf jeder Unterseite laden, auch dort, wo sie nicht benötigt werden.

Die häufigsten Übeltäter sind umfangreiche serverseitige Statistik-Plugins, „All-in-One“-Sicherheits-Plugins, die Dateien während des Betriebs scannen, und Plugins für verwandte Beiträge, Slider und Formulare, die global geladen werden.

So erkennst du sie: Installiere das kostenlose Plugin Query Monitor. In der Admin-Leiste zeigt es die Seitenladezeit, die Anzahl der Datenbankabfragen und, welches Plugin wie viele davon sendet. Eine Seite, die länger als 0,5 Sekunden geladen wird oder mehrere hundert Abfragen hat, hat ein Problem.

So behebst du es:

1. Erstelle eine Sicherung deiner Website.
2. Deaktiviere Plugins, die du seit Monaten nicht benutzt hast. Lösche sie, deaktiviere sie nicht nur.
3. Suche für schwere Plugins leichtere Alternativen.
4. Verwende ein Plugin wie Asset CleanUp oder Perfmatters, um das Laden von Plugin-Skripten dort zu deaktivieren, wo sie unnötig sind (z. B. Skripte für Kontaktformulare nur auf der Kontaktseite).
5. Messe erneut.

Sind deine Bilder zu groß?

Ein Foto direkt von der Kamera oder dem Handy wiegt 4 bis 8 MB und ist 4000 Pixel breit. Auf der Webseite wird es mit einer Breite von 800 Pixeln angezeigt, aber der Browser muss trotzdem die gesamte Datei herunterladen. Drei solcher Bilder auf der Startseite und dein LCP steigt auf mehrere Sekunden, besonders auf dem Handy.

Wie du es erkennst: In PageSpeed Insights erscheinen die Empfehlungen „Bilder in modernen Formaten bereitstellen“ und „Bilder passend skalieren“. Im Wasserfall-Diagramm sind die längsten Balken JPG- oder PNG-Dateien.

So behebst du es:

• Reduziere die Bilder vor dem Hochladen auf eine sinnvolle Breite, normalerweise 1600 bis 2000 Pixel für vollbreite Bilder.
• Aktiviere die Konvertierung in das WebP- oder AVIF-Format. Das übernehmen Plugins wie Converter for Media, EWWW Image Optimizer oder ShortPixel.
• Stelle sicher, dass Lazy Loading funktioniert. WordPress fügt es seit Version 5.5 von selbst hinzu, aber einige Themes deaktivieren es.
• Lade das ganz oben auf der Seite sichtbare Bild (z. B. ein Header-Bild) nicht lazy. Es ist ausschlaggebend für den LCP.

Hat die Seite Cache aktiviert?

Ohne Cache startet WordPress bei jedem Zugriff PHP, verbindet sich mit der Datenbank, setzt die Seite aus Dutzenden von Abfragen zusammen und sendet sie erst dann an den Browser. Bei zehn gleichzeitigen Besuchern erledigt der Server dieselbe Arbeit zehnmal.

Es gibt zwei Arten von Cache, die du unterscheiden solltest:

• Seiten-Cache speichert fertiges HTML und liefert es den nächsten Besuchern, ohne PHP auszuführen. Dies bieten Plugins wie WP Super Cache, W3 Total Cache, LiteSpeed Cache (nur auf LiteSpeed-Servern) oder WP Rocket (kostenpflichtig).
• Objekt-Cache speichert die Ergebnisse von Datenbankabfragen im Arbeitsspeicher, meist in Redis. Er hilft dort, wo der Seiten-Cache nicht funktioniert: im Admin-Panel, im Warenkorb und im Kundenkonto eines WooCommerce-Shops.

So erkennst du es: Überprüfe im Query Monitor, ob der Objekt-Cache aktiv ist. Die TTFB auf einer Seite, die du zum zweiten Mal aktualisierst, sollte deutlich sinken. Wenn nicht, funktioniert der Seiten-Cache nicht.

So behebst du es: Installiere ein Seiten-Cache-Plugin (nicht zwei gleichzeitig, da sie sich gegenseitig stören) und aktiviere den Objekt-Cache, wenn dein Hosting Redis anbietet. Bei Saplo verbindet die WordPress-Installation aus dem Katalog automatisch ein lokales Redis in der Box und aktiviert das Redis Object Cache Plugin, mit einem separaten Präfix und einer Datenbank für jede Seite. Du musst nichts manuell konfigurieren.

Welche PHP-Version verwendet deine Website?

WordPress ist in PHP geschrieben, und jede neue PHP-Version ist schneller als die vorherige. Der Unterschied zwischen PHP 7.4 und PHP 8.3 kann bei der gleichen Website deutlich spürbar sein, besonders im Admin-Panel und bei großen Shops. Außerdem erhält PHP 7.4 keine Sicherheitsupdates mehr.

So erkennst du es: Gehe im WordPress-Adminbereich zu "Werkzeuge", dann "Website-Zustand", dann "Informationen", Abschnitt "Server". Dort siehst du die PHP-Version und das Speicherlimit.

So behebst du es:

1. Erstelle ein Backup.
2. Aktualisiere WordPress, Theme und Plugins auf die neuesten Versionen. Alte Plugins können mit neueren PHP-Versionen inkompatibel sein.
3. Ändere die PHP-Version im Hosting-Panel auf 8.2 oder 8.3.
4. Überprüfe die Startseite, das Formular, den Warenkorb und das Admin-Panel. Wenn etwas nicht funktioniert, kehre zur vorherigen Version zurück und finde heraus, welches Plugin inkompatibel ist.

Bei Saplo wählst du bei der WordPress-Installation die PHP-Version aus einer Liste von 7.4 bis 8.5. Standardmäßig verwenden wir 8.3, da praktisch jedes aktuelle Plugin damit kompatibel ist.

Ist die Datenbank nicht überladen?

Die WordPress-Datenbank bläht sich mit der Zeit auf. Darin sammeln sich Beitragsrevisionen (jede Speicherung erzeugt eine neue Kopie), Beiträge im Papierkorb, Kommentar-Spam, abgelaufene temporäre Daten (Transients) und Optionen von Plugins, die du längst gelöscht hast. Besonders kritisch ist die Tabelle wp_options. Einige ihrer Zeilen lädt WordPress bei jedem Seitenaufruf (Optionen mit dem Autoload-Flag). Wenn sie auf mehrere Megabyte anwächst, verlangsamt das jeden Aufruf.

Wie zu erkennen: Ab WordPress Version 6.6 warnt der Website-Zustand selbst vor zu großen Autoload-Optionen. Im Query Monitor sind langsame Datenbankabfragen sichtbar.

Wie zu beheben:

• Begrenze die Anzahl der Revisionen, indem du dem File wp-config.php die Zeile define('WP_POST_REVISIONS', 5); hinzufügst.
• Bereinige die Datenbank mit dem Plugin WP-Optimize oder Advanced Database Cleaner: Revisionen, Papierkorb, Spam, abgelaufene Transients.
• Entferne Optionen von deinstallierten Plugins. Advanced Database Cleaner zeigt an, zu welchem Plugin eine Option gehört.
• Erstelle vor der Bereinigung immer eine Datenbankkopie.

Sind das Theme oder der Page Builder zu groß?

„Multifunktionale“ Themes, die mit Hunderten von vorgefertigten Layouts verkauft werden, laden Skripte und Stile für alle ihre Funktionen auf jeder Seite, auch für die, die du nicht verwendest. Page Builder (Elementor, Divi, WPBakery) fügen tief verschachtelten HTML-Code und eigene CSS- und JS-Dateien hinzu.

Das bedeutet nicht, dass der Builder raus muss. Es bedeutet, dass er richtig konfiguriert werden muss.

So erkennst du es: In PageSpeed Insights weisen die Empfehlungen „Ungenutztes JavaScript reduzieren“ und „Ungenutztes CSS reduzieren“ auf Theme- oder Builder-Dateien hin. Die Seite hat mehrere Megabyte an Skripten.

So behebst du es:

• Aktiviere in Elementor in den Einstellungen die Leistungsfunktionen (optimiertes Laden von Ressourcen, Laden von CSS in einer Datei statt inline).
• Deaktiviere im Theme Module, die du nicht verwendest (Slider, Icons, Animationen).
• Wenn du eine neue Seite erstellst, ziehe ein leichtes Theme, zum Beispiel GeneratePress, Kadence oder Astra, und einen Block-Editor anstelle eines schweren Builders in Betracht.

Blockieren externe Skripte das Laden?

Ein Chat auf der Website, ein Facebook-Pixel, Google Analytics, Tag Manager mit zehn Tags, eine Google-Karte, ein eingebettetes YouTube-Video, ein Bewertungs-Widget, Schriftarten von Google Fonts. Jedes davon ist eine separate Verbindung zu einem anderen Server und weitere Kilobyte an Skripten, über die du keine Kontrolle hast.

Wie zu erkennen: Im Wasserfalldiagramm siehst du viele Dateien von fremden Domains. PageSpeed Insights zeigt die Empfehlung „Reduzieren Sie den Einfluss von Drittanbieter-Code“.

So behebst du das Problem:

• Überprüfe den Tag Manager und entferne Tags von alten Kampagnen.
• Lade den Chat erst nach Benutzerinteraktion oder nach einigen Sekunden.
• Bette YouTube-Videos als Miniaturansicht ein, die den Player erst nach dem Anklicken lädt (das macht z.B. WP YouTube Lyte).
• Lade Schriftarten auf deinen eigenen Server herunter, anstatt sie von Google Fonts zu laden. Damit löst du übrigens auch die DSGVO-Frage.

Frisst wp-cron keine Ressourcen auf?

WordPress verfügt über einen integrierten Aufgabenplaner, wp-cron. Dieser funktioniert nicht wie ein echter System-Cron-Job, sondern wird nur bei Besucherzugriffen ausgeführt. Auf einer Website mit hohem Traffic wird er zu oft ausgelöst, und auf einer Website mit geringem Traffic werden Aufgaben (Veröffentlichung geplanter Beiträge, Backups, E-Mail-Versand aus dem Shop) verzögert ausgeführt und können einen zufälligen Zugriff verlangsamen, der sie gerade ausgelöst hat.

So erkennst du es: Einzelne Zugriffe sind ohne ersichtlichen Grund deutlich langsamer als die übrigen. Das Plugin WP Crontrol zeigt eine Liste der Aufgaben und oft auch Aufgaben von gelöschten Plugins an, die jahrelang hängen bleiben.

So behebst du es:

1. Lösche in WP Crontrol Aufgaben von Plugins, die du nicht mehr hast.
2. Deaktiviere die Ausführung von wp-cron durch Besucher, indem du die Zeile define('DISABLE_WP_CRON', true); zu wp-config.php hinzufügst.
3. Richte einen echten System-Cron-Job ein, der alle 5 Minuten wp cron event run --due-now oder die Adresse wp-cron.php aufruft. Auf Saplo hast du ab Box M SSH-Zugriff mit vollem sudo, sodass du dies in einer Zeile des Crontabs einrichten kannst.

Wo soll man mit der Reparatur anfangen?

Wenn du nicht weißt, wo du anfangen sollst, gehe in dieser Reihenfolge vor, denn von oben nach unten sind die Änderungen am günstigsten und haben den größten Effekt:

1. Messe die Seite in PageSpeed Insights und notiere TTFB und LCP.
2. Erstelle eine Sicherungskopie der gesamten Seite und der Datenbank.
3. Aktualisiere WordPress, Plugins und PHP auf 8.2 oder 8.3.
4. Aktiviere den Seiten-Cache und, wenn möglich, den Objekt-Cache in Redis.
5. Optimiere die Bilder und konvertiere sie zu WebP.
6. Überprüfe die Plugins in Query Monitor und entferne unnötige.
7. Bereinige die Datenbank und beschränke die Revisionen.
8. Entlaste externe Skripte und richte das Theme ein.
9. Messe erneut. Wenn der TTFB immer noch je nach Tageszeit schwankt, liegt das Problem beim Hosting und nicht bei der Seite.

Im letzteren Fall hilft kein Plugin. Die Seite muss dorthin verschoben werden, wo die Serverressourcen nur dir gehören. Wenn du Saplo in Betracht ziehst, verschieben wir WordPress für dich: Die Migration ist kostenlos, zusammen mit der Datenbank und E-Mail, ohne Ausfallzeiten der Seite. Mehr darüber, wie WordPress auf Saplo funktioniert, findest du auf der Seite WordPress im App-Katalog und auf der Seite WordPress Hosting.

FAQ

Wie viele Plugins sind zu viele in WordPress?

Es gibt keine feste Grenze. Es kommt darauf an, was die Plugins tun, nicht auf ihre Anzahl. Eine Website mit dreißig leichten Plugins kann schnell laufen, während ein einziges schlecht geschriebenes Plugin sie lahmlegen kann. Überprüfe die Seiten-Generierungszeit und die Anzahl der Anfragen im Query Monitor, anstatt die Anzahl der Einträge in einer Liste zu zählen.

Reicht ein Cache-Plugin aus, um WordPress zu beschleunigen?

Oft bringt es den größten einmaligen Leistungssprung, löst aber nicht alles. Website-Cache funktioniert nicht im Admin-Panel, im Warenkorb oder für eingeloggte Shop-Kunden. Hier helfen Object Cache in Redis, aktuelles PHP und Ordnung bei den Plugins. Ein Cache behebt auch keine großen Bilder oder einen überlasteten Server.

Warum ist mein WordPress Admin-Panel langsam, aber meine Website schnell?

Das liegt daran, dass deine Besucher fertige, gecachte Seiten erhalten, während das Admin-Panel immer in Echtzeit von PHP und der Datenbank generiert wird. Ein langsames Panel ist oft ein Zeichen für aufwendige Plugins, eine überfüllte Tabelle wp_options, veraltetes PHP oder das Fehlen eines Object Cache. Beginne mit dem Query Monitor, der im Panel geöffnet ist.

Welcher PageSpeed Insights-Score ist gut?

Ein Score von 90 oder höher ist sehr gut, 50 bis 89 erfordert Verbesserungen. Wichtiger als die Zahl selbst sind die Core Web Vitals-Indikatoren: LCP unter 2,5 Sekunden, INP unter 200 ms und CLS unter 0,1. Sie beeinflussen die Bewertung der Seite in Google.

Beschleunigt ein Hosting-Wechsel WordPress?

Ja, wenn die Ursache der Server ist, d.h. ein hoher und instabiler TTFB sowie Meldungen über Ressourcenlimits. Nein, wenn die Website über große Bilder und Dutzende unnötiger Skripte verfügt, da dieselben Dateien vom neuen Server heruntergeladen werden müssen. Zuerst messen, dann entscheiden.