WordPress Speed Optimierung – Performanceprobleme identifizieren und beheben

Um mögliche Probleme mit dem Speed der eigenen Website korrekt identifizieren zu können, ist es wichtig, dass man die innere Funktionsweise von WordPress zumindest ansatzweise versteht. Wer die technische Verarbeitung innerhalb des WordPress Core versteht, findet zuverlässig geeignete Ansatzpunkte für die Performanceoptimierung, für alle Anderen bleibt nur Try & Error.

WordPress arbeitet mit sogenannten Hooks & Filtern. Diese zwei Techniken der Programmierung ermöglichen es Entwicklern von Plugins und Themes, während der Laufzeit auf Daten & Eigenschaften von WordPress zuzugreifen, diese zu beeinflussen und zu verändern.

Damit der Redakteur beispielsweise bequem eine Bildergalerie im Backend erstellen kann, installiert dieser wahrscheinlich ein zusätzliches Plugin, welches genau diese Funktion zur Verfügung stellt. Damit der Redakteur nach der Installation des passenden Plugins tatsächlich auch eine Bildergalerie erstellen kann und diese danach den Besuchern der Website auch ausgegeben wird, müssen sowohl im Frontend wie auch im Backend zusätzliche Programmfunktionen bereitgestellt werden. Damit das Plugin diese Programmfunktionen hinzufügen kann, stellt der WordPress Core unzählige kleine Programmierschnittstellen in Form von Hooks & Filtern zur Verfügung. Über diese Schnittstellen können Plugins zusätzlichen Code im WordPress Core registrieren. Dieser zusätzliche Code greift oft mitten in den Verarbeitungsprozess von Informationen ein, was eine Manipulation der zu verarbeitenden Informationen zur Laufzeit ermöglicht.

Je mehr Hooks und Filter in einem Content Management System vorhanden sind (und bei WordPress sind das sehr viele), desto flexibler ist das System und desto einfacher kann die Funktionalität des System mittels Plugins erweitert werden.

Die Vor- und Nachteile von Hooks liegen auf der Hand. Dank der vielen Hooks, welche der WordPress Core bereitstellt, können zu WordPress alle denkbaren Features & Funktionen hinzugefügt werden. Diese Flexibilität erkauft sich WordPress auf Kosten von Rechenleistung, denn jeder Hook bedeutet zusätzliche Programmschleifen, was die Ausführungszeit negativ beeinflusst.

Bevor man sich mit dem Abarbeiten der Empfehlungen abmüht, welche PageSpeed Insights vorschlägt, sollte man zuerst lernen, die Metriken wie First Contentful Paint oder Time to Interactive zu verstehen. Dies ist besonders wichtig, da die Analyse seitens PageSpeed Insights nur technische Metriken misst, was mit der tatsächlich gefühlten Ladezeit oft nicht übereinstimmt. Versteht man es nicht, die Metriken korrekt zu interpretieren, setzt man bei der Performanceoptimierung möglicherweise am falschen Ort den Hebel an.

Der Browser hat den ersten Teil des Inhalts aus dem DOM gerendert und gibt dem Benutzer die erste Rückmeldung, dass die Seite tatsächlich geladen wird.
> Indikator, wie schnell die Website Serverseitig verarbeitet wurde und ob serverseitige Optimierungen notwendig sind

Misst, wie lange es geht bis das grösste Inhaltselements auf der Webseite, z.B. ein Slider oder die Hero-Section, für die Besucher geladen und gerendert ist.
> Indikator, wie schnell die Website gerendert wird und ob der Content der Website optimiert werden sollte

Der TTI misst den frühesten Zeitpunkt nach dem First Contentful Paint (FCP), an dem die Seite zuverlässig für die Interaktivität des Benutzers bereit ist. TBT misst die Gesamtzeit, in der die Webseite blockiert war und den Nutzer daran hindert, mit der Seite zu interagieren.
> Indikator, ob zu viel JavaScript, SVG verarbeitet werden muss und deferred/async Loading angewandt werden soll

Nachdem wir nun besser verstehen, wie die Werte von PageSpeed Insight korrekt zu interpretieren sind, können wir daraus einen Grundsatz ableiten.

