Ich bin mir nicht sicher, ob es die „eine Lösung“ gibt, um eine WordPress-Blog auf Trab zu bringen. Die paar Sachen, die ich hier gleich erwähne, haben drei von mir verantwortete Seiten, wie diese hier, auf eine Ladezeit um eine Sekunde gebracht, teils drunter! – Ob dein WordPress, wie meins, auch abei uberspace liegt, ist dabei gar nicht so wichtig. Nur zwei Punkte (PHP 7, Redis) beziehen sich bei der Konfiguration spezifisch darauf, das sollte sich bei einem anderen Hoster adaptieren lassen.

  1. URL korrekt umleiten
  2. PHP 7
  3. Redis Object Cache
  4. Cache Plugins // 4a. Piwik optimieren
  5. WordPress Heartbeat / admin-ajax.php
  6. Bildgrößen anpassen
  7. Lazy Load
  8. Fazit

1. URL korrekt umleiten (auf www und https)

Neu war mir, auch wenn es nicht sonderlich neu ist, dass 301 Umleitungen von Google nicht sonderlich gemocht werden. In einem Fall waren meine Umleitungen so schlecht, dass mehrere Sekunden verschwendet wurden. Hintergrund war, dass ich zunächst von schongeil.de auf www.schongeil.de und dann auf https://www.schongeil.de umgeleitet habe.

Wer sich fragt, warum ich SSL einsetze? Google bewertet Seiten mit eingerichtetem SSL besser und mit Let’s Encrypt ist es keine kostspielige Sache mehr, ein SSL-Zertifkat für beliebig viele Seiten einzusetzen. Nebenbei hat man vielleicht auch noch Bock drauf, dass eventuell erhobene Nutzerdaten verschlüsselt übertragen werden.

Meine Lösung sieht momentan so aus:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.schongeil.de/$1 [L,R=301]

Ob es die perfekte Lösung ist, weiß ich nicht. Die htaccess überfordert mich eigentlich immer. Aber diese Anpassung hat deutliche Verbesserung in der Ladezeit und bei Tests über u. a. tool.pingdom.com gebracht.
Was mir bei der Recherche dieser Anpassung über den Weg gelaufen ist, dass wohl oft der Fehler gemacht wird, und

RewriteCond %{HTTPS} on

in die htaccess gesetzt wird. Dies hatte ich anfänglich auch und kann ein Indiz für eine nicht optimale Einrichtung sein.

Nebenbei sei auch erwähnt, dass man beim Einsatz von iThemes Security die htaccess dann noch mal anfassen darf. iThemes Security setzt seine Anpassungen an den Anfang der htaccess-Datei, dies sorgt dann auch für etwas komische Umleitungen, wenn auch ein Cache-Plugin (s. u.) eingesetzt wird. Meine Lösung war das nach oben schieben des URL-Umleitung-Parts, sodass meine htaccess nun folgenen Aufbau hat:

  • URL-Umleitung (das Code-Snippet oben)
  • iThemes (alles was iThemes Security setzt)
  • WordPress Permalinks (was durch die Einstellungen im normalen WP-Backend gesetzt wird)

Dann klappt es auch mit dem Cache-Plugin!

2. PHP 7

Neu ist immer besser! Und im Fall von PHP 7 wirkt sich das auch etwas auf die Ladezeit aus. Zumal das gleich folgende Redis Cache auch PHP 7 voraussetzt, zumindest bei meinem Hoster uberspace. PHP 7 kann zumeist über die php.ini eingerichtet werden, wenn der Hoster dies grundsätzlich anbietet und unterstützt. Bei uberspace ist es recht simpel per Terminal umsetzbar:

echo PHPVERSION=7.0 > ~/etc/phpversion
killall php-cgi

Et voilà. Man merkt erst mal nicht viel, gehen wir wir weiter zum Cache.

3. Redis Object Cahe

Redis lässt sich bei uberspace natürlich auch einfach per Terminal aktivieren. Wie, sieht man hier. Danach hilft der Beitrag von Lukas, den ich 1:1 umgesetzt habe: https://leitsch.org/blog/wordpress-redis-cache-bei-uberspace-einrichten

