WordPress-Website lädt langsam: Plugin, Theme oder Server?

Lädt eine WordPress-Website langsam, liegt die Ursache meist an einer dieser Stellen: der Zeit, die der Server zum Erzeugen der Seite braucht, den Dateien, die Theme und Plugins jeder Seite hinzufügen, oder Bildern, die größer sind als nötig. Welche davon auf Ihrer Website die Zeit verlängert, findet man heraus, indem man jeweils nur eine Sache ändert und dieselbe Messung wiederholt.

WordPress selbst ist keine langsame Software; die Langsamkeit entsteht aus der Summe all dessen, was darum herum aufgebaut wird. Die Performance-Dokumentation von WordPress zählt die Faktoren, die die Geschwindigkeit beeinflussen, einzeln auf: Hosting-Umgebung und Hardware, die Versionen von PHP und Datenbanksoftware, die Wahl von Theme und Plugins, Größe und Anzahl der Bilder, die Effizienz der Datenbank, die Last auf dem Server und seine Entfernung zum Besucher. Zwei Websites mit demselben Theme können durch unterschiedliche Kombinationen dieser Faktoren völlig verschieden schnell laden.

Deshalb enthält dieser Artikel keine Zahlen der Art „dieses Plugin fügt einer Seite so viel Zeit hinzu“. Dasselbe Plugin kostet auf zwei Websites unterschiedlich viel, und eine pauschale Zahl führt Sie an die falsche Stelle. Stattdessen beschreiben wir, wie Sie selbst herausfinden, wo auf Ihrer Website die Ursache liegt. Möchten Sie Messung und Behebung uns überlassen, beschreibt die Seite Website-Geschwindigkeitsoptimierung den Ablauf; die Liste allgemeiner, nicht WordPress-spezifischer Ursachen steht im Artikel Warum lädt Ihre Website langsam.

Liegt das Problem am Server oder im Browser?

Das ist die erste Unterscheidung, und sie trennt zwei verschiedene Welten. WordPress erzeugt die Seite bei jedem Besuch mit PHP aus der Datenbank; das geschieht auf dem Server, und die Dauer wird als Time to First Byte (TTFB) gemessen. Nachdem die Seite erzeugt und gesendet ist, lädt der Browser die Stil-, Skript-, Bild- und Schriftdateien, die Theme und Plugins einbinden; das ist die Browserseite. Ein Caching-Plugin beschleunigt die erste Seite, die Last auf der zweiten verringert es nicht.

So erkennen Sie es: Öffnen Sie in Chrome mit F12 die Entwicklertools, haken Sie im Netzwerk-Tab (Network) das Kästchen „Disable cache“ (Cache deaktivieren) an und laden Sie die Seite neu. Die erste Zeile der Liste ist die Seite selbst; klicken Sie darauf und sehen Sie im Bereich Timing (Zeitablauf) die Zeit bei „Waiting for server response“ (Warten auf Serverantwort) an. web.dev nennt für die meisten Websites 0,8 Sekunden oder weniger als Ziel. Ist diese Zeit über mehrere Neuladungen hinweg durchgehend lang, sieht man zuerst auf den Server; ist sie kurz und die Seite erscheint trotzdem spät, liegt das Problem in der Last, die zum Browser geht. Die technische Seite des Themas: TTFB und Serverantwort.

Ein Hinweis: Eine Messung, während Sie in WordPress als Administrator angemeldet sind, zeigt womöglich nicht, was ein Besucher sieht. Viele Caching-Setups erzeugen die Seite für angemeldete Nutzer jedes Mal neu und laden zusätzliche Dateien wie die Admin-Leiste. Messen Sie in einem privaten Fenster und abgemeldet.

Worauf achtet man, wenn der Server langsam ist?

Auf der Serverseite werden drei Fragen der Reihe nach gestellt. Erstens das Hosting: Auf einem überfüllten Shared Server reichen der Prozessor und der Arbeitsspeicher, die Ihrer Website zugeteilt sind, zu Stoßzeiten womöglich nicht aus. Zweitens die Softwareversionen: Die WordPress-Dokumentation zählt aktuelle Versionen von PHP, Datenbank- und Webserver-Software zu den Performance-Faktoren. Drittens der Seiten-Cache: eine fertige Kopie der Seite zu senden, statt dieselbe Seite bei jedem Besuch neu aus der Datenbank zu erzeugen.

