WordPress Performance Mythen mit modernen Servern

Letztes Update 9. Juli 2020 – der Artikel wird regelmäßig aktualisiert.

Es gibt unzählige Artikel darüber, wie eine WordPress Installation beschleunigt werden kann. Die meisten der Tipps sind wertvoll und richtig. Oder waren es zumindest. Denn die gesamte Web-Technologie entwickelt sich weiter und damit verändern sich auch die sinnvollen Optimierungen.

Die Optimierungen von früher waren hauptsächlich folgende Punkte

  • Schnellen Server nutzen, damit die ersten Bytes der Homepage schnell gesendet werden (TTFB reduzieren)
  • Caching nutzen, das die (wiederholten) Abfragen im WordPress schnell ausgeliefert werden
  • Dateigrößen so weit es möglich reduzieren, das betrifft vor allem die Bilder, aber auch CSS, JS und HTML durch ein Minify
  • Möglichst wenige Requests erzeugen, weil die Requests Round-Trips erzeugen, die Zeit kosten
  • Damit möglichst viele Dateien in eine zusammenfügen (Header und Footer CSS und JS kombinieren) oder sogar Inlinen (in die HTML Datei direkt einfügen)
  • Dabei auf kritische Pfade und Abhängigkeiten achten, sodass das erste Zeichnen nicht verzögert wird, weil relevante Daten noch nicht da sind.
  • Statische Cookieless Domain nutzen, um die Übertragung von Cookies zu sparen.
  • Nutzung von CDN Diensten, um die Auslieferung der Daten weiter zu beschleunigen

Um das alles zu erreichen, habe ich in meiner WordPress Installation viel Aufwand getrieben. Ein gutes Cache-Plugin ist Pflicht (bei mir Cache Enabler, weil sehr reduziert und schnell) und natürlich ein CSS+JS Optimierer wie Autoptimize, Fast Velocity Minify. Oder Plugins, die das zusammen erledigen, wie WP Rocket. Diese hervorragenden Plugins leisten genau das, wofür sie gemacht sind. Und doch kommt es immer wieder zu Inkompatibilitäten oder Problemen, weil ein Template Builder etwas aktualisiert oder der Icon-Font doch nicht geladen wird oder der Cache nicht sauber aktualisiert und so weiter. Es war ständige Nacharbeit nötig und gerade bei Installationen, wo weniger erfahrene Anwender arbeiten immer wieder aufwendig und stressig.

Die neue Zeit mit HTTP/2

Mit dem neuen Protokoll HTTP/2 hat sich jedoch vieles geändert. Was früher mit HTTP 1.1 noch optimal war, ist jetzt ein Nachteil. Alle aktuellen Server und alle aktuellen Browser unterstützen HTTP/2 und es ist damit Zeit, neu zu denken.

Die alten Paradigmen betrachte ich im folgenden unter den Gesichtspunkt von HTTP/2 neu:

Das Verteilen der Anfragen auf mehrere Domain Namen (z. B. durch eine statische CDN Domain) ist nicht mehr sinnvoll. Früher waren dadurch mehrere gleichzeitige Verbindungen (TCP/IP-Requests) möglich, heute bringt die extra DNS Abfrage nur einen Zeitverlust. Auch Cookieless Domain ist nicht mehr relevant, da die Daten sowieso komprimiert werden und CDN-Anbieter wie Cloudflare auf jeder Domain Cookies setzen. Hier hießt es einfach: weglassen und alle Daten von einer Domain holen.

