WordPress Beschleunigung mit WP-Rocket

Wir sehen uns heute an, was man bei einer WordPress Seite tun sollte, damit sie auch wirklich verwendbar wird. Wir nehmen als Beispiel die https://clubcomputer.at Website. Wir machen einen Test mit GT Metrix um zu sehen was unsere Ausgangsbasis ist. GT Metrix ist ein Testtool, dass die Ladezeiten von Websites misst und auch hilft die Probleme aufzuzeigen.

https://gtmetrix.com

Messergebnisse vor der Optimierung

Vor der Optimierung:

Wir sehen, dass wir eine Seitenladezeit von 7,5 Sekunden haben. Die Seite ist 2,5MB groß und um sie zu laden benötigt der Browser 138 Requests die vom Server geladen werden. Das Problem mit WordPress ist, dass die Programmlogik dahinter recht komplex ist, und WordPress auch meist aus vielen Plugins zusammengesetzt wird. Die Webseiten werden mithilfe der Programmiersprache PHP erzeugt. PHP liest sehr viele Informationen aus einer Datenbank (meistens MySQL). Dieser Vorgang benötigt Zeit, belastet je nach Zugriffshäufigkeit (Anzahl der Website Besucher) die CPU und Hauptspeicher des Servers. Zudem müssen die so erzeugten dynamischen Webseiten dann noch über das Internet an den Browser des Benutzers ausgeliefert und dort angezeigt werden.

Installieren eines Cache Plugins

Es ist auf allen WordPress Seiten empfohlen ein Caching Plugin zu installieren. Wir verenden das Plugin „WP Rocket“, es ist kostenpflichtig aber sehr einfach im Umgang. Caching Plugins erzeugen Seiten, die sich nicht oft ändern einmal und speichern sie auf der Platte des Webservers zwischen. Damit muss der Webserver diese Seiten nicht bei jedem Zugriff erzeugen, sondern sie nur noch an den Benutzer ausliefern. Im ausliefern von statischen Webseiten sind Webserver sehr gut. Das passiert daher recht rasch.

Zudem schalten diese Caching Plugins auch die Cache Funktionalität des Browsers zusätzlich ein. Bestimmte Elemente (z.B. Grafiken) müssen dann gar nicht mehr über das Internet übertragen werden, denn sie liegen schon auf der Festpatte des Benutzers, wenn sie bereits vor kurzem angesehen wurden. Diese Elemente werden dann gar nicht mehr übers Internet geschickt, sondern nur noch lokal geladen.

Messergebnisse nach dem Aktivieren von WP Rocket

Alleine durch das Einschalten des Plugins (ohne Konfiguration) verbessert sich unsere Ladezeit deutlich auf 1,8 Sekunden. Wir sehen aber, dass die Anzahl der Requests beinahe gleichbleibt. Die beiden Performance Scores sind auch noch nicht zufriedenstellend. Wir werden uns mit diesen nun im Detail beschäftigen.

Den Test, den wir verwenden ist Pagespeed. Er wird unterhalb der oben gezeigten Zusammenfassung angezeigt. Wir bekommen hier einige Hinweise wie wir die Ladezeiten unserer Seite weiter verbessern können:

Wir beschäftigen uns zuerst mit den Zeilen, die uns einen besonders schlechten Performance grade bescheren:

Ergebnisse Remove Query String for static ressources

Wir sehen hier, dass JavaScripts und andere Ressourcen geladen werden, die statisch sind (also nicht zur Laufzeit erzeugt werden, aber die einen Query String (also eine Abfrage) hinten angehängt haben. Beispielsweise ?ver=2.5.14.6684 – dieser Querstring bewirkt zwar nichts bei der Abfrage – aber er verhindert, dass diese Dateien gecached werden können.

Wir schalten also in WP Rocket folgende Option ein:

Option Query String in Static Ressources entfernenEin neuer Test biringt uns hier auf Grade „A“ mit 94%.

Die nächste Problematik, die wir uns ansehen ist „Defer Parsing of Javascript“. Wir bekommen hier folgendes Bild:

Defer Parsing of JavaScript

GTMetrix sagt uns, dass wir 1,2MiB Javascript laden. Diese Scripts werden ausgeführt bevor die Seite angezeigt wird Das Ausführen des Javascripts verhindert, dass wir die Seite sehen.

Dafür gibt es diese Option in WP Rocket. Wir schalten sie ein:

WP Rocket Defer Parsing of JavaScript

Wir testen wieder mit GTMetrix und sehen dass wir im Ergebnis nach unten gerutscht sind und uns ebenfalls auf Grade „A“ mit 92% verbessert haben.

Als nächsten Schritt nehmen wir uns folgendes Problem vor:

GTMetrix Ergebnis Minify JavaScripts

Bei der Minifizierung wird der Java Code optimiert, der über die Leitung übertragen wird. Es werden Zeichen, die die Lesbarkeit verbessern, aber für die Ausführung nicht benötigt werden entfernt. Damit wird die Anzahl der Zeichen die über die Leitung gesendet werden verringert.

Wir aktivieren folgende Option:

WP Rocket JavaScript Minifizieren

Bei der Aktivierung werden wir darauf hingewiesen, dass die Aktivierung Probleme machen kann. Es ist also notwendig, dass wir nach der Aktivierung unsere Seite testen, und sehen ob irgendwo ein Problem auftritt.

Wichtig ist beim Einschalten einer derartigen Option danach die Seite ausführlich zu testen. Bemerkt man ein Problem, dann kann im zugehörigen Feld Ausnahmen eintragen. Man kann etwa bestimmte Plugins oder einzelne CSS oder JavaScripts von den Maßnahmen ausnehmen. Dazu gehört aber mehr Erfahrung und Wissen, das sollte man eher einem Spezialisten überlassen.

Wir bekommen hier nach dem Einschalten dieser Option ein grünes Ergebnis mit Grade “A” und 97%.

Im nächsten Schritt schalten wir nun bei den CSS alle 3 Optionen ein, und bekommen auch hier die Warnungen, die wir schon beim JavaScript bekommen haben.

WP Rocket CSS Optionen

Ein neuerlicher Test bringt uns bei Inline small CSS auf grün und 100% und gleichzeitig bei Minify CSS auf grün und 99%.

Bleibt uns noch:

GT Metrix Inline small JavaScript

Wir aktivieren also in WP Rocket folgende Option:

WP Rocket JavaScript zusammenfassen

Wir bekommen auch hier wieder eine Warnung, dass die Aktivierung gefährlich ist, und es zu Störungen auf unserer Seite kommen kann. Wir akzeptieren das.

GT Metrix gibt uns nun das Ergebnis, dass “Inline smal JavaScripts” jetzt grün mit 100% bewertet wird.

Wir schalten nun och noch die letzte verbliebene WP Rocket Funktion ein. Sie bringt keine dramatischen Verbesserungen, hier wird noch der HTML Code optimiert:

HTML Minifizieren

Mittlerweile sehen unsere Performance Scores bereits sehr gut aus:

PageSpeed 92%, YSOW 82%

Wir sehen uns noch den YSlow Score an (er ist immer schlechter als die Page Speed Score). Hier zeigt uns YSlow folgendes Problem:

Add Expire Headers

Wir sehen dass alle angemerkten Seiten von einer anderen Seite geladen werden. Die erste Zeile ist ein Google Font, die nächsten zwei sind das Pixel bzw. Bild von Blogheimat (einem österreichischen Portal, dass die Performance (Beliebtheit) von Blogs misst und ein Ranking erstellt, und die vierte Zeile ist wieder ein Google Font. Wir könnten hier nun, um das Ergebnis zu optimieren nur das Pixel/Bild von Blogheimat entfernen und eventuell die Google Fonts nicht von Google, sondern direkt von unserer Seite laden. Wir entscheiden uns also vorerst die Sache so zu belassen.

Wir aktivieren nun noch folgende zwei Optionen in WP Rocket:

Lazyload

Sie verursachen, dass Bilder / Videos erst geladen werden, wenn sie in den sichtbaren Bereich des Browsers kommen. Das kann unsere Ladezeiten weiter verbessern, wenn Bilder im unteren Bereich einer Website angezeigt werden.

Bilder Optimieren

Es bleibt uns nur noch ein offener Punkt für die Pagescore Analyse:

Optimize Images

Wir verwenden zum Optimieren der Bilder das Plugin WPMUDEV Smush Pro. Wir haben ein Abo für WPMUDEV, dass uns erlaubt diese Software auf allen bei uns betriebenen WordPress Installationen zu betreiben.

Wir sehen, dass bei Clubcomputer.at 11.509 Grafikdateien liegen, bei denen wir uns 2,9GB Platz (=33%) durch die Optimierung ersparen. Es geht uns aber hier nicht um den Plattenplatz, der eingespart wird, sondern dass dann diese Daten auch bei einem Abruf von der Website nicht geladen werden müssen. Daher: Die Website lädt dadurch schneller, weil weniger Daten über die Leitung gehen.

Smush Pro Dashboard

Es wird uns hier auch angezeigt, dass 711 Dateien noch nicht optimiert wurden. Diese können mit dem Button „Buld Smush now“ optimiert werden. Das dauert einige Zeit (Stunden) während dessen man auch das Browserfenster offen lassen muss.

2.   Ergebnis
Wir vergleichen nun unser Endergebnis mit den Zahlen von Beginn:

Statistiken Anfang

Endergebnis

Unsere Seitengröße konnte (ohne Veränderung für den Nutzer) von 2,54 auf 2,19 MB reduziert werden. Die Anzahl der Requests (Zugriffe) auf den Webserver von 137 auf 37 fast geviertelt werden. Die Ladezeit hat sich dadurch von 7,5 Sekunden auf 1,7 Sekunden reduzieren lassen. Das Ergebnis ist also durchaus beachtlich.

Follow me on

Werner Illsinger

Chief Technology Officer bei CC Communications
Werner Illsinger ist systemischer Coach, Unternehmensberater sowie Lektor an der FH-Kärnten. Sein Herzensanliegen ist es, dass Arbeit Spaß macht.
Follow me on

Letzte Artikel von Werner Illsinger (Alle anzeigen)