Die WordPress-Dokumentation selbst nennt Caching den Schritt, der mit dem geringsten Aufwand den größten Gewinn bringt, und für die Serverseite stimmt das. Ist die Seite aber nach der Installation eines Caching-Plugins noch immer langsam, liegt das Problem sehr wahrscheinlich nicht mehr am Server; gehen Sie zum nächsten Abschnitt.

Welches Plugin bremst, und wie findet man es heraus?

Auch die WordPress-Dokumentation empfiehlt diesen Weg: Plugins gezielt deaktivieren und die Performance messen. Verlässlich ist die Methode nur, wenn einige Regeln eingehalten werden:

Arbeiten Sie nicht auf der Live-Website, sondern auf einer Kopie (Staging-Umgebung); das Deaktivieren von Plugins kann Formulare und Bezahlabläufe stören.
Nehmen Sie zuerst eine Basismessung: dieselbe Seite, dasselbe Werkzeug, dasselbe Geräteprofil; mindestens fünf Durchläufe und der Medianwert. Ein einzelner Durchlauf kann den Unterschied zwischen zwei Plugins nicht vom Rauschen trennen.
Deaktivieren Sie die Plugins einzeln und wiederholen Sie nach jeder Deaktivierung dieselbe Messung.
Notieren Sie in jeder Zeile das deaktivierte Plugin, die Time to First Byte, die insgesamt übertragene Datenmenge und die Zahl der Anfragen.
Halten Sie die mit großem Unterschied fest und aktivieren Sie dann alle wieder. Die Entscheidung trifft die Tabelle, nicht das Bauchgefühl.

Auf der Browserseite gibt es eine schnellere Abkürzung. In WordPress kommen Plugin-Dateien aus dem Ordner „/wp-content/plugins/plugin-name/“, Theme-Dateien aus dem Ordner „/wp-content/themes/theme-name/“. Wenn Sie in das Filterfeld des Netzwerk-Tabs „plugins“ eingeben, bleiben nur die von Plugins geladenen Dateien übrig, und an der Adresse jeder Zeile lässt sich ablesen, zu welchem Plugin sie gehört. So sehen Sie auf einen Blick, ob das Skript des Kontaktformular-Plugins auch auf Seiten ohne Formular lädt oder ob ein Galerie-Plugin auf der ganzen Website ein Stylesheet einbindet. Auch der Bereich Coverage (Abdeckung) in den Entwicklertools zeigt, wie viel des geladenen Codes auf dieser Seite nie verwendet wird.

Zählt die Zahl der Plugins oder das, was sie tun?

Die WordPress-Dokumentation schreibt, dass sowohl die Zahl der Plugins als auch deren eigene Performance großen Einfluss auf die Geschwindigkeit haben, und nennt das Entfernen unnötiger Plugins eine wichtige Verbesserung. In der Praxis ist die eigentliche Frage eher das Verhalten als die Zahl: Ein einziges Plugin, das auf dem Server bei jeder Anfrage schwere Arbeit leistet, kann teurer sein als mehrere Plugins, die nur im Admin-Bereich laufen. Stellen Sie zu jedem Plugin drei Fragen: Fügt es der Seite, die der Besucher sieht, Dateien hinzu, tut es das auf jeder Seite, und kann das Theme oder der Browser selbst schon, was es tut?

Ist das Theme zu schwer?

Multipurpose-Themes und Page Builder sind so gebaut, dass sie zu jeder Art von Website passen; sie können auch Stile und Skripte für Slider, Animationen und Komponenten senden, die Sie gar nicht nutzen. Den Anteil des Themes isoliert man wieder mit einer Messung mit nur einer Variablen: Wechseln Sie auf einer Kopie der Website bei unveränderten Plugins zu einem der Standard-Themes von WordPress und messen Sie dieselbe Seite unter denselben Bedingungen. Der Unterschied ist ein grober Anhaltspunkt dafür, was das Theme kostet. Der Filter „themes“ im Netzwerk-Tab und der Anteil ungenutzter Stile im Coverage-Bereich beantworten dieselbe Frage aus einem zweiten Blickwinkel.

Welchen Anteil haben Bilder und eingebettete Inhalte?