Nachfolgend werden wir nun einige Methoden vorstellen, wie die Performance von WordPress Websites stark verbessert werden kann. Wir erklären, welche Metriken beachtet werden müssen, um Probleme zu erkennen und geben Tipps zur Fehlerbehebung. Bevor wir richtig loslegen, möchten wir jedoch noch zuerst zwei weitere wichtige Instrumente zur Identifizierung von Problemen vorstellen.

Das Plugin Query Monitor ist unverzichtbar, wenn es um die Identifizierung von Performance Schwachstellen geht. Es hilft zuverlässig beim Identifizieren von langsamen, nicht optimierten Datenbankabfragen und schlecht programmierten Plugins. Neben den Datenbankabfragen, zeigt Query Monitor auch die gesamte Zeit welche für die Seitengenerierung benötigt wird. Hier sollte immer eine Gesamtzeit für die Generierung von unter 1 Sekunde angestrebt werden. Unser Beispiel liegt mit 1.36 Sekunden über dem angestrebten Wert, dies weil es sich hier um eine sehr lange und komplexe Inhaltsseite handelt und der Kunde hier eine etwas längere Wartezeit in Kauf nimmt.

Mittels der Option WP_DEBUG_LOG, welche in der Konfigurationsdatei von WordPress (wp-config.php) gesetzt werden kann, zwingt man WordPress, alle PHP Fehler zu protokollieren. Durch die korrekte Kombination der Optionen WP_DEBUG, WP_DEBUG_DISPLAY und WP_DEBUG_LOG werden alle Fehler in eine Logdatei umgeleitet, statt diese den Besuchern anzuzeigen. Die Logdatei wiederum kann sporadisch auf Fehler überprüft werden. Teilweise findet man dank der Datei debug.log Fehler in Plugins, welche sich negativ auf die Performance auswirken.

Bevor wir beginnen Massnahmen zur Performanceoptimierung umzusetzen, sollten wir das Hosting prüfen. Relevant sind folgende Metriken:

Wir erlauben uns hier eine persönliche Empfehlung zum Hosting abzugeben:

Auch andere Hosting Anbieter wie Hostpoint, Metanet, Hoststar, Infomaniak oder Cyon können für das Hosting in Betracht gezogen werden. Hosttech, Webland und sonstige kleine Anbieter haben sich gemäss unserer Erfahrungen als ungeeignet für das Hosting von WordPress erwiesen. Diese Liste bildet sich aus den Erfahrungen unserer Agentur aus den letzten 15 Jahren.

Werden Performance Probleme festgestellt, wird oft versucht die Ladezeit zu verbessern, indem ein zusätzliches Plugin installiert wird. Einige Plugins wie WP Rocket, Hummingbird Pro oder W3 Total Cache versprechen auf Knopfdruck eine Verbesserung der Ladezeiten. Wir haben alle diese und weitere Performance Plugins installiert und ausprobiert, mit gutem aber auch mit mässigem Erfolg. Teilweise wurde die Website sogar langsamer. Wie kann das sein?

Eine einfache und effiziente zur Verbesserung der Ladezeiten der eigenen Website ist aktivieren des Browser Caches. Dadurch wird der Browser des Besuchers angewiesen, statische Inhalte wie Bilder, Grafiken, CSS und Javascript für einen bestimmten Zeitraum im lokalen Speicher zwischenzuspeichern. Gleich und unveränderte Dateien müssen somit nicht wiederholt vom Server zum Client übermittelt werden, was die Ladezeiten beim wiederholten aufrufen der Homepage oder von Unterseiten verbessert.

Mittels der Datei .htaccess kann der Browser des Besuchers angewiesen werden, die Inhalte von spezifischen Dateitypen wie z.B. alle JPEG-Bilder oder alle CSS-Dateien für einen bestimmten Zeitraum lokal zwischenzuspeichern und jeweils direkt aus dem internen Cache zu laden.

Mittels Page Caching wird versucht, Ressourcenengpässe seitens der Serverinfrastruktur wie zu wenig RAM oder zu wenig CPU-Leistung zu verhindern oder zu umgehen, indem man die Serverressourcen schont und die Anzahl an rechenaufwändigen und ressourcenintensiven Aufgaben reduziert. Um die Ressourcen zu schonen, weisen Plugins wie WP Rocket, Super Cache oder W3 Total Cache den Server an, die Ergebnisse der nötigen Berechnungen zur Bereitstellung einer Website in Dateien auf der Festplatte oder im Arbeitsspeicher zwischenzuspeichern. Damit wird erreicht, dass die ressourcenaufwendigen Berechnungen nicht bei jedem Aufruf der Website wiederholt ausgeführt werden müssen, vielmehr kann bei wiederholtem Aufrufen der Website das Ergebnis direkt aus dem Zwischenspeicher geladen werden, ohne dass die Berechnungen erneut ausgeführt werden müssen.