4. Cache Plugins

Neben dem Redis-Cache  setze ich noch WP Fastest Cache ein. Ich hatte irgendwann mal einen Test gelesen, bei dem das Plugin am besten abschnitt. Zufälliger Weise kam ich dann irgendwann später auch noch auf das Plugin Fast Velocity Minify, welches mit Fastest Cache teilweise zusammen arbeitet. Dies zeigt sich u. a. daran, dass man beim Löschen des Fast Velocity Cache auch gleichzeitig den WP Fastest Cache löscht. Fast Velocity ist hilfreich bei der Reduzierung der Anfragen an den Server und ggf. bieten andere Plugins, wie W3C, einen vergleichbaren Ansatz, bei mir scheint diese Kombi bisher  am besten! Für dieses Blog habe ich tatsächlich die Pro-Version von Fastest Cache gekauft, glaube aber, dass man es nicht zwinegnd braucht.

Bei den Einstellungen (beider Plugins) muss man tatsächlich ein bisschen rumprobieren. Mal funktioniert Minify bei dem einen Theme, bei dem nächsten wieder nicht bzw. man muss dann vereinzelte JavaScript- oder CSS-Dateien von der Verarbeitung ausschließen.
Wenn Teile des Themes, wie z. B. ein Slider, nach der Aktivierung des Plugins bzw. der Optionen nicht mehr richtig angezeigt werden, kann man sich mit Pingdom ein bisschen orientieren, welche Datei es sei könnte. Da das Tool die geladenen CSS- und JavaScript-Dateien auflistet. Mir hat es bei der Identifizierung einiger Dateien geholfen, um diese dann auszuschließen und man muss auch nicht immer stoisch auf Google Page Speed oder Pingdom hören, wenn die sich über JS und CSS Dateien beschweren. Die vollständiger Minimierung bringt gerade bei WordPress eher Nachteile in der Ladezeit. Daher kann ruhig etwas weniger zusammengelegt werden, als es solche Tools verlangen. UX sollte immer im Fokus bleiben!

Was man aus meiner Sicht mindestens bei WP Fastest Cache aktivieren kann:

  • Preload
  • New Post
  • Update Post
  • Minify HTML
  • Minify CSS
  • Combine JS
  • Gzip

Und bei Fast Velocity Minfy ist Folgendes hilfreich:

WordPress Fast Velocity Minify

Die Option Preconnect Headers bietet sich für das optimierte Laden von Google Fonts an, aber auch, um sein Analytics-Tool der Wahl schneller parat zu haben. Piwik war es gerade in meinem Fall, welches die Ladezeit deutlich verlangsamt hat. Vorher habe ich allerdings meine Piwik-Installation etwas beschleunigen müssen, indem ich dort Gzip per htaccess aktiviert habe:

# rules for gzip-compression
<IfModule mod_deflate.c>
# html, txt, css, js, json, xml, htc:
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
<FilesMatch „\.(ttf|otf|eot|svg)$“ >
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

Stand heute (Version 3.0.4) wird Piwik nicht mit eigener htaccess (im root-Verzeichnis) installiert, diese setzt man dann mit dem Snippet selbst. Danach werden die Dateien piwik.js und piwik.php in etwa um 2/3 komprimiert übertragen.
Dann erst habe ich die beiden Dateien innerhalb des Headers hier zusätzlich vorgeladen. Im Header kann man auch den gerade gezeigten Preconnect vornehmen, das sieht dann so aus:

<!DOCTYPE html>
(…)
<head>
<link rel=“dns-prefetch“ href=“//analytics.schn.gl“>
<link rel=“preload“ href=“https://analytics.schn.gl/piwik.js“ onload=“embedTracker()“ type=“script“ crossorigin>
<link rel=“preload“ href=“https://analytics.schn.gl/piwik.php“ onload=“embedTracker()“ type=“script“ crossorigin>
(…)
</head>
(…)
<body>

Wer aufgepasst hat, sieht, dass beim prefetch kein http/https Attribut gesetzt ist. Die Dateien allerdings je eins haben. In dem Fall macht es Sinn, da der dort angesprochene Server beim Laden der Dateien sonst erst noch SSL aushandeln müsste, wertvolle Millisekunden! – Wenn man noch tiefer in die Optimierungs Piwik einsteigen will, ist man hiermit wahrscheinlich gut bedient.

5. WordPress Heartbeat / Admin Ajax

Java Scripts sind gefühlt das Schlimmste, um das man sich kümmern muss. So nützlich all diese Scripts sind, so lästig wird es, wenn es immer mehr werden. Das ist gerade mit einigen Plugins, einem vielleicht überladenem Theme, oder allein durch WordPress der Fall. Ich habe, wie so einiges anderes, durch Pingdom von der tollen admin-ajax.php erfahren, die gerne mal etwas lahmarschig ist. Das Script ist u. a. dafür zuständig, dass ein Artikel während des Schreibens automatisch gespeichert wird. Es gibt auch Plugins die sich dem bedienen. Mit Integration von admin-ajax.php in WordPress kam in etwa auch das Heartbeat Control Plugin, das sich um dieses Script kümmern kann. Die Anpassungen sind schnell gemacht. Meine Empfehlung sieht wie folgt aus:

Heartbeat Control WordPress Plugin

6. Bildgrößen anpassen

So viel Technik-Shizzle, dabei ist das offensichtlichste noch nicht behandelt worden. Der No-Brainer sind Bildgrößen! Wer ein 4260×3250 Bild im Blog hat, davon vielleicht gleich 12 in einem Artikel, darf sich nicht wundern, dass Nutzer während der Ladezeit aussteigen und die nächste Seite ansurfen. Die Aufbereitung der Vorschaubilder in akzeptablen Größen ist Pflicht. Klar, es soll gut aussehen, aber der Kompromiss muss zunächst UX berücksichtigen und dabei hilft u. a. tinypng.
Für diese Seite versuche ich keine Bilder einzusetzen, die ein Maß von ungefähr 1000 bis 1200 Pixeln überschreiten. Entsprechend in Photoshop komprimiert und vielleicht noch durch tinypng gejagt, ist sowohl UX, als auch Auge ausreichend berücksichtigt. Und mit…

7. Lazy Load

… kann man dann noch den letzten Rest aus der Ladezeit rausholen. Ich benutze Lazy Load XT bisher nur auf einer Seite und das auch nur, um einen Google Maps Ausschnitt erst dann zu laden, wenn der Bereich der Seite erreicht ist. Ansonsten bin ich mit solchen Plugins bisher noch nicht so warm geworden und versuche eher den Aufbau der Seite entsprechend anzupassen. Hier habe ich z. B. nur 6 Artikel auf der Einstiegsseite und somit auch nur 7 Bilder, inklusive Logo, die geladen werden.

Fazit

Warum der ganze Budenzauber? Allein aus meinem Nutzungsempfinden heraus ist es wichtig, dass Websites vorerst für die mobile Nutzung optimiert werden. Knapp 1 Sekunde am Desktop-Rechner können mobil noch mal ein paar mehr werden. Die Kontaktpunkte, gerade für Content-getriebene Seiten, werden immer häufiger mobil sein. In sofern ist die Ladezeit der Seite mindestens genau so wichtig wie der Content!

Für diese Seite hatte ich einige Zeit mit Facebooks Instant Articles experimentiert, da das Ladeverhalten derer dem Nutzer schon gefallen könnte. Die Dinger frusteten mich aber zu sehr, als das sich der Aufwand für nur einen Kanal lohnt. Daher sind Ambitionen, die eigene Seite generell schnell zu machen, weitaus besser, um kanalübergreifend allen Nutzern eine gute Performance zu bieten.

Abschließend sei noch mal angemerkt. Tools, wie Pingdom oder Google Page Speed, sollten nur zur Orientierung dienen, welche Dateien oder Umstände sich negativ auswirken. Bezogen auf die Ladezeit zeigt Pingdom mir z. B. mal unter einer Sekunde, dann doch auf ein mal 4 Sekunden an. Etwas mehr Gewissheit gibt es mit einer lokalen Messung, z. B. über ein Chrome-Plugin, wie Page load time.