Eine langsame WordPress-Website kann viele Ursachen haben. Große Bilder, zu viele oder schlecht programmierte Plugins, langsame Datenbankabfragen, externe Dienste, fehlendes Caching, WP-Cron, PHP-Prozesse oder ausgelastete Hosting-Ressourcen können die Ladezeit einzeln oder gemeinsam beeinflussen.
Deshalb gibt es keine seriöse Universallösung nach dem Muster „Installiere dieses eine Performance-Plugin und WordPress ist schnell“. Bevor du optimierst, solltest du herausfinden, welcher Teil der Website tatsächlich langsam ist.
Eine gute Performance-Analyse unterscheidet beispielsweise zwischen einer langsamen Serverantwort, einer aufwendigen WordPress-Verarbeitung und einem Frontend, das erst im Browser durch Bilder, JavaScript, CSS, Webfonts oder externe Dienste ausgebremst wird.
Kurz erklärt: Miss zuerst, bevor du optimierst. Ist bereits die erste Serverantwort langsam, solltest du PHP, Datenbank, Plugins, WordPress-Prozesse und Hosting-Ressourcen untersuchen. Kommt die HTML-Seite schnell, benötigt der Browser danach aber lange für die Darstellung, liegen die Ursachen eher bei Bildern, CSS, JavaScript, Fonts oder externen Ressourcen.
Was bedeutet „WordPress ist langsam“ überhaupt? #
Die Aussage kann sehr unterschiedliche Probleme beschreiben.
Vielleicht benötigt die öffentliche Website mehrere Sekunden, bis überhaupt etwas passiert. Vielleicht erscheint die Seite schnell, Bilder und andere Elemente laden aber lange nach. In anderen Fällen ist nur der WordPress-Adminbereich langsam oder ausschließlich der WooCommerce-Checkout reagiert verzögert.
Diese Situationen haben nicht zwangsläufig dieselbe Ursache.
Deshalb sollte eine Performance-Optimierung immer mit einer möglichst genauen Beschreibung des Problems beginnen.
Frontend und WordPress-Adminbereich getrennt betrachten #
Eine Website kann im Frontend schnell sein und gleichzeitig einen langsamen Adminbereich besitzen.
Das ist technisch durchaus möglich. Öffentliche Seiten können beispielsweise aus einem Page Cache ausgeliefert werden, während Anfragen innerhalb von:
/wp-admin/
dynamisch durch WordPress und PHP verarbeitet werden müssen.
Wenn nur der Adminbereich langsam ist, solltest du deshalb nicht automatisch Bilder auf der Startseite optimieren. Umgekehrt erklärt ein langsames Hero-Bild nicht zwangsläufig einen trägen WordPress-Editor.
Die Ladezeit besteht aus mehreren Abschnitten #
Beim Aufruf einer WordPress-Seite passieren vereinfacht mehrere Dinge.
Der Browser muss die Domain erreichen und eine Verbindung herstellen. Der Webserver verarbeitet die Anfrage. Falls die Seite nicht bereits aus einem Cache geliefert werden kann, startet PHP die WordPress-Anwendung. WordPress lädt unter anderem Plugins und Theme, führt Datenbankabfragen aus und erzeugt das HTML-Dokument.
Erst danach beginnt im Browser ein weiterer wichtiger Teil: HTML wird verarbeitet und zusätzliche Ressourcen wie Stylesheets, JavaScript, Bilder und Fonts werden geladen.
Eine Gesamtangabe wie „die Seite lädt in vier Sekunden“ sagt deshalb noch nicht, an welcher Stelle diese Zeit verloren geht.
Was ist TTFB? #
TTFB steht für Time to First Byte. Vereinfacht beschreibt dieser Messwert, wie lange es dauert, bis nach einer Anfrage das erste Byte der Serverantwort beim Client eintrifft.
Eine hohe TTFB kann ein Hinweis auf Probleme im serverseitigen Bereich sein. Sie beweist jedoch nicht automatisch, dass der Hosting-Server zu langsam ist.
In die gemessene Zeit können mehrere Faktoren einfließen, darunter Netzwerk, Verbindungsaufbau, Serververarbeitung und bei dynamischem WordPress insbesondere die benötigte PHP- und Datenbankverarbeitung.
Wichtig: Eine hohe TTFB und ein langsames visuelles Rendering sind nicht dasselbe. Eine WordPress-Seite kann serverseitig schnell antworten und anschließend durch große Frontend-Ressourcen trotzdem langsam erscheinen.
Page Cache verändert die WordPress-Performance grundlegend #
Ohne Page Cache muss WordPress für einen normalen Seitenaufruf typischerweise PHP ausführen, WordPress laden, Plugins und Theme berücksichtigen, Datenbankabfragen durchführen und daraus HTML erzeugen.
Ein Page Cache kann bereits erzeugtes HTML zwischenspeichern und bei geeigneten Anfragen erneut ausliefern.
Dadurch muss WordPress nicht bei jedem anonymen Seitenaufruf den vollständigen dynamischen Prozess erneut durchführen.
Das kann insbesondere bei normalen Inhaltsseiten einen erheblichen Performance-Unterschied verursachen.
Nicht jede Seite darf gleich gecacht werden #
Bei dynamischen Websites muss Caching gezielt eingesetzt werden.
Ein WooCommerce-Warenkorb, Checkout oder personalisierter Mitgliederbereich darf beispielsweise nicht einfach so behandelt werden wie ein öffentlicher Blogbeitrag.
Auch angemeldete Benutzer benötigen je nach Anwendung individuelle Inhalte.
Eine falsche Cache-Konfiguration kann deshalb zwar schnell sein, gleichzeitig aber funktionale Fehler oder falsche Inhalte verursachen.
Cache ist keine Reparatur für langsamen Code #
Page Caching kann viele öffentliche Seiten erheblich beschleunigen. Es sollte aber nicht dazu verwendet werden, grundlegende Probleme vollständig zu verdecken.
Wenn eine nicht gecachte WordPress-Anfrage extrem lange dauert, können beispielsweise ineffiziente Plugins, Datenbankprobleme oder externe API-Aufrufe dahinterstecken.
Diese Ursachen können weiterhin im Adminbereich, bei eingeloggten Benutzern, im Checkout oder bei nicht gecachten Anfragen auftreten.
Praxis-Tipp: Prüfe bei einer Performance-Analyse nach Möglichkeit sowohl einen normalen gecachten Seitenaufruf als auch Bereiche, die dynamisch verarbeitet werden. Eine schnelle Startseite beweist nicht, dass die gesamte WordPress-Anwendung schnell arbeitet.
Plugins können WordPress erheblich verlangsamen #
Die reine Anzahl installierter Plugins ist kein zuverlässiger Performance-Messwert.
Eine Website mit 30 schlanken Plugins kann schneller arbeiten als eine Website mit fünf sehr aufwendigen Erweiterungen.
Entscheidend ist, was ein Plugin bei einer Anfrage tatsächlich tut.
Ein Plugin kann beispielsweise viele Datenbankabfragen erzeugen, externe Dienste kontaktieren, große Mengen JavaScript laden oder bei jedem Seitenaufruf rechenintensive Operationen durchführen.
„Zu viele Plugins“ ist als Diagnose zu ungenau #
Die Empfehlung, einfach möglichst viele Plugins zu löschen, greift deshalb zu kurz.
Wenn WordPress langsam ist, solltest du die Erweiterungen identifizieren, die tatsächlich auffällig sind.
Besonders interessant sind Plugins, nach deren Installation oder Update sich die Performance deutlich verändert hat.
Auch funktional überlappende Erweiterungen solltest du prüfen. Mehrere Plugins für dieselbe Aufgabe können nicht nur unnötige Komplexität erzeugen, sondern sich teilweise gegenseitig beeinflussen.
Wie du Erweiterungen kontrolliert gegeneinander testest, erklären wir unter Plugin- oder Theme-Konflikte in WordPress erkennen und beheben.
Das Theme beeinflusst die Ladezeit ebenfalls #
Das aktive Theme bestimmt einen wesentlichen Teil der Frontend-Ausgabe. Es kann Stylesheets, JavaScript, Fonts, Bilder und zusätzliche Funktionen laden.
Ein sehr umfangreiches Theme kann deshalb mehr Ressourcen benötigen als ein schlankes Theme.
Das bedeutet jedoch nicht, dass ein minimalistisches Theme automatisch jede WordPress-Website schnell macht. Page Builder, Plugins, Bilder und individuelle Funktionen können weiterhin den größten Teil der Last verursachen.
Theme und restliche Website sollten deshalb gemeinsam betrachtet werden.
Page Builder differenziert beurteilen #
Page Builder ermöglichen komplexe Layouts, können dafür aber zusätzliches HTML, CSS und JavaScript erzeugen.
Ob das in der Praxis problematisch ist, hängt stark davon ab, wie die Website aufgebaut wurde.
Viele verschachtelte Container, Animationen, Slider, Videos, große Hintergrundbilder und zahlreiche Widgets können eine Seite deutlich aufwendiger machen.
Statt pauschal den Page Builder verantwortlich zu machen, solltest du untersuchen, welche Ressourcen und Elemente auf der konkreten Seite tatsächlich geladen werden.
Bilder gehören zu den häufigsten Frontend-Bremsen #
Ein hochauflösendes Foto direkt aus einer Kamera oder einem Smartphone kann mehrere Megabyte groß sein. Wird ein solches Bild unverändert auf einer Website eingesetzt, muss der Besucher diese Daten übertragen, obwohl das Bild möglicherweise nur mit einer Breite von wenigen hundert Pixeln dargestellt wird.
Deshalb sollten Bilder passend dimensioniert und sinnvoll komprimiert werden.
Moderne Bildformate können die übertragene Datenmenge zusätzlich reduzieren, sofern sie zur jeweiligen Website und Browserunterstützung passen.
Bildabmessungen und Dateigröße sind nicht dasselbe #
Ein Bild kann beispielsweise Abmessungen von:
5000 × 3333 Pixel
besitzen, obwohl es auf der Website nur mit:
800 × 533 Pixel
angezeigt wird.
Die bloße visuelle Verkleinerung durch CSS reduziert nicht automatisch die ursprüngliche Bilddatei, die übertragen werden muss.
Deshalb sollten Bilddimensionen bereits zur tatsächlichen Verwendung passen.
Lazy Loading sinnvoll einsetzen #
Bilder und andere Ressourcen, die sich weit unterhalb des zunächst sichtbaren Bereichs befinden, müssen nicht immer sofort geladen werden.
Lazy Loading kann solche Ressourcen verzögert laden, bis sie benötigt werden.
Das reduziert die anfängliche Datenmenge.
Ein wichtiges Bild im direkt sichtbaren Bereich sollte jedoch nicht unüberlegt künstlich verzögert werden. Performance-Optimierung bedeutet nicht, jede Ressource grundsätzlich so spät wie möglich zu laden.
JavaScript kann die Darstellung ausbremsen #
Moderne WordPress-Websites verwenden häufig JavaScript für Navigationen, Slider, Formulare, Tracking, Consent-Systeme, Page Builder und viele weitere Funktionen.
Zu viel oder ungünstig geladenes JavaScript kann die Verarbeitung im Browser verzögern.
Besonders auf langsameren Mobilgeräten ist nicht nur die Dateigröße relevant. JavaScript muss heruntergeladen, analysiert und ausgeführt werden.
Deshalb kann eine kleinere Datei trotzdem teuer sein, wenn sie viel Rechenarbeit verursacht.
JavaScript verzögern – aber kontrolliert #
Performance-Plugins bieten häufig Funktionen wie verzögertes oder aufgeschobenes Laden von JavaScript.
Das kann die initiale Darstellung verbessern, darf aber nicht blind aktiviert werden.
Werden abhängige Skripte in der falschen Reihenfolge geladen, können beispielsweise Menüs, Formulare, Slider oder andere interaktive Elemente ausfallen.
Nach solchen Optimierungen solltest du die wichtigsten Funktionen der Website deshalb immer testen.
CSS kann ebenfalls zum Flaschenhals werden #
Große Stylesheets oder viele unterschiedliche CSS-Dateien erhöhen den Aufwand im Browser.
Besonders problematisch kann CSS sein, das für die initiale Darstellung benötigt wird, aber erst spät verfügbar ist.
Auch hier gilt jedoch: Eine möglichst geringe Anzahl von Dateien ist nicht automatisch das alleinige Ziel. Moderne Übertragungsprotokolle und Cache-Mechanismen verändern die Bewertung gegenüber älteren Optimierungsregeln.
Entscheidend ist das tatsächliche Ladeverhalten der Website.
Webfonts kosten zusätzliche Requests #
Individuelle Webfonts können die Gestaltung verbessern, verursachen aber zusätzliche Ressourcen.
Besonders viele Schriftfamilien, Schriftschnitte und externe Font-Dienste können die Ladezeit erhöhen.
Prüfe deshalb, welche Schriftvarianten tatsächlich verwendet werden.
Werden externe Font-Dienste eingesetzt, sind neben Performance auch Datenschutzanforderungen zu berücksichtigen.
Externe Dienste können eine schnelle Website langsam machen #
Nicht jede Ressource einer WordPress-Seite wird vom eigenen Server geladen.
Typische externe Komponenten sind beispielsweise Analyse- und Trackingdienste, Karten, Videos, Social-Media-Widgets, Werbenetzwerke, Chat-Systeme oder externe Schriftarten.
Die Performance dieser Dienste liegt teilweise außerhalb der Kontrolle des eigenen WordPress-Servers.
Wenn eine Seite serverseitig schnell antwortet, im Browser aber lange nachlädt, solltest du deshalb auch Drittanbieter-Requests untersuchen.
Eingebettete Videos nicht unterschätzen #
Ein eingebettetes Video kann zusätzliche JavaScript-Dateien, Vorschaubilder, Verbindungen und weitere Ressourcen eines externen Anbieters laden.
Bei mehreren Videos kann sich dieser Effekt vervielfachen.
Je nach Website kann es sinnvoll sein, externe Medien erst nach einer Benutzerinteraktion vollständig zu laden.
Die WordPress-Datenbank als Performance-Faktor #
WordPress speichert Inhalte, Einstellungen und viele Plugin-Daten in einer relationalen Datenbank.
Bei einem Seitenaufruf führen WordPress, Theme und Plugins Abfragen gegen diese Datenbank aus.
Die reine Größe der Datenbank ist dabei nicht automatisch entscheidend. Eine große, sinnvoll strukturierte Datenbank kann problemlos funktionieren, während eine kleinere Datenbank durch ineffiziente Abfragen Performance-Probleme verursacht.
Langsame Datenbankabfragen erkennen #
Wenn eine dynamische WordPress-Anfrage langsam ist, können einzelne Datenbankabfragen einen erheblichen Anteil daran haben.
Besonders Plugins mit komplexen Such-, Filter-, Statistik- oder Reporting-Funktionen können anspruchsvolle Queries erzeugen.
Eine professionelle Analyse sollte deshalb nicht nur fragen, wie groß die Datenbank ist, sondern welche Abfragen tatsächlich lange benötigen und wie häufig sie ausgeführt werden.
wp_options und Autoload #
Die WordPress-Tabelle für Optionen enthält Konfigurationsdaten von WordPress und Plugins. Bestimmte Optionen werden automatisch bei vielen WordPress-Anfragen geladen.
Wenn Plugins dort sehr große oder unnötige automatisch geladene Daten hinterlassen, kann das die Performance beeinträchtigen.
Solche Einträge sollten allerdings nicht anhand ihres Namens wahllos aus der Datenbank gelöscht werden.
Achtung: Datenbank-„Bereinigungen“ können Einstellungen oder Plugin-Daten dauerhaft entfernen. Erstelle vor manuellen Eingriffen ein Backup und lösche nur Daten, deren Funktion und Herkunft eindeutig geklärt sind.
Transients und temporäre Daten #
WordPress und Plugins können sogenannte Transients verwenden, um Daten temporär zwischenzuspeichern.
Transients sind grundsätzlich kein Fehler und gehören zum normalen WordPress-Mechanismus.
Problematisch können fehlerhafte Implementierungen oder ungewöhnlich große Mengen an temporären Daten werden.
Das pauschale Löschen sämtlicher Transients ist jedoch keine dauerhafte Performance-Strategie. Wenn sie unmittelbar wieder in problematischer Menge entstehen, muss die Ursache untersucht werden.
Revisionen sind nicht automatisch das Problem #
WordPress kann frühere Bearbeitungsstände von Beiträgen und Seiten als Revisionen speichern.
Auf lange betriebenen Websites können dadurch viele Datensätze entstehen.
Das bedeutet aber nicht, dass einige hundert oder tausend Revisionen automatisch die Ursache einer langsamen Website sind.
Eine Datenbank sollte anhand realer Messwerte optimiert werden und nicht aufgrund pauschaler Annahmen.
Object Cache und Page Cache unterscheiden #
Page Cache und Object Cache lösen unterschiedliche Aufgaben.
Ein Page Cache speichert vereinfacht bereits erzeugte Seitenausgaben. Ein persistenter Object Cache kann dagegen Ergebnisse und Daten, die WordPress während seiner Verarbeitung benötigt, über einzelne Requests hinaus zwischenspeichern.
Technologien wie Redis können als Backend für einen persistenten Object Cache eingesetzt werden.
Das kann insbesondere bei dynamischen WordPress-Anwendungen mit wiederkehrenden Datenbankzugriffen hilfreich sein.
Ein Object Cache ersetzt jedoch keinen Page Cache und beseitigt auch keinen schlecht programmierten Code.
WooCommerce stellt andere Anforderungen als ein Blog #
Ein einfacher Blog besteht überwiegend aus öffentlich lesbaren Inhalten. Viele Seiten lassen sich deshalb sehr effektiv cachen.
Ein WooCommerce-Shop besitzt dagegen zahlreiche dynamische Vorgänge. Warenkorb, Checkout, Kundenkonto, Lagerbestand, Preise und weitere Funktionen können benutzer- oder zustandsabhängig sein.
Deshalb muss Performance bei WooCommerce differenzierter betrachtet werden.
Eine hervorragend gecachte Shop-Startseite sagt beispielsweise wenig darüber aus, wie schnell der Checkout oder eine komplexe Produktsuche verarbeitet wird.
wp-admin langsam: Plugins und Hintergrundprozesse prüfen #
Wenn ausschließlich der WordPress-Adminbereich langsam ist, solltest du untersuchen, welche Prozesse dort stattfinden.
Plugins können Dashboard-Widgets laden, externe Lizenzserver kontaktieren, Statistiken berechnen oder im Hintergrund Daten verarbeiten.
Auch eine große Anzahl administrativer AJAX- oder REST-Anfragen kann relevant sein.
Da der Adminbereich normalerweise nicht wie eine öffentliche Seite vollständig gecacht werden kann, werden ineffiziente Prozesse dort besonders sichtbar.
admin-ajax.php richtig einordnen #
WordPress und Plugins können die Datei:
wp-admin/admin-ajax.php
für AJAX-Anfragen verwenden.
Viele Zugriffe darauf sind nicht automatisch problematisch. Wenn jedoch sehr häufige oder besonders langsame AJAX-Anfragen auftreten, sollte geprüft werden, welche Funktion beziehungsweise welches Plugin sie auslöst.
Das bloße Blockieren von admin-ajax.php ist keine sinnvolle allgemeine Performance-Lösung und kann Funktionen der Website beschädigen.
WordPress REST API nicht pauschal deaktivieren #
WordPress und moderne Plugins verwenden die REST API für zahlreiche Funktionen.
Sie aus Performance-Gründen vollständig zu deaktivieren, kann den Block-Editor oder Erweiterungen beeinträchtigen.
Wenn REST-Anfragen auffällig viel Last erzeugen, sollte die verursachende Anwendung beziehungsweise Route identifiziert werden.
WP-Cron kann die Performance beeinflussen #
WordPress verwendet standardmäßig WP-Cron, um geplante Aufgaben auszuführen.
Dazu gehören je nach Website beispielsweise geplante Beiträge, Wartungsaufgaben und von Plugins registrierte Hintergrundjobs.
Bei jedem Seitenaufruf kann WordPress prüfen, ob geplante Aufgaben fällig sind.
Wenn sehr viele oder besonders aufwendige Cron-Aufgaben anstehen, kann dies die Website belasten.
Entscheidend ist deshalb nicht nur, dass WP-Cron existiert, sondern welche Aufgaben darüber ausgeführt werden und wie lange diese benötigen.
WP-Cron durch einen echten Cronjob ersetzen #
Auf geeigneten Hosting-Umgebungen kann es sinnvoll sein, den WordPress-internen Cron-Aufruf nicht bei normalen Seitenaufrufen anzustoßen, sondern kontrolliert über einen serverseitigen Cronjob auszuführen.
Dafür kann WordPress beispielsweise mit:
DISABLE_WP_CRON
entsprechend konfiguriert werden.
Das sollte jedoch nur geschehen, wenn anschließend tatsächlich ein zuverlässiger externer Cronjob eingerichtet wird.
Achtung: WP-Cron einfach zu deaktivieren, ohne einen Ersatz einzurichten, kann geplante WordPress- und Plugin-Aufgaben verhindern.
PHP-Version beeinflusst WordPress-Performance #
WordPress wird serverseitig überwiegend mit PHP ausgeführt. Die verwendete PHP-Version beeinflusst deshalb Kompatibilität, Sicherheit und Performance.
Eine aktuelle, von WordPress und den eingesetzten Erweiterungen unterstützte PHP-Version ist grundsätzlich sinnvoll.
Du solltest eine PHP-Version aber nicht ausschließlich deshalb wechseln, weil eine höhere Versionsnummer vermeintlich automatisch jede Website schneller macht.
Vor einem Wechsel müssen Plugins, Theme und individueller Code kompatibel sein.
Wie du dabei vorgehst, erklären wir unter PHP-Version für WordPress ändern und Kompatibilität prüfen.
PHP Memory Limit und Performance unterscheiden #
Das PHP Memory Limit bestimmt, wie viel Arbeitsspeicher ein einzelner PHP-Prozess beziehungsweise eine PHP-Ausführung innerhalb der jeweiligen Konfiguration verwenden darf.
Erreicht WordPress dieses Limit, kann ein Fehler wie:
Allowed memory size ... exhausted
auftreten.
Ein höheres Memory Limit macht eine normal funktionierende WordPress-Seite jedoch nicht automatisch schneller.
Wenn ein Plugin ungewöhnlich viel Speicher verbraucht, kann eine Erhöhung des Limits außerdem lediglich das Symptom verschieben.
Die Unterschiede erklären wir ausführlich unter PHP Memory Limit in WordPress: Fehler erkennen und beheben.
PHP OPcache #
PHP-Code muss für die Ausführung verarbeitet werden. OPcache kann bereits kompilierten PHP-Bytecode im Arbeitsspeicher zwischenspeichern, sodass PHP-Dateien nicht bei jeder Anfrage vollständig neu kompiliert werden müssen.
Auf modernen PHP-Hosting-Umgebungen ist OPcache deshalb ein wichtiger Bestandteil der serverseitigen Performance.
Als WordPress-Benutzer musst du daran normalerweise nicht ständig Änderungen vornehmen. Bei einer technischen Performance-Analyse gehört die PHP-Laufzeitumgebung jedoch zum Gesamtbild.
Hosting-Ressourcen können zum Flaschenhals werden #
Auch eine technisch gut optimierte WordPress-Website benötigt Rechenleistung, Arbeitsspeicher, Datenbankleistung und I/O-Ressourcen.
Wenn eine Website dauerhaft mehr Ressourcen benötigt, als ihre Umgebung bereitstellen kann, können Anfragen langsamer verarbeitet werden.
Das betrifft beispielsweise stark frequentierte Websites, umfangreiche WooCommerce-Shops oder Websites mit ressourcenintensiven Plugins.
Bei CURIAWEB verwenden unsere WordPress-Hosting-Angebote eine für WordPress ausgelegte Hosting-Umgebung. Trotzdem sollte bei einem konkreten Performance-Problem immer zuerst geprüft werden, welche Ressource tatsächlich limitiert, statt pauschal mehr Serverleistung als Lösung anzunehmen.
CloudLinux-Ressourcen richtig interpretieren #
In einer CloudLinux-Hosting-Umgebung können Ressourcen eines Hosting-Accounts kontrolliert begrenzt werden. Dadurch kann ein einzelner Account nicht unbegrenzt Ressourcen des gesamten Servers beanspruchen.
Wenn eine WordPress-Website wiederholt an solche Limits stößt, ist das eine wichtige Diagnoseinformation.
Entscheidend ist jedoch, welches Limit erreicht wird und warum.
Ein plötzlich stark erhöhter Ressourcenverbrauch kann beispielsweise durch ein problematisches Plugin, Bots, Cronjobs oder ungewöhnlich viele dynamische Anfragen verursacht werden. Ein größeres Hosting-Paket würde in einem solchen Fall möglicherweise nur mehr Spielraum schaffen, ohne die Ursache zu beseitigen.
CPU-Auslastung #
PHP-Code, Datenbankoperationen und andere Prozesse benötigen CPU-Zeit.
Wenn eine Website dauerhaft rechenintensive Aufgaben ausführt, kann die CPU zum Engpass werden.
Besonders interessant ist dabei, ob die hohe Last permanent oder nur zu bestimmten Zeiten auftritt.
Wiederkehrende Lastspitzen können beispielsweise auf Cronjobs, Backups, Imports, Scans oder Bots hindeuten.
I/O und Festplattenzugriffe #
WordPress liest und schreibt Dateien und Daten. Auch Plugins können große Mengen an Dateioperationen verursachen.
Backups, Bildverarbeitung, Sicherheits-Scans, Imports und umfangreiche Logdateien sind Beispiele für Prozesse, die I/O-Ressourcen beanspruchen können.
Schneller NVMe-Speicher ist hilfreich, kann aber ineffiziente oder unnötig häufige Dateioperationen nicht vollständig kompensieren.
PHP-Prozesse und gleichzeitige Anfragen #
Bei dynamischen Seitenaufrufen muss PHP Anfragen verarbeiten. Erreichen sehr viele nicht gecachte Anfragen gleichzeitig die Website, können verfügbare Prozesse beziehungsweise Worker zum Engpass werden.
Das ist einer der Gründe, warum effizientes Page Caching bei öffentlich cachebaren Inhalten so wirkungsvoll sein kann: Nicht jeder Besucher benötigt dann eine vollständige neue WordPress-Ausführung.
Bots können WordPress belasten #
Nicht jeder Website-Aufruf stammt von einem echten Besucher.
Suchmaschinen, SEO-Tools, Monitoring-Dienste, KI-Crawler, Sicherheits-Scanner und unerwünschte Bots können ebenfalls Anfragen erzeugen.
Besonders aggressive Bots können dynamische URLs in hoher Frequenz aufrufen und dadurch PHP sowie Datenbank belasten.
Bei unerklärlichen Lastspitzen lohnt sich deshalb auch ein Blick auf Access Logs und die angeforderten URLs.
wp-login.php und automatisierte Login-Versuche #
Öffentlich erreichbare WordPress-Websites erhalten häufig automatisierte Anfragen auf:
wp-login.php
Eine große Zahl solcher Anfragen kann zusätzliche Ressourcen beanspruchen.
Geeignete Sicherheitsmechanismen können unerwünschte Login-Versuche begrenzen. Die Login-Datei einfach zu löschen oder WordPress-Core-Dateien zu verändern, ist dagegen keine Lösung.
XML-RPC als mögliche Quelle von Requests #
Je nach Konfiguration und verwendeten Funktionen kann:
xmlrpc.php
Anfragen erhalten.
Ob XML-RPC benötigt wird, hängt von der konkreten Website und eingesetzten Diensten ab.
Statt die Funktion pauschal aufgrund allgemeiner Performance-Empfehlungen zu deaktivieren, solltest du zunächst prüfen, ob dort tatsächlich relevante Last entsteht und ob abhängige Funktionen existieren.
Backups können temporär Ressourcen benötigen #
Ein vollständiges WordPress-Backup muss möglicherweise viele Dateien lesen, Archive erstellen und Datenbankinhalte exportieren.
Bei großen Websites kann das spürbare Ressourcenlast verursachen.
Wenn WordPress beispielsweise jeden Tag zu einer bestimmten Uhrzeit langsam wird, solltest du deshalb prüfen, ob zu diesem Zeitpunkt Backups oder andere geplante Wartungsaufgaben laufen.
Sicherheits-Scans benötigen ebenfalls Leistung #
Ein Security-Plugin, das tausende Dateien untersucht, benötigt zwangsläufig Ressourcen.
Das bedeutet nicht, dass Sicherheits-Scans grundsätzlich schlecht sind. Ihre Häufigkeit und Ausführung sollten jedoch zur Website und Hosting-Umgebung passen.
Wenn Performance-Probleme immer während eines Scans auftreten, ist der zeitliche Zusammenhang ein wichtiger Hinweis.
Logdateien können unbemerkt sehr groß werden #
Fehlerhafte Plugins oder dauerhaft aktiviertes Debugging können große Logdateien erzeugen.
Eine bekannte WordPress-Debugdatei ist beispielsweise:
wp-content/debug.log
Wenn ein Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann diese Datei schnell wachsen.
Debugging sollte deshalb zur Diagnose kontrolliert verwendet und anschließend wieder passend konfiguriert werden.
Mehr dazu erklären wir unter WordPress Debugging aktivieren und Fehlerprotokolle verwenden.
Eine langsame externe API kann WordPress blockieren #
Plugins kommunizieren teilweise während einer Anfrage mit externen Diensten.
Wenn WordPress auf die Antwort eines langsamen oder nicht erreichbaren externen Servers wartet, kann die eigene Website verzögert reagieren.
Das ist besonders tückisch, weil der eigene Server technisch einwandfrei funktionieren kann.
Wenn Performance-Probleme sporadisch auftreten, können externe HTTP-Anfragen deshalb ebenfalls untersucht werden.
DNS und Netzwerk nicht mit WordPress verwechseln #
Bevor der Browser WordPress überhaupt erreicht, muss die Domain aufgelöst und eine Verbindung zum Server hergestellt werden.
Probleme auf dieser Ebene sind keine WordPress-Performance-Probleme im engeren Sinn.
Eine vollständige Analyse betrachtet deshalb auch, ob die Verzögerung bereits vor der eigentlichen Serververarbeitung entsteht.
CDN: sinnvoll, aber nicht automatisch notwendig #
Ein Content Delivery Network kann statische Ressourcen über geografisch verteilte Systeme bereitstellen und je nach Konfiguration weitere Optimierungen übernehmen.
Das kann insbesondere bei einem international verteilten Publikum sinnvoll sein.
Ein CDN repariert jedoch keine langsame PHP-Funktion, keine ineffiziente Datenbankabfrage und kein fehlerhaftes Plugin.
Bei einer hauptsächlich regionalen Zielgruppe sollte deshalb geprüft werden, welches konkrete Problem durch ein CDN gelöst werden soll.
Viele HTTP-Requests sind nicht automatisch schlecht #
Ältere Performance-Anleitungen konzentrieren sich häufig stark darauf, die Anzahl einzelner Dateien möglichst drastisch zu reduzieren.
Die Zahl der Requests bleibt relevant, sollte aber nicht isoliert betrachtet werden.
Dateigröße, Priorisierung, Cachebarkeit, Übertragungsprotokoll und Verarbeitungsaufwand im Browser spielen ebenfalls eine Rolle.
Eine einzelne riesige JavaScript-Datei ist nicht automatisch besser als mehrere sinnvoll strukturierte kleinere Ressourcen.
Core Web Vitals richtig einordnen #
Bei der wahrgenommenen Nutzererfahrung sind nicht nur Sekunden bis zum vollständigen Laden relevant.
Moderne Performance-Messungen betrachten unter anderem, wann der wichtigste sichtbare Inhalt erscheint, wie schnell eine Seite auf Interaktionen reagiert und ob sich das Layout während des Ladens unerwartet verschiebt.
Deshalb kann eine Website trotz akzeptabler Gesamt-Ladezeit eine schlechte Nutzererfahrung bieten.
LCP – Largest Contentful Paint #
Der Largest Contentful Paint betrachtet vereinfacht, wann ein großes beziehungsweise wichtiges Inhaltselement im sichtbaren Bereich dargestellt wird.
Häufig handelt es sich dabei um ein großes Bild, eine Überschrift oder einen anderen prominenten Inhalt.
Ist beispielsweise das Hero-Bild sehr groß oder wird unnötig verzögert geladen, kann dies den LCP verschlechtern.
INP – Interaction to Next Paint #
Interaction to Next Paint betrachtet die Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen über den Besuch hinweg.
Aufwendiges JavaScript kann beispielsweise dazu führen, dass der Browser nach einem Klick oder einer anderen Interaktion nicht schnell genug reagieren kann.
Eine schnelle Serverantwort allein garantiert deshalb noch keine gute Interaktionsperformance.
CLS – Cumulative Layout Shift #
Cumulative Layout Shift bewertet unerwartete Layoutverschiebungen.
Wenn beispielsweise ein Bild zunächst ohne reservierten Platz geladen wird und anschließend den restlichen Inhalt nach unten verschiebt, kann das die visuelle Stabilität beeinträchtigen.
Auch nachträglich geladene Banner, Fonts oder andere Elemente können dazu beitragen.
Labordaten und echte Nutzerdaten unterscheiden #
Performance-Tools können Tests unter kontrollierten Bedingungen durchführen. Diese sogenannten Labordaten sind hervorragend für reproduzierbare Analysen geeignet.
Echte Besucher verwenden jedoch unterschiedliche Geräte, Browser und Netzwerkverbindungen.
Felddaten beziehungsweise reale Nutzerdaten können deshalb ein anderes Bild zeigen.
Beide Perspektiven sind nützlich und sollten nicht miteinander verwechselt werden.
Ein einzelner Speed-Test reicht nicht #
Performance-Messungen können schwanken.
Cache-Zustand, Netzwerk, externe Dienste und Hintergrundprozesse beeinflussen das Ergebnis.
Deshalb solltest du nicht aufgrund eines einzigen Tests umfangreiche Änderungen an einer Website vornehmen.
Mehrere Messungen unter vergleichbaren Bedingungen liefern eine bessere Grundlage.
Praxis-Tipp: Dokumentiere vor größeren Optimierungen einen Ausgangswert. Ändere anschließend möglichst nur einen relevanten Bereich und miss erneut. So kannst du feststellen, ob eine Maßnahme tatsächlich geholfen hat.
Startseite allein ist kein ausreichender Test #
Eine WordPress-Website besteht häufig aus sehr unterschiedlichen Seitentypen.
Für eine aussagekräftige Analyse solltest du beispielsweise auch einen normalen Beitrag, eine wichtige Landingpage und bei WooCommerce eine Produktseite betrachten.
Wenn ausschließlich eine einzelne Seite langsam ist, liegt die Ursache möglicherweise im Aufbau genau dieser Seite und nicht in der gesamten WordPress-Installation.
Mobile Performance besonders beachten #
Eine Website, die auf einem leistungsstarken Desktop mit schneller Internetverbindung problemlos wirkt, kann auf einem durchschnittlichen Smartphone deutlich langsamer reagieren.
Große JavaScript-Mengen und aufwendige visuelle Effekte fallen auf schwächeren Geräten stärker ins Gewicht.
Performance sollte deshalb nicht ausschließlich vom eigenen Bürocomputer aus beurteilt werden.
Warum ein Performance-Score nicht das alleinige Ziel ist #
Tools verdichten komplexe Messwerte häufig zu einer Punktzahl.
Solche Scores sind hilfreich, sollten aber nicht zum Selbstzweck werden.
Eine Website sollte schnell, stabil und für reale Benutzer gut bedienbar sein. Eine technische Änderung, die lediglich einen Score verbessert, dafür aber eine wichtige Funktion beschädigt, ist keine erfolgreiche Optimierung.
WordPress regelmäßig aufräumen – aber gezielt #
Im Laufe der Zeit sammeln sich auf vielen Installationen nicht mehr verwendete Plugins, Themes, Medien, Testfunktionen und alte Konfigurationen an.
Nicht alles davon macht die Website unmittelbar langsam. Unnötige Komponenten erhöhen aber die Komplexität und können Wartung sowie Fehlersuche erschweren.
Nicht mehr benötigte Erweiterungen sollten deshalb nach vorheriger Prüfung sauber entfernt werden.
Updates können Performance-Probleme lösen #
Aktuelle WordPress-, Plugin- und Theme-Versionen enthalten nicht nur neue Funktionen und Sicherheitskorrekturen. Entwickler verbessern teilweise auch Performance und Kompatibilität.
Eine dauerhaft veraltete Installation ist deshalb keine sinnvolle Performance-Strategie.
Updates sollten bei wichtigen Websites kontrolliert und mit einer funktionierenden Backup- beziehungsweise Wiederherstellungsstrategie durchgeführt werden.
Wann ein Plugin ersetzt werden sollte #
Wenn eine Erweiterung dauerhaft unverhältnismäßig viele Ressourcen benötigt und keine Konfigurations- oder Update-Lösung existiert, kann ein Ersatz sinnvoll sein.
Entscheidend ist dabei nicht, welches Plugin in irgendeiner Bestenliste als „schnellstes“ bezeichnet wird, sondern welche Funktionen deine Website tatsächlich benötigt und wie die Alternative in deiner konkreten Umgebung arbeitet.
Wann mehr Hosting-Ressourcen sinnvoll sind #
Optimierung bedeutet nicht, dass jede Website mit minimalen Ressourcen betrieben werden muss.
Wenn eine technisch sauber aufgebaute Website aufgrund echten Traffics oder legitimer dynamischer Prozesse dauerhaft hohe Ressourcen benötigt, kann mehr Rechenleistung die richtige Lösung sein.
Vorher sollte jedoch ausgeschlossen werden, dass die Last hauptsächlich durch einen Fehler, Bots, einen außer Kontrolle geratenen Cronjob oder eine ineffiziente Erweiterung entsteht.
Performance-Probleme systematisch eingrenzen #
Beginne mit dem konkreten Symptom. Ist die gesamte Website langsam oder nur eine Seite? Betrifft es das Frontend, wp-admin oder beides? Ist bereits die Serverantwort langsam oder entstehen die Verzögerungen erst beim Laden und Verarbeiten der Frontend-Ressourcen?
Prüfe danach, ob das Problem dauerhaft oder nur zu bestimmten Zeiten auftritt. Ein wiederkehrendes Zeitmuster kann auf Backups, Cronjobs, Scans oder andere geplante Prozesse hindeuten.
Betrachte anschließend die letzten Änderungen. Wenn die Website direkt nach Installation eines Plugins, einem Update oder einer PHP-Änderung langsam geworden ist, besitzt du bereits einen wichtigen Anhaltspunkt.
Erst danach solltest du gezielt Plugins, Datenbankabfragen, externe Requests, Cache, PHP und Hosting-Ressourcen untersuchen.
Was du bei einer langsamen WordPress-Website besser nicht tun solltest #
Installiere nicht fünf Performance-Plugins gleichzeitig. Mehrere Systeme, die gleichzeitig Cache, CSS, JavaScript und Datenbank optimieren wollen, können neue Konflikte erzeugen und die Diagnose erschweren.
Lösche nicht wahllos Datenbanktabellen oder Optionen, nur weil ein Optimierungstool sie als groß markiert. Größe allein beweist kein Performance-Problem.
Wechsle außerdem nicht gleichzeitig Theme, PHP-Version, Cache-System und mehrere Plugins. Wenn die Website danach schneller ist, weißt du nicht, welche Maßnahme tatsächlich geholfen hat.
Und erhöhe Serverressourcen nicht automatisch, bevor du geprüft hast, warum die vorhandenen Ressourcen ausgeschöpft werden.
Grundregel: Erst messen, dann Ursache eingrenzen, anschließend gezielt optimieren und danach erneut messen. Performance-Optimierung ohne Vergleichswerte ist häufig nur Vermutung.
Welche Informationen helfen dem CURIAWEB-Support? #
Wenn eine WordPress-Website bei CURIAWEB ungewöhnlich langsam ist, hilft eine möglichst genaue Beschreibung des Problems wesentlich mehr als die allgemeine Aussage „WordPress ist langsam“.
Teile beispielsweise mit, welche URL betroffen ist, ob das Problem auch im Adminbereich auftritt und seit wann du die Veränderung bemerkst. Wenn die Performance nur zu bestimmten Zeiten schlecht ist, ist auch der ungefähre Zeitpunkt wichtig.
Hilfreich ist außerdem zu wissen, ob unmittelbar zuvor Plugins, Themes, WordPress, PHP oder andere Einstellungen verändert wurden.
Bei auffälligen Ressourcenwerten oder Fehlermeldungen können wir anschließend gezielt prüfen, ob beispielsweise PHP, Datenbank, Prozesse oder Account-Ressourcen beteiligt sind.
Sende Passwörter nicht unaufgefordert mit.
Zusammenfassung #
Eine langsame WordPress-Website hat selten nur eine mögliche Ursache. Serverantwort, PHP, Datenbank, Plugins, Theme, Cache, Bilder, JavaScript, CSS, externe Dienste und Hosting-Ressourcen beeinflussen unterschiedliche Teile der Ladezeit.
Deshalb sollte die Optimierung nicht mit dem Installieren eines beliebigen Performance-Plugins beginnen, sondern mit einer Messung und Eingrenzung des Problems.
Ist bereits die dynamische Serverantwort langsam, solltest du insbesondere PHP-Verarbeitung, Datenbankabfragen, Plugins, externe API-Aufrufe, Cronjobs und Hosting-Ressourcen untersuchen. Antwortet der Server schnell, während die Seite im Browser langsam aufgebaut wird, rücken Bilder, JavaScript, CSS, Fonts und Drittanbieter-Ressourcen stärker in den Fokus.
Page Cache und persistenter Object Cache können WordPress erheblich entlasten, lösen aber unterschiedliche Aufgaben und ersetzen keine saubere Anwendung. Auch mehr Serverleistung ist nur dann die richtige Lösung, wenn tatsächlich Ressourcen fehlen und nicht lediglich ein fehlerhafter Prozess unnötig Last erzeugt.
Eine nachhaltige WordPress-Optimierung folgt deshalb immer demselben Prinzip: messen, Ursache bestimmen, gezielt verändern und erneut messen.