Das Dilemma von Page Caching ist, dass es bei statischen Websites keinen nennenswerten Performance Vorteil bringt und bei komplexen dynamischen Websites Fehleranfällig ist. Bei wenig komplexen Websites bringt Page Caching nur einen geringen Performancevorteil gegenüber der wiederholten Berechnung und Bereitstellung der Inhalte mittels CPU & RAM. Dies, weil der Zugriff auf das Dateisystem und das Öffnen der in der Datei enthaltenen Informationen ebenfalls eine gewisse Zeit in Anspruch nimmt. Wenn keine SSD Disks im Einsatz sind, ist von Page Caching definitiv abzuraten.

Ein persistenter Objekt-Cache hilft, die Ladezeiten von Seiten zu verkürzen, indem er dem Webserver Wege zur Datenbank erspart. Beim Caching von Objekten werden die Ergebnisse von Datenbankabfragen gespeichert, so dass beim nächsten Mal ein Ergebnis aus dem Cache abgerufen werden kann, ohne die Datenbank wiederholt abfragen zu müssen.

WordPress implementiert Object Caches über WP_Object_Cache. Dabei ist das Caching standardmässig nicht-persistent. Das bedeutet, dass die Daten im Cache nur für die Dauer der Anfrage gespeichert werden. Zwischengespeicherte Daten werden nicht dauerhaft und über mehrere Requests hinweg gespeichert. Will man eine persistente Speicherung der Daten erreichen, muss man ein zusätzliches Plugin installieren, welches einen persistenten Speicher wie Redis oder Memcached implementiert.

Wer weder Memcached noch Redis zur Verfügung hat, kann auf das Plugin «Docket Cache» ausweichen, um einen persistente Speicherung der Informationen zu erreichen.

Ein Reverse-Proxy sitzt vor einem Webserver und empfängt alle Anfragen, bevor sie den Zielserver erreichen. Entsprechend kann der Reverse-Proxy zur Beschleunigung der Performance eingesetzt werden, indem er sowohl statische als auch dynamische Inhalte zwischenlagert und dadurch die Last auf den Zielserver verringert. Varnish Cache und Nginx FastCGI sind bekannte Beispiele für Reverse Proxies.

Nginx eignet sich hervorragend für den Umgang mit mehreren gleichzeitigen Benutzern, ohne dabei viele Serverressourcen zu verbrauchen. Apache ist extrem schnell für die effiziente Verarbeitung von PHP. Einige Schweizer Hosting Anbieter bieten aus diesem Grund die Möglichkeit, Nginx als Reverse Proxy einzusetzen, um das Beste aus beiden Welten zu kombinieren.

Fast alle Plugins zur Optimierung der Website Performance wollen uns dazu bringen, einen CDN einzusetzen. Zur Profitoptimierung ist dies für die Hersteller der Performance Plugins besonders attraktiv, da für die Bereitstellung eines CDN’s oft eine zusätzliche monatliche Gebühr anfällt, welche die Betreiber der Websites bezahlen müssen. Doch wer braucht einen CDN wirklich und wann ist der Einsatz Sinnvoll?

CDN’s versprechen bessere Leistung und höhere Zuverlässigkeit. Doch wie funktioniert ein CDN im Detail und wie wird dadurch die Performance verbessert?

Besucht jemand beispielsweise die Website Shoppingtotal.ch, welche hier in der Schweiz auf einem Server gehostet wird, müssen jeweils alle Daten aus dem Serverzentrum in der Schweiz zum Bestimmungsort des Besuchers übermittelt werden. Je nach Standort des Besuchers müssen die Daten demnach einen kürzeren oder längeren Weg zurücklegen, bis diese am Zielort angelangt sind. Je nach Distanz nimmt die Datenübermittlung entsprechend mehr oder weniger Zeit in Anspruch.

