WordPress schneller machen: Was wirklich etwas bringt

Eine langsame WordPress-Seite lässt sich selten mit einem einzelnen Häkchen reparieren.

Trotzdem beginnt Performance-Optimierung häufig genau so: Cache-Plugin installieren, ein paar Optionen aktivieren und hoffen, dass anschließend alles schnell ist.

Manchmal funktioniert das sogar.

Das Problem: Wir wissen danach nicht unbedingt, warum die Seite schneller geworden ist oder ob sie überhaupt messbar schneller geworden ist.

Deshalb gilt bei der WordPress-Optimierung eine einfache Regel:

Erst messen. Dann verändern. Danach erneut messen.

In dieser Anleitung schauen wir uns nicht nur typische Performance-Maßnahmen an. Wir zeigen auch, mit welchen Werkzeugen sich überprüfen lässt, ob sie tatsächlich etwas gebracht haben.

Was bedeutet eigentlich „WordPress ist langsam“?

#

Eine Website kann auf ganz unterschiedliche Arten langsam sein.

Vielleicht braucht der Server lange, bevor überhaupt eine Antwort kommt.

Vielleicht erscheint die Seite schnell, aber ein großes Titelbild benötigt mehrere Sekunden.

Vielleicht ist alles sichtbar, aber die Seite reagiert zunächst schlecht auf Eingaben.

Oder ein eingebettetes Video, Analytics, Werbung und andere externe Dienste erzeugen im Hintergrund zahlreiche zusätzliche Requests.

Deshalb reicht eine Aussage wie:

Meine Seite braucht vier Sekunden.

für eine vernünftige Diagnose nicht aus.

Wir müssen herausfinden, wo diese Zeit entsteht.

Vier Werkzeuge, die uns dabei helfen

#

Für die meisten WordPress-Seiten brauchen wir zunächst keine kostenpflichtige Performance-Suite.

Vier Werkzeuge bringen uns bereits ziemlich weit:

1. Google PageSpeed Insights
2. Lighthouse
3. die Netzwerkanalyse des Browsers
4. WebPageTest

Für Probleme innerhalb von WordPress selbst können wir später zusätzlich Query Monitor einsetzen.

Google PageSpeed Insights

#

PageSpeed Insights ist wahrscheinlich das bekannteste Werkzeug zur Untersuchung der Performance einer Website.

Man gibt eine öffentliche URL ein und erhält anschließend eine Analyse für Mobilgeräte und Desktop.

Besonders interessant sind dabei die sogenannten Core Web Vitals.

Largest Contentful Paint

#

Der Largest Contentful Paint, kurz LCP, beschreibt vereinfacht, wann ein wesentliches großes Inhaltselement im sichtbaren Bereich dargestellt wurde.

Das kann beispielsweise ein großes Titelbild sein.

Wenn dieses Bild riesig ist oder erst sehr spät geladen wird, kann sich das unmittelbar im LCP bemerkbar machen.

Interaction to Next Paint

#

Interaction to Next Paint, kurz INP, betrachtet die Reaktionsfähigkeit einer Website bei Benutzerinteraktionen.

Eine Website kann optisch bereits fertig aussehen und trotzdem träge auf eine Eingabe reagieren.

Aufwendiges JavaScript kann dabei eine Rolle spielen.

Cumulative Layout Shift

#

Der Cumulative Layout Shift, kurz CLS, betrachtet unerwartete Layoutverschiebungen.

Ein klassisches Beispiel:

Du möchtest gerade auf einen Link klicken. In diesem Moment erscheint darüber ein Bild oder eine Werbung und der gesamte Inhalt springt nach unten.

Das ist nicht nur nervig, sondern messbar.

Labordaten und echte Nutzerdaten sind nicht dasselbe

#

Bei PageSpeed Insights sollte man einen wichtigen Unterschied kennen.

Das Werkzeug kann sowohl Labordaten als auch Daten aus realen Nutzungssituationen anzeigen.

Labordaten entstehen unter kontrollierten Testbedingungen.

Felddaten basieren dagegen auf realen Nutzungserfahrungen, sofern für die untersuchte Seite beziehungsweise Herkunft genügend Daten vorhanden sind.

Deshalb können die Ergebnisse voneinander abweichen.

Das ist kein Fehler.

Ein Labortest beantwortet eher:

Wie verhält sich diese Seite unter diesen Testbedingungen?

Felddaten beantworten eher:

Wie erleben echte Chrome-Nutzer diese Website?

Bei einer neuen oder wenig besuchten Website stehen möglicherweise noch keine ausreichenden Felddaten zur Verfügung.

Lighthouse direkt im Browser

#

Lighthouse lässt sich auch direkt über die Chrome beziehungsweise Chromium Developer Tools ausführen.

Das ist besonders praktisch während der Entwicklung.

Wir öffnen die Entwicklerwerkzeuge und wählen den Bereich Lighthouse.

Anschließend können wir eine Analyse starten.

Das Ergebnis enthält unter anderem eine Performance-Bewertung und konkrete Hinweise auf mögliche Probleme.

Wichtig ist dabei:

Der Score ist hilfreich, aber er ist nicht das eigentliche Ziel.

Eine Website mit einem Score von 100 ist nicht automatisch eine gute Website.

Und eine vernünftige Website wird nicht plötzlich schlecht, weil eine Messung 91 statt 97 Punkte ergibt.

Wir verwenden Lighthouse vor allem als Diagnosewerkzeug.

Nicht nur auf die große Zahl schauen

#

Die Versuchung ist groß:

Performance: 74

Dann optimieren wir irgendetwas:

Performance: 93

Erfolg!

Vielleicht.

Interessanter ist, welche Messwerte sich verändert haben.

Hat sich LCP verbessert?

Ist weniger JavaScript vorhanden?

Wurde die übertragene Datenmenge kleiner?

Antwortet der Server schneller?

Sind weniger blockierende Ressourcen vorhanden?

Ein einzelner Score fasst sehr unterschiedliche Dinge zusammen.

Für die eigentliche Optimierung sollten wir deshalb tiefer schauen.

Der Network-Tab zeigt, was wirklich geladen wird

#

Eines meiner wichtigsten Werkzeuge für WordPress-Performance ist wesentlich unspektakulärer:

die Netzwerkanalyse des Browsers.

In Firefox öffnen wir die Entwicklerwerkzeuge beispielsweise mit:

F12

und wechseln zu Netzwerkanalyse.

Danach:

1. Liste leeren.
2. Seite neu laden.
3. Requests ansehen.
4. Nach Größe sortieren.
5. Domains und Dateitypen untersuchen.

Jetzt sehen wir beispielsweise:

HTML
CSS
JavaScript
Bilder
Fonts
Analytics
YouTube
Google Maps

und wie groß die einzelnen Ressourcen sind.

Nach Größe sortieren

#

Das ist einer der einfachsten Performance-Checks überhaupt.

Sortiere die Requests nach übertragener Größe.

Wenn ganz oben ein Bild mit mehreren Megabyte auftaucht, haben wir einen ziemlich offensichtlichen Kandidaten gefunden.

Dann optimieren wir dieses Bild und messen erneut.

Aus beispielsweise:

hero.jpg
3,8 MB

könnte nach Größenanpassung und geeigneter Kompression etwas wesentlich Kleineres werden.

Die konkrete Einsparung hängt vom Bild und den gewählten Einstellungen ab.

Und genau deshalb messen wir sie statt irgendeinen pauschalen Prozentwert zu versprechen.

Der Waterfall zeigt die zeitliche Abfolge

#

Die Netzwerkanalyse zeigt nicht nur, was geladen wurde.

Sie zeigt auch, wann etwas geladen wurde.

Das sogenannte Waterfall-Diagramm macht sichtbar, welche Requests parallel stattfinden und welche Ressourcen auf andere warten.

Vereinfacht:

HTML        █████
CSS             ███████
Font               █████
Hero Image             ███████████
Analytics          ███
YouTube                █████████████

Damit können wir Zusammenhänge erkennen, die in einer einfachen Liste von Dateigrößen nicht sichtbar sind.

WebPageTest für einen genaueren Blick

#

Für detailliertere Untersuchungen ist WebPageTest sehr interessant.

Dort lässt sich eine Website unter definierten Bedingungen testen und anschließend detailliert untersuchen.

Besonders hilfreich ist wiederum der Waterfall.

Wir sehen dort sehr genau, wann welche Ressource angefordert wurde und wie lange einzelne Schritte gedauert haben.

Für einen normalen WordPress-Nutzer ist das zunächst etwas überwältigend.

Man muss aber nicht jede einzelne Zeile verstehen.

Schon drei Fragen helfen:

• Wann kommt das HTML?
• Welche großen Ressourcen folgen?
• Welche externen Domains tauchen auf?

Damit lassen sich viele Probleme bereits eingrenzen.

Immer nur eine Sache verändern

#

Für unsere Tests verwenden wir ein einfaches Verfahren:

Ausgangszustand messen
          │
          ▼
eine Änderung durchführen
          │
          ▼
erneut messen
          │
          ▼
Ergebnisse vergleichen

Der wichtige Teil ist:

eine Änderung.

Wenn wir gleichzeitig ein Cache-Plugin installieren, Bilder optimieren, das Theme wechseln und fünf Plugins deaktivieren, ist die Website anschließend vielleicht schneller.

Wir wissen aber nicht, welche Maßnahme dafür verantwortlich war.

Mehrfach messen

#

Performance-Messungen schwanken.

Netzwerk, Serverlast, Caches und die Testumgebung können dazu führen, dass zwei unmittelbar aufeinanderfolgende Messungen unterschiedliche Ergebnisse liefern.

Deshalb sollte man wichtige Vergleiche mehrfach durchführen.

Wenn eine Änderung einmal 300 Millisekunden schneller erscheint, beweist das wenig.

Wenn mehrere vergleichbare Tests konsistent eine deutliche Verbesserung zeigen, wird das Ergebnis interessanter.

Jetzt können wir sinnvoll optimieren

#

Nachdem wir wissen, wie wir messen, schauen wir uns die typischen Ursachen an.

1. Hosting und Serverantwort

#

WordPress erzeugt viele Seiten dynamisch mit PHP und greift dabei auf eine Datenbank zu.

Bevor der Browser CSS, Bilder und JavaScript verarbeiten kann, muss der Server zunächst das HTML liefern.

Ist bereits diese erste Antwort langsam, lohnt sich ein Blick auf Server und WordPress-Backend.

Ein schnelleres Bildformat wird eine sehr langsame PHP-Anwendung nicht reparieren.

Deshalb ist es wichtig, Frontend- und Backend-Probleme auseinanderzuhalten.

2. Caching

#

Caching gehört tatsächlich zu den wirkungsvollsten WordPress-Optimierungen.

Ohne Page Cache läuft vereinfacht:

Request
   │
   ▼
WordPress / PHP
   │
   ▼
Datenbank
   │
   ▼
HTML erzeugen
   │
   ▼
Browser

Mit einem funktionierenden Page Cache kann der Ablauf eher so aussehen:

Request
   │
   ▼
Cache
   │
   ▼
fertiges HTML
   │
   ▼
Browser

Gerade bei öffentlichen Artikeln kann das erheblich weniger Arbeit pro Seitenaufruf bedeuten.

Auch hier gilt: nicht einfach glauben, dass der Cache funktioniert.

Wir messen die Seite vorher und nachher.

3. Bilder

#

Bei vielen Websites sind Bilder der einfachste große Hebel.

Ein Foto direkt aus einer modernen Kamera oder einem Smartphone kann mehrere Megabyte groß und mehrere tausend Pixel breit sein.

Wird es auf der Website später nur 900 Pixel breit dargestellt, übertragen wir möglicherweise sehr viele Daten, die der Besucher niemals benötigt.

Wir achten deshalb auf:

• sinnvolle Abmessungen,
• geeignete Kompression,
• passende Bildformate,
• responsive Bilder.

WebP und AVIF können je nach Ausgangsmaterial interessante Optionen sein.

4. Lazy Loading

#

Nicht jedes Bild eines langen Artikels muss sofort geladen werden.

Bilder außerhalb des sichtbaren Bereichs können häufig später geladen werden.

WordPress unterstützt Lazy Loading für geeignete Bilder bereits.

Das bedeutet aber nicht:

Lazy Loading für alles ist immer schneller.

Ein wichtiges großes Bild direkt im sichtbaren Bereich sollte möglicherweise gerade nicht verzögert angefordert werden.

Wir prüfen deshalb anschließend wieder LCP und Waterfall.

5. Plugins

#

Die Anzahl der Plugins allein sagt erstaunlich wenig über Performance aus.

Zehn kleine Plugins können weniger Auswirkungen haben als eine einzige Erweiterung, die auf jeder Seite große JavaScript-Dateien lädt oder aufwendige Datenbankabfragen ausführt.

Die bessere Frage lautet deshalb nicht:

Wie viele Plugins habe ich?

Sondern:

Was machen diese Plugins?

Für einen einfachen Test können wir ein verdächtiges Plugin deaktivieren, erneut messen und die Ergebnisse vergleichen.

Query Monitor: Wenn das Problem in WordPress steckt

#

Wenn wir tiefer in WordPress selbst schauen möchten, ist das Plugin Query Monitor interessant.

Es richtet sich eher an technisch interessierte Anwender und Entwickler.

Damit lassen sich unter anderem Datenbankabfragen und verschiedene Aspekte der WordPress-Ausführung untersuchen.

Das ist hilfreich, wenn der Browser zeigt:

Der Server braucht lange für die HTML-Antwort.

Dann können wir innerhalb von WordPress weiterforschen.

Für einen normalen kleinen Blog würde ich Query Monitor nicht permanent als Performance-Werkzeug betrachten.

Für die Fehlersuche kann es aber ausgesprochen hilfreich sein.

6. Das Theme

#

Themes können große Mengen CSS, JavaScript, Fonts, Slider und weitere Komponenten mitbringen.

Ein Theme ist deshalb nicht nur eine Designentscheidung.

Es ist auch Teil der technischen Architektur der Website.

Dabei wollen wir allerdings fair bleiben.

Ein Theme mit mehr Funktionen darf mehr Ressourcen benötigen.

Entscheidend ist, ob wir diese Funktionen tatsächlich brauchen.

7. Externe Dienste

#

Google Analytics, YouTube, Google Maps, Social-Media-Embeds und externe Fonts können zusätzliche Requests verursachen.

Auf unserer Testseite können wir das sehr schön beobachten.

Wir haben dort unter anderem Analytics, YouTube und Maps eingebunden.

Die Netzwerkanalyse zeigt unmittelbar, dass der Browser nun mit weiteren Servern kommuniziert.

Das ist nicht automatisch schlecht.

Aber jeder externe Dienst sollte einen Zweck erfüllen.

Und externe Dienste sind nicht nur für Performance interessant. Sie können auch Auswirkungen auf Datenschutz und Consent haben.

8. Fonts

#

Webfonts werden häufig unterschätzt.

Eine Website könnte beispielsweise laden:

Regular
Medium
SemiBold
Bold
Italic
Bold Italic

und vielleicht noch eine zweite Schriftfamilie dazu.

Im Network-Tab können wir nach font filtern und uns ansehen, was tatsächlich übertragen wird.

Häufig werden deutlich weniger Schriftschnitte benötigt, als ursprünglich eingebunden wurden.

Auch die Frage, ob Fonts extern oder lokal bereitgestellt werden, ist einen Blick wert.

9. JavaScript

#

Bei JavaScript zählt nicht nur die Dateigröße.

Der Browser muss heruntergeladenen JavaScript-Code anschließend verarbeiten und ausführen.

Das kann insbesondere auf schwächeren Smartphones relevant werden.

Slider, Animationen, Tracking, Page Builder und verschiedene Plugins können zusätzliche Skripte einbinden.

Lighthouse kann Hinweise auf große oder nicht benötigte JavaScript-Anteile geben.

10. Datenbank

#

Bei älteren WordPress-Installationen können sich Revisionen, temporäre Daten, Plugin-Tabellen und andere Daten ansammeln.

Das bedeutet allerdings nicht automatisch, dass eine Datenbankbereinigung die Website spürbar schneller macht.

Genau deshalb haben wir Query Monitor und unsere Messungen.

Wenn die Datenbank nicht das Problem ist, müssen wir sie nicht zum Problem erklären.

Was ist mit Minify?

#

CSS und JavaScript zu minifizieren reduziert die Dateigröße.

Das ist technisch sinnvoll.

Der Effekt sollte aber im Verhältnis betrachtet werden.

Wenn ein Titelbild 4 MB groß ist, würde ich nicht zuerst eine Stunde damit verbringen, weitere 8 KB aus einer CSS-Datei herauszuholen.

Zuerst kümmern wir uns um die großen Hebel.

Was ist mit einem CDN?

#

Ein Content Delivery Network kann statische Ressourcen über geografisch verteilte Server bereitstellen.

Das kann insbesondere bei einem internationalen Publikum sinnvoll sein.

Für einen kleinen Blog mit hauptsächlich regionalem Publikum muss ein CDN aber nicht zwangsläufig die erste Performance-Maßnahme sein.

Auch hier entscheidet das konkrete Problem.

Ein praktischer Performance-Workflow

#

Für eine normale WordPress-Seite würde ich folgendermaßen vorgehen:

PageSpeed Insights
        │
        ▼
grobe Probleme erkennen
        │
        ▼
Browser Network
        │
        ▼
Requests + Größen + Waterfall
        │
        ▼
größten Kandidaten auswählen
        │
        ▼
eine Änderung
        │
        ▼
erneut messen

Wenn die erste Serverantwort auffällig langsam ist:

langsames HTML
      │
      ▼
Server / WordPress untersuchen
      │
      ├── Caching
      ├── Plugins
      ├── PHP
      └── Query Monitor

Wenn dagegen die Seite hauptsächlich riesige Ressourcen lädt:

großer Download
      │
      ▼
Network-Tab
      │
      ├── Bilder
      ├── Fonts
      ├── JavaScript
      └── externe Dienste

Damit haben wir zumindest einen Plan und klicken nicht wahllos Optimierungsoptionen an.

Unsere Testseite

#

Wir haben die einzelnen Schritte auf einer eigenen WordPress-Testinstallation nachvollzogen.

Dabei haben wir unter anderem Lighthouse, die Netzwerkanalyse, den Network Waterfall und Query Monitor verwendet.

Die Screenshots in diesem Artikel stammen aus diesen tatsächlichen Tests.

So können wir nicht nur behaupten, dass eine Maßnahme schneller sein sollte.

Wir können zeigen, was die Werkzeuge tatsächlich messen und wo wir nach Problemen suchen können.

Fazit

#

WordPress-Performance ist weniger geheimnisvoll, als viele Optimierungsanleitungen vermuten lassen.

Wir brauchen zunächst keine Sammlung von 50 Tweaks.

Wir brauchen Messwerte.

PageSpeed Insights und Lighthouse geben uns einen guten Überblick. Die Netzwerkanalyse zeigt uns, was der Browser tatsächlich lädt. WebPageTest erlaubt einen detaillierteren Blick auf den Ablauf. Und wenn das Problem innerhalb von WordPress liegt, können Werkzeuge wie Query Monitor bei der weiteren Diagnose helfen.

Danach optimieren wir den größten sinnvollen Kandidaten und messen erneut.

Der wichtigste Performance-Tipp lautet deshalb nicht:

Installiere dieses Plugin.

Sondern:

Nicht raten. Messen.