Der größte Unterschied kommt, weil wir komplett neu denken müssen: HTTP/2 ist optimiert darauf, viele kleine Dateien effizient zu transportieren. Genau das war bei HTTP 1.1 das Problem, welches wir mit dem Verbinden von CSS+JS Dateien versucht haben zu verringern. Das Zusammenfügen von CSS und Javascript-Dateien hat mit HTTP/2 fast nur noch Nachteile:

  • die übertragene HTML-Seite + einige wenige CSS+JS Dateien haben bis jetzt den gesamten Workload transportiert. Beim ersten Aufruf der Seite mag das noch geholfen haben, spätestens wenn jede weitere Seite immer alle statischen und über mehrere Seiten geteilten CSS + JS Dateien komplett neu lädt, ist jedes Caching nahezu ausgeschlossen. Meine Erfahrung ist, das bei WordPress und modernen Themes >90 % der CSS oder Javascript Dateien über alle Seiten hinweg identisch sind und nur einmal gezogen werden müssten und spätestens beim zweiten Aufruf einer Unterseite im Cache sind. Was sofort Downloadvolumen spart.
  • Die Dateien zu verbinden sorgt oft dafür, dass der Browser warten muss, bevor der monolithische Block von Dateien heruntergeladen und interpretiert ist, bevor er die Seite komplett rendern kann. Mit aufwendigen Critical Path Analysen usw. kann man das verhindern, doch ist es aufwendig und fehleranfällig.
  • Ein minimaler Vorteil ist, dass die Kompression von größeren Text-Dateien effektiver ist als viele kleinere Textdateien. Der Unterschied ist jedoch in der Praxis vernachlässigbar.

Mit HTTP/2 sparen wir uns das Verbinden der Dateien vollkommen und erreichen damit, dass

  • CSS und Javascript Dateien können mit effektiven Cache-Richtlinien versehen werden und sowohl im Browser als auch im CDN effektiv gecacht werden. Das spart sowohl Clientseitig als auch Serverseitig Ressourcen.
  • Durch die Priorisierung von Requests bekommt der Client die Vielzahl von Ressourcen in einer optimalen Reihenfolge ausgeliefert, so das die Seite schnell grundsätzlich dargestellt werden kann (Zeit bis zum ersten Paint oder Paint des Viewports). Diese Funktion ist möglich, wenn alle Ressourcen in wenige große Dateien gepackt werden. Gerade bei mobilen Endgeräten kann der Vorteil dramatisch sein: Wenig, aber wichtiges Datenvolumen wurde frühestmöglich übertragen und die Seite schon aufgebaut, während weitere Ressourcen wie Bilder erst im Hintergrund nachgeladen werden. Durch das HTTP/2 Multiplexing werden die vielen kleinen Dateien höchst effizient mit einem oder wenigen Requests übertragen.
  • Mit der Funktion des Server Push geht es noch einen Schritt weiter: Der Server schickt dem Client die wichtigsten Dateien, bevor diese überhaupt angefordert werden. Ziel ist auch hier die schnellstmögliche Darstellung einer (rudimentären) Seite, so das der Anwender die Seite frühestmöglich nutzen kann.

Was bedeutet das konkret für WordPress

Die gute Nachricht ist: Wir können uns ganz viel sparen. Die meistens Plugins für das Minimieren und Verbinden von CSS+JS können wir ersatzlos abschalten oder nutzen nur wenige der eher zusätzlichen Funktionen (wie das Abschalten der JS-Datei für die WordPress Emojis). Autoptimize und Fast Velocity Minify habe ich auf  diesem Server komplett gestrichen. Das reduziert die Komplexität einer WordPress-Installation deutlich. Für WP Rocket gibt es eine Anleitung, welche Funktionen ausgeschaltet werden sollten, wenn der Server HTTP/2 unterstützt.

In den Themes ist es jetzt optimal, wenn wir die Generierung von Inline CSS oder verbundenen Dateien abschalten. Das Theme WP Astra unterstützt ab Version 2.10 diese Option (Astra-Optionen, CSS File Generation anschalten).

Mit Divi heißt die Option „Reduzieren und kombinieren Sie Javascript-Dateien“ und „Reduzieren und kombinieren Sie CSS-Dateien“ unter Divi/Theme-Optionen. Auf einer normalen Installation werden etwa 8 Dateien mehr generiert, wenn diese beiden Optionen deaktiviert werden.

 

Welche Geschwindigkeit erreichen wir damit?

