Vollgas bei der WordPress Seitenauslieferung

Aus gegebenem Anlass möchten wir eine WordPress-Serie starten, heute dreht sich alles um das Thema Geschwindigkeit. Auch wir nutzen zwei Komponenten, um die Ladezeit unserer Seite gegen null zu bekommen. Welche das sind und wie sie implementiert sind, möchten wir in diesem Artikel beleuchten.

Disclaimer: Bis auf das Caching-Plugin sowie das Sitemap-Script erfordern die Schritte in diesem Artikel einen Root-Server, VPS, Dedicated Server und wie sie nicht all’ heißen. Auf einem Shared Webhosting funktioniert dies nicht.

Caching Plugin WP-Rocket

WordPress ist ein CMS, dass seine Inhalte in einer Datenbank speichert und bei jedem Seitenaufruf die angeforderten Inhalte dynamisch generiert. Vergleichen wir das mal mit Lego: Es geht deutlich schneller zu spielen, als vor dem Spielen die Burg erst noch aufbauen zu müssen.

Ein Caching Plugin übernimmt diese Arbeit im Hintergrund und legt die fertigen Seiten ab, diese werden dann auch ausgeliefert. Hierzu gehören auch die minifizierung von CSS und JS.

Wir setzen dabei auf wp-rocket, natürlich nicht im Standard. Auf Rocket Analytics und Rocket CDN verzichten wir gänzlich, Matomo kann Statistiken auch ganz gut erstellen – ein CDN ist bei 2,5 GBit WAN-Anbindung ebenfalls nicht vonnöten. Wir arbeiten uns Reiter für Reiter durch:

Cache

Hier sollte man den Cache für mobile Geräte aktivieren, wenn euer Wert für die Mobilgeräte bei Pagespeed es erfordert. Die Cache Dauer kann bei Seiten mit wenig Änderung (News Publishing, Homepage einer Firma) auf 24h gestellt werden.

Datei-Optimierung

Hierzu gibt es keine allgemeingültige Anleitung, das variiert zu stark nach den verwendeten Plugins als auch dem benutzen Theme.

CSS und JS zu minifizieren ist generell eine gute Idee. Setzt eine neue Einstellung und schaut euch an wie sich eure Seite verhält. WICHTIG: NACH NEUER EINSTELLUNG IMMER DEN CACHE LEEREN! Dem bin ich zu Beginn ganz schön auf den Leim gegangen, das tut das Plugin nicht automatisch nach einer Änderung.

Medien

Hier können wir für alles Lazyload aktivieren, falls das verwendete Theme das nicht schon tut. Ebenfalls sinnvoll ist es die fehlenden Bildabmessungen hinzufügen zu lassen.

Cache Füllen

Vorladen aktivieren, er erkennt die Sitemap und lädt künftig automatisch vor. Das funktioniert eher so semi-gut, mehr dazu etwas später im Artikel.

Unter DNS Prefetch könnte man Dinge angeben wie z.B. matomo.linuxnews.de, so ist die Ladezeit trotz eingebundenen Matomo-JS immer kurz, da nicht erst ein DNS-Lookup notwenig ist.

Ebenfalls kann man die Fonts vorladen lassen. Wie komme ich an meine Fonts? So:

Ruft eure Seite ganz normal auf und drückt F12 um die Entwickler-Tools zu öffnen. Begebt euch in den Reiter Netzwerkanalyse und drückt erneut auf laden. Nun lädt die Seite neu und die Liste füllt sich. Der Einfachheit halber kann man das Wort Initiator anklicken und sich alles nach Art sortieren lassen, so stehen alle Fonts untereinander und man muss nicht die gesamte Liste durchgehen.

Klickt den ersten (Font)Treffer an, es öffnet sich rechts ein Kasten. Darin steht die GET Anfrage, genau die ist es die wir benötigen. In diesem Fall wäre das https://linuxnews.de/wp-content/fonts/open-sans/memSYaGs126MiZpBA-UvWbX2vVnXBbObj2OVZyOOSr4dVJWUgsg-1x4gaVI.woff2. Genau das ist die URL die in das Fonts vorladen Feld eingetragen werden muss. Wiederholt das, bis ihr alle Fonts beisammen habt. Manchmal werden Fonts auch nur auf bestimmten Seiten geladen, navigiert euch einfach mal durch eure komplette Seite bis ihr alle erschlagen habt.

Erweiterte Regeln

Wer hier etwas eintragen muss, wird das schon wissen. Für den Rest empfehlen sich nur zwei Einträge unter “Nie cachen”, das wäre zum einen /kontakt oder wie es bei euch eben heißt, WP-Forms hat manchmal Probleme mit Caching. Die Zweite ist /feed.

TMPFS

Wir haben nun einen gut konfigurierten Seitencache, der uns aber noch nicht so auf die Tube drückt wie man das gerne hätte. Gerade auf HDD’s ist die Auslieferungszeit so zwar schneller, aber noch nicht optimal. Getreu dem Motto “Da geht noch was”, geht da auch noch was. tmpfs entered the chat. Einfach gesagt ist das ein Dateisystem im Arbeitsspeicher, Arbeitsspeicher ist schneller als die Platte. Allerdings ist er nicht persistent, bedeutet es nicht nach einem Neustart weg. Das ist nicht weiter tragisch, es ist nur Cache und keine echten Daten. Doch wie erstellt man sowas?

Zuerst suchen wir uns unseren Webroot, das Verzeichnis wo WordPress drin liegt. Sieht z.B. so aus: /var/www/wordpress. Dieser Pfad muss noch erweitert werden um /wp-content/cache/. Somit haben wir /var/www/wordpress/wp-content/cache/, genau das muss in die fstab:

/var/www/wordpress/wp-content/cache/ tmpfs defaults,size=5g 0 0

Das in die letzte Zeile der /etc/fstab einfügen und ein mount -a ausführen. Die size=5g wird nicht für jeden passen, gerade auf kleinen VPS mit wenig RAM. Diesen Wert ermittelt man mit einem du -sh auf /var/www/wordpress/wp-content/cache/. Ausgegeben wird die aktuelle Cache-Größe, daran sollte man sich orientieren und etwas Puffer nach oben einrechnen.

Cache aufwärmen (script)

Intelligente Programme mag ich, im Falle wp-rocket ist die Intelligenz allerdings eher so semi-gut. Es erkennt wohl automatisch die Sitemap und füllt damit den Cache. Bei uns hat das nie wirklich gut funktioniert, also musste auch hier eine Eigenentwicklung herhalten. Die Sitemap gibt es, warum nicht selbst nutzen?

Natürlich könnte man diese Aufgabe von einem weiteren Plugin erledigen lassen, wer nun einige meiner Artikel kennt weiß, dass ich Bordmittel mag und es schlank will. Diese Plugin-Reinklatscherei ist schrecklich! Am Ende bekommt die IT auf’s Dach, weil die Webseite so langsam ist. Ja logisch, wenn der Webdesigner seinen ultimativen Plugin-P*rn auslebt und 40-50 Plugins installiert. Das ist kein IT Problem, sondern eins der beauftragten Agentur. Zurück zum Thema:

#!/bin/bash
urls=$(curl -s https://linuxnews.de/sitemap.xml | grep "<loc>" | awk -F"<loc>" '{print $2} ' | awk -F"</loc>" '{print $1}')
for i in $urls
do
   curl -o /dev/null $i > /dev/null 2>&1
done

Der Link in urls=$(curl... muss durch die URL euerer Sitemap ersetzt werden. Doch was passiert da? Das Script holt sich die Sitemap und separiert die einzelnen Links. Diese werden nach und nach nach /dev/null heruntergeladen. Dem Caching-Plugin ist es egal ob es nun ein curl oder ein Webbrowser ist. Es ist eine Anfrage und die wird bearbeitet. Jede Seitenanforderung generiert Cache. Somit ist der Cache immer vollständig und warm. Geht das auch automatisch? Klar:

0 0 * * * rm -rf /var/www/wordpress/wp-content/cache/* > /dev/null 2>&1
5 0 * * * /bin/bash /var/www/scripts/sitemap.sh > /dev/null 2>&1

Die erste Zeile löscht nachts um 12 den Cache, bei uns bevor die Backups anlaufen. Zeile zwei läuft um 5 Uhr morgens, noch bevor ihr alle wach seit und das Lesen beginnt. Hier muss man sich aus seinen Seitenstatistiken heraussuchen, wann “das Loch” bei den Aufrufen ist – das ist nicht zwingend erforderlich.

Warum wir das so machen? NGINX hat dieser Seite ein Rate Limit übergestülpt, wer z.B. seine F5 Taste in zu kleinem Abstand zu oft benutzt muss 10 Minuten auf die stille Treppe. Dieses Rate Limit greift aber nicht für den Server selbst. Bedeutet das Sitemap-Ansauge-Script läuft an und lastet php-fpm vollkommen aus. So wäre die Seite für euch nur schwer benutzbar, das wollten wir vermeiden.

Grundlegend könnt ihr da die Uhrzeiten eintragen die ihr wollt, es sollte nur der Cache nicht nach Erzeugung gelöscht werden 😉. Wer sich mit Cron schwer tut: Hier gibt es eine Testseite.

Solltet ihr bei einem Webhoster sein, der Plesk benutzt (davon weiß ich es sicher), könnt ihr dieses Script auch nutzen. Legt das bei euch im Abonnement irgendwo ab und erstellt eine geplante Aufgabe wie hier zu sehen:

NGINX

Als kleines Schmankerl kann WP-Rocket auch mit NGINX umgehen und stellt dafür auf GitHub etwas fertiges bereit. Die Anleitung ist in der readme.md zu finden. Diese Schnipsel sorgen dafür, dass NGINX auch korrekt arbeitet und ausliefert.

Fazit

Jetzt haben wir der WortPresse so richtig Beine gemacht, das dürfte sich auch in den Zahlen von PageSpeed oder Pingdom widerspiegeln. Zugegeben, die Einrichtung ist nicht einfach, lohnt sich aber wirklich! Wir wünschen viel Spaß beim Umsetzen.

Teilt den Beitrag, falls ihr mögt

Abonnieren
Benachrichtige mich bei
0 Kommentare
Inline Feedbacks
View all comments