In WordPress werden Bilder oft in der Größe hochgeladen, in der sie aus der Kamera oder dem Grafikprogramm kamen. Wählen Sie im Netzwerk-Tab den Filter Img (Bild) und sortieren Sie nach der Spalte Size (Größe); die schwerste Datei der Seite ist meist ein Bild und oft das LCP-Element, das als Hauptinhalt der Seite gilt. Inhalte von anderen Servern, etwa eingebettete Videos und Karten, sind ein eigener Posten; wenn Sie die Spalte Domain einblenden, sehen Sie jede Zeile, die von außerhalb Ihrer eigenen Domain kommt.

Reicht es, ein Plugin zur Beschleunigung zu installieren?

Beschleunigungs-Plugins fassen Dateien zusammen, verzögern Skripte und verkleinern Bilder. Auf manchen Websites bringen sie echten Gewinn; aber sie beseitigen keine Last, oft ändern sie nur deren Reihenfolge. Ein verzögertes Skript kann das erste Erscheinen der Seite beschleunigen und zugleich den ersten Klick verzögern; zusammengefasste Dateien können Layoutverschiebungen oder ein defektes Menü verursachen. Die Regel ist einfach: Wiederholen Sie nach jeder Einstellungsänderung dieselbe Messung und behalten Sie nur die Einstellung, bei der die Messung eine Verbesserung zeigt.

Wie haben wir diese Methode auf unserer eigenen Website angewendet?

Diese Website ist nicht mit WordPress, sondern mit unserem eigenen Generator gebaut, aber die Methode, Langsamkeit einzugrenzen, ist dieselbe. Nach einer Arbeitsrunde stieg die Total Blocking Time der Startseite plötzlich an. Erster Verdacht war das in dieser Runde hinzugefügte JavaScript; die Messung zeigte woandershin. Wir testeten die Stilregeln familienweise, nahmen jedes Mal eine einzige Familie heraus und lasen bei jedem Versuch den Median der Blockierzeit ab. Ohne alle :has()-Selektoren sank die Zeit von 369 Millisekunden auf 104 Millisekunden; ohne nur die an die Wurzel der Seite gebundenen auf 115 Millisekunden. Die Last konzentrierte sich auf eine einzige Familie, und diese Regeln färbten auf der Startseite nichts ein. Nach der Korrektur sank die Zeit auf 97–108 Millisekunden. Einzelheiten in Wie ein :has()-Selektor die Blockierzeit beeinflusste.

Am ähnlichsten zu Plugins war allerdings unsere Erfahrung mit Bibliotheken. Bevor wir die beiden Bibliotheken entfernten, die das Scrollen steuerten, fragten wir uns: Kann der Browser diese Aufgabe selbst erledigen? Er konnte es; ohne die Bibliotheken sank das komprimierte JavaScript von 51,1 Kilobyte auf 33,5 Kilobyte. In WordPress entspricht dem die Frage, ob das, was ein Plugin tut, bereits im Theme oder im Browser vorhanden ist, bevor man es entfernt.

Eine Variable ändern, dieselbe Messung wiederholen; die Tabelle entscheiden lassen.

Beschleunigen oder neu aufbauen?

Auch diese Frage beantwortet die Messtabelle. Konzentriert sich die Last auf wenige Plugins und einige große Bilder, genügt ein Eingriff in die bestehende Website, und er ist meist günstiger. Fügt das Theme oder der Page Builder jeder Seite eine schwere Grundlast hinzu, die ohne Theme-Wechsel nicht verschwindet, kann ein Neuaufbau langfristig günstiger sein. Wie oft und von wem die Inhalte geändert werden, gehört ebenfalls zu dieser Entscheidung; den Unterschied der beiden Ansätze beschreiben wir in Statische Website oder Content-Management-System.

Welcher Weg es auch wird: Gewonnene Geschwindigkeit, die nicht geschützt wird, geht wieder verloren; jedes neue Plugin, jedes neue Kampagnenbild erhöht die Last ein wenig. Grenzen festzuschreiben, die die Website nicht überschreiten darf, und nach jedem Update zu messen, gehört deshalb zur Arbeit; wie man sie aufsetzt, steht im Leitfaden zum Performance-Budget. Und wenn Sie sich fragen, warum die Messung selbst jedes Mal ein anderes Ergebnis liefert: Wie misst man die Website-Geschwindigkeit.

Wenn Sie die Geschwindigkeit Ihrer eigenen Website verbessern möchten: Unser individuelles Webdesign liefert Performance als messbares Budget aus — Ziel ist ein LCP unter 0,8 Sekunden.

VERFASST VON Murat Tunalı Gründer. Zwanzig Jahre Enterprise-IT-Infrastruktur + Webentwicklung.