Die Schwierigkeit beim Messen der Geschwindigkeit ist, das uns die gängigen Test-Tools wie Pingdom, GTMetrix und Google Pagespeed Insights uns teilweise mit irreführenden Hinweisen glaubhaft machen wollen, das etwas nicht in Ordnung sei. Letztendlich kommt es wirklich nur auf die Ladezeit und weitere Parameter wie Time to First Byte (TTFB) an, denn das sind die relevanten Parameter, die das Kundenerlebnis beschreiben. Alle weiteren Empfehlungen sind im Detail zu prüfen, ob sie wirklich heute noch so sinnvoll sind.

Ein einfacher, aber überaus aussagekräftiger Speedtest ist der Cloudflare Page Performance Test. Er zeigt die effektive Ladezeit, Time to First Byte (TTFB) und die Anzahl der Requests an.

Um konkrete Zahlen zu nennen: Die Webseite https://oelverliebt.biz/blog habe ich mit verschiedenen Einstellungen getestet.

  • Alle Optimierungen mit Fast Velocity Minify aktiv, kein Cloudflare Caching/Optimierung
    5200ms Ladezeit, 1100ms TTFB, 55 Requests – davon je 5 x CSS + JS
  • Alle Optimierungen mit Fast Velocity Minify aktiv, Cloudflare mit Rocket, Minify aktiv
    3800ms Ladezeit, 730ms TTFB, 54 Requests
  • Fast Velocity Minify komplett ausgeschaltet, Cloudflare mit Rocket, Minify aktiv
    3100ms Ladezeit, 730ms TTFB, 64 Requests
  • Identisch wie letzter Punkt, jedoch mit den Cloudflare Professional Features
    2280ms Ladezeit, 350ms TTFB, 65 Requests, 300 KB weniger Datenvolumen (durch WebP Bilder)

Die Werte mit GTMetrix gemessen sind noch deutlicher: Alle Optimierungen mit Fast Velocity Minify aktiv liegt die Ladezeit bestenfalls bei 2,8 Sekunden. Ohne diese Optimierungen bei 1,0 Sekunden. Weitere deutliche Optimierungen wären möglich, wenn bei Cloudflare mindestens der Professional-Tarif genutzt wird. Das schaltet unter anderem Polish und die erweiterte HTTP/2 Priorisierung frei (Ladezeit jetzt 0,8 Sekunden). Der Ladezeitvorteil ist mit dem Aufruf der zweiten Seite nochmals deutlich größer, da nur noch HTML und evtl. weitere Bilder übertragen werden müssen.

Weitere WordPress Performance Tipps

  • Wer bei dem Hosting-Anbieter Domainfactory ist, kann sein Hosting durch einen Umstieg auf die 64 Bit Hosting-Platform deutlich verbessern. Dazu reicht ein Wechsel auf die Tarife „ManagedHosting 64“. Die Umstellung kostet einmalig knapp 10 €, alle anderen Gebühren bleiben gleich. Die neue Hosting-Platform ist deutlich schneller als die alte, insbesondere liegen jetzt die Werte für das erste Byte vom Server bei ca. 150ms im Vergleich zu den früheren 700ms, die ein Request immer mindestens gebraucht hat. Zu beachten ist: df.eu verwendet ein extrem aggressives Caching durch den NGINX Cache von 10(!) Minuten, scheinbar unabhängig der gesetzten HTTP Header (Thread im Support-Forum). Das ist für statischen Content hervorragend, aber für dynamische Arbeiten nicht brauchbar. Das Caching soll in Zukunft steuerbar sein.
  • Das Plugin Cache Enabler hat eine unbekanntere Funktion: Mittels Rewrite können gecachte Seiten komplett ohne Aufruf des WordPress PHP Codes ausgeliefert werden. Eine Anleitung dazu findet sich hier.
  • Mit Cloudflare kann man den HTTP/2 Server Push für WordPress aktivieren, wenn man das entsprechende Plugin mit einer passenden Konfiguration nutzt.

Weitere Artikel:

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen