„WordPress ist total lahm und lässt sich mit HTTPS nicht vernünftig nutzen und Apache mit PHP ist ja auch nicht mehr so optimal“ hat mir ein Bekannter neulich erzählt.
Ich war anderer Meinung und habe Lust bekommen, Performanceoptimierung zu betreiben, mit Software herumzuspielen und auszuprobieren ob die These stimmt – oder widerlegt werden kann.
Zu Anfang lag da noch ein alter Blog rum. Dieser hier. Oll, langsam, die Leserzahlen egal – ein idealer Kandidat für meinen Versuch.
Stylesheet aufräumen
Zunächst habe ich das Stylesheet aufgeräumt und viele schwere und unnütze Webfonts durch einen leichtgewichtigeren ersetzt. So kam ich von ~7MB, die in 12s auf etwa 6,1MB, die laut Webpagetest Performance Messtool in 11s geladen waren. 11s – eine halbe Ewigkeit. In der Auswertung sah ich, dass vor allem die Bilder auf der Webseite einen grossen Anteil (>50%!) am gesamten Seitenvolumen hatten.
Lazy Loading und Bilder komprimieren
Um dem entgegenzuwirken suchte ich eine Möglichkeit die Bilder im nicht sichtbaren Teil der Webseite erst zu Laden, wenn sie benötigt werden (oder kurz vorher). Also ein sogenanntes „Lazy Loading“ einzurichten. Hierfür gibt es ein passendes WordPress Plugin („Lazy Load“), mit dem der Job recht flott erledigt war. So werden beim Seitenaufruf erstmal nur die Thumbnails geladen, aber nicht mehr die kompletten Bilder.
Den Standardwert für die Bildkomprimierung habe ich ausserdem von 95% auf 80% gesenkt, ansonsten hätten viele Bilder doch zu sehr an Qualität eingebüsst. In einem Fotoblog darf man ruhig wenig komprimierte JPEGs zeigen, auch wenn diese Dateien dann etwas grösser ausfallen.
Diese Massnahmen haben die Ladezeit aber immerhin auf etwa 6s gedrückt und die Gesamtseitenkapazität auf etwa 700kB reduziert. Damit könnte man leben. Wenn da nicht diese 3s Time to first Byte in der Webpagetest Auswertung gewesen wären. In 3s laden moderne Webseiten inkl. Rendering im Browser. In 3s treffen Finanzalgorithmen Millardenentscheidungen in hunderten von Transaktionen. In 3s ändert sich die Welt.
Schneller!!!
Meine Vermutung war, dass eines der installierten Plugins dafür verantwortlich ist, dass es so lange dauert bis WordPress das erste Byte an den Browser ausliefert. Ich probierte also alle Plugins der Reihe nach durch (Messen, deaktivieren, messen…jeweils mehrere Zyklen) und identifizierte auf diese Art zwei Plugins die Zeit stehlen.
Interessanterweise kostete das W3 Total Cache Plugin fast 2s, obwohl es eigentlich zur Performanceverbesserung gedacht ist. Das veraltete Statistikplugin, dass im Hintergrund lief und Dinge tat, von denen ich keine Ahnung hatte und dabei alles bremste kostete nochmal etwa 1s.
Jetzt hatte ich also eine WordPress instanz, die etwa ein Zehntel der ursprünglichen Grösse hatte und in einem viertel der Zeit lädt. Blöderweise hatte ich dadurch den Cache und die Lesestatistik eingebüsst. Suboptimal. Ersteres bremste jetzt bei jedem weiteren Seitenaufruf und letzteres verhindert, dass ich sehe welche Artikel am meisten gelesen werden (schade, aber zu verschmerzen).
Johnny Cache alias Varnish.
Ich dachte über eine Architekturänderung nach. Bisher lief der Apache Webserver im Standalone Modus und machte alles alleine. Für das Caching habe ich spaßeshalber einen Varnish Cache davorgehängt – und siehe da: Die Ladezeiten beim zweiten Aufruf waren wieder da wo sie hin sollten: Im Keller. Ganz unten. Top!
Und dank neuem, passiven Statistikplugin sehe ich jetzt wieder die Seitenaufrufe, aber ohne störende Nebenwirkungen auf die Time-to-first-Byte (TTFB).
Und HTTPS?
SSL hätte ich ja auch gerne noch, dachte ich so. Vor allem im Hinblick auf die vielen Browserfeatures die in den Chromes, Firefoxes und Edges dieser Welt Stück für Stück nur noch per HTTPS zur Verfügung stehen bzw. stehen werden. Also flugs einen HA-Proxy als SSL Terminator vor den Varnish Cache geklemmt, ein LetsEncrypt SSL Zertifikat installiert – und erstmal nur Probleme gehabt: Redirect Loops, Security Warnungen wenn Seiteninhalte teilweise per HTTP geladen wurden, Browserfehler…Blöd.
Um die Warnungen vor gemischt geladenem Content zu verhindern habe ich das „SSL Insecure Content Fixer“ Plugin installiert und einige Plugins mit hartkodiertem Protokoll in den URLs (z.b. das Google Translate Plugin) per Hand angepasst. Die Redirect Loop Probleme waren eine Mischung aus fehlerhafter HA-Proxy, Varnish und WordPress Config gepaart mit einer WordPress Default URL die mit „http://“ begann.
Nachdem nun alle Probleme ausgemerzt sind läuft die Kiste. Genauer: das Blog ist flott geworden. Flotter als es jemals war.
In Zahlen: First Load: ~3,8s, 670kB. Second Load: 2,7s, 64kB.
Und das mit ein paar wenigen nicht so komplizierten Handgriffen. Die These meines Bekannten ist damit hinreichend widerlegt. Oder?
Auf jeden Fall war es ein Grund seit langer Zeit wieder einmal einen Artikel hier zu posten.