Ein CDN kopiert und verteilt relevante Daten und Informationen einer Website in verschiedene Serverzentren auf der ganzen Welt, damit die Daten immer nur einen möglichst kurzen Weg bis zum Bestimmungsort zurücklegen müssen. Wenn nun ein Besucher unsere Website von einem beliebigen Standort auf der Welt abruft, werden die Daten jeweils aus dem nächstgelegenen Serverzentrum abgerufen und nicht zwingend aus dem Serverzentrum in der Schweiz.

Grundsätzlich macht der Einsatz eines CDN nur dann Sinn, wenn ein Unternehmen international ausgerichtet ist und entsprechend der Zugriff auf die Website des Unternehmens aus der ganzen Welt erfolgt. Kommt der Traffic, wie im Beispiel oben, hingegen zu 85% aus der Schweiz, ist ein CDN nur dann nötig, wenn sich der Serverstandort nicht in der Schweiz befindet.

Die GZIP-Komprimierung ist eine einfache und wirksame Methode, um Bandbreite zu sparen und die Ladezeiten von Websites zu verbessern. Die Komprimierung ist schnell aktiviert und hat keinerlei negative Nebeneffekte wie zum Beispiel bei anderen Optimierungsverfahren wie Combine & Minify von JavaScript und CSS auf Plugin-Basis, welches sehr fehleranfällig ist.

Alle modernen Browser enthalten standardmässig Support für die GZIP-Komprimierung, entsprechend kann es problemlos eingesetzt werden. GZIP ermöglicht es, die Grösse der HTML-Seiten, Stylesheets und Skripte von Webseites zu reduzieren. Dabei erreicht GZIP normalerweise für kleine Daten eine Kompressionsrate von etwa 70% und für grosse textbasierte Daten bis zu 90%.

Um die GZIP-Komprimierung auf Apache-Servern aktivieren zu können, müssen Sie die Module mod_filter und mod_deflate installiert sein. Ist das der Fall, kann GZIP in der .htaccess-Datei konfiguriert werden. Noch einfacher geht es mit Plugins wie WP Rocket oder Hummingbird Pro, welche die nötigen Zeilen zum aktivieren von GZIP automatisch in die .htaccess Datei einfügen.

Die richtige PHP Version zu verwenden kann WordPress beschleunigen. So zeigt ein Benchmark Test von Cloudflare eine bessere durchschnittliche Response Time von 20% von PHP 8 gegenüber PHP 7.4. Leider hinkt WordPress in der Entwicklung hinterher, weshalb die neusten PHP Versionen oft erst Jahre nach deren Einführung sicher verwendet werden können.

Wichtig für die Performance ist jedoch nicht nur die Verwendung der neusten Version von PHP. Auch die Qualität des Codes ist von Bedeutung, entsprechend muss bei der Entwicklung darauf geachtet werden, dass keine PHP Warnings entstehen. Auch wenn die Ausgabe von PHP-Warnings im Frontend ohne weiteres unterdrückt werden können, sind diese hinsichtlich der Performance einer Website nicht zuträglich und sollten wenn immer möglich zu 100% eliminiert werden.

Um den Benutzern eine Liste der neuesten Artikel anzuzeigen könnte eine einfache SQL-Abfrage wie `SELECT * FROM wp_posts ORDER BY post_date ASC` verwendet werden und später in PHP mit `array_slice($array, 0, 5)` auf 5 beschränkt werden. Das Problem dabei ist, dass alle Artikel aus der Datenbank gelesen werden, was unter Umständen viel Zeit in Anspruch nimmt und die Leistung beeinträchtigt. Ein besserer Ansatz ist es, die SQL-Abfrage mittels LIMIT einzuschränken.

Dies ist nur ein Beispiel einer schlecht geschriebenen Datenbankabfrage. Die folgenden Grundsätze sollte man bei Datenbankabfragen beachten:

Da Caching‑Methoden einen klaren Mehrwert hinsichtlich der Ladezeiten von Websites bieten, sollte für jede Website eine geeignete Caching Strategie entwickelt werden, welche die eingesetzten Arten des Caching definiert und den Einsatz dieser beschreibt. In eine Caching Strategie sollten folgende Caching Methoden einbezogen werden:

Ein Index ist eine Datenstruktur, die speziell für die effiziente Suche und Sortierung von Daten entwickelt wurde. Es ermöglicht es, Daten in einer bestimmten Reihenfolge zu organisieren und schneller darauf zuzugreifen. Wenn man eine Datenbankabfrage ausführt, kann das System den Index verwenden, um schnell auf die relevanten Daten zuzugreifen, anstatt die gesamte Datenbank durchsuchen zu müssen. Dadurch wird die Geschwindigkeit der Abfrage erheblich verbessert. Bekannte Beispiele sind z.B. der Suchindex von Search WP oder Relevanssi. Weiter erstellen viele WooCommerce Filter Plugins einen Index für die Anzahl Produkte nach Kategorie. Solche Indizes können die Performance von WordPress erheblich steigern.

Es ist jedoch wichtig zu beachten, dass das Erstellen von Indizes auch einige Nachteile haben kann. Es verbraucht Speicherplatz und erhöht die Zeit, die benötigt wird, um neue Daten hinzuzufügen oder Daten zu ändern. Daher ist es wichtig, die Indizes mittels eines Hintergrundprozesses zu erstellen, welcher beispielsweise jede Nacht automatisch ausgeführt wird.

Viele moderne Webanwendungen sind auf APIs von Drittanbietern angewiesen. So kann eine Anwendung beispielsweise auf einen E-Mail-Server angewiesen sein, um Transaktions-E-Mails zu versenden, auf einen Zahlungsabwickler, um Bestellungen zu bearbeiten, oder auf ein Content Delivery Network (CDN), um Bilder zu hosten.

Statt immer wieder bei jeder Anfrage die Geodaten einer Adresse über eine API auflösen zu lassen, sollte das Resultat nach der ersten Abfrage in der Datenbank gespeichert werden, damit zukünftig die bereits zuvor aufgelösten Werte geladen werden.

Geht es um Speedoptimierung und WordPress, versuchen viele sich an sogenanntem Minify & Combining. Viele Plugins wie WP Rocket, WP Optimize oder Hummingbird Pro bieten spezielle Features, welche ein einfaches und sorgenfreies Kombinieren und Minimieren der Dateien versprechen. Leider versprechen diese oft zu viel bzw. es ist praktisch unmöglich, 20 oder mehr Dateien in einer einzigen Datei so zusammenzufassen, dass es keine Konflikte gibt.

Während das Minimieren von Dateien seine Berechtigung hat und in der Regel auch sorgenfrei durchgeführt werden kann, da es nicht zur Laufzeit durchgeführt werden muss, ist das Kombinieren von Dateien eine herausfordernde Aufgabe. Besonders, da bei Fehlern in der Zusammenführung dazu führen können, dass einige Teile der Website nicht mehr funktionieren. Braucht es diesen Balanceakt in Zeiten von HTTP/2 und HTTP/3 überhaupt noch?

In einer idealen Welt hätten wir nur wenige Abhängigkeiten und unser Website würde nicht 40 oder mehr Styles und Scripts benötigen. Mit WordPress ist dieses Szenario jedoch nicht realistisch, auch in Zukunft werden komplexe Websites einige Abhängigkeiten benötigen. Im Jahr 2015, Google und Microsoft sei Dank, wurde das Protokoll HTTP/2 spezifiziert und das Leben von uns und zahlreichen anderen Entwicklern wurde einfacher. Die neuen Spezifikationen bieten die Möglichkeit des Zusammenfassens (Multiplex) mehrerer Anfragen. Das bedeutet, mühsames Combining von Dateien seitens WordPress ist nicht mehr wichtig und man kann sich diesen Balanceakt getrost sparen.

Nicht notwendige Redirects können die Geschwindigkeit der Website positiv beeinflussen. Wenn die Zielseite eine Umleitung enthält, wiederholt der Browser den gesamten DNS-Auflösungsprozess noch einmal, um den Benutzer zur richtigen Webseite zu führen. Diese mehrfachen Weiterleitungsanfragen belasten die Browserressourcen und verlangsamen das Laden der Seite.

Beim setzen der Links sollte man die Struktur beachten, welche im WordPress Adminpanel unter Einstellungen › Permalinks gewählt wurde. Insbesondere sollte auch beachtet werden, ob eine Struktur mit Slash am Schluss gewählt wurde.