WordPress Performance

Die letzten Wochen habe ich mir etwas Zeit genommen, um mich um die Technik hinter diesem Blog zu kümmern. Das Blog läuft natürlich auf WordPress. Neben der allgemeinen Konfiguration, dem Theme und den Plugins habe ich dabei speziell die Performance betrachtet. Eigentlich war das keine Problemzone. Dieses Blog war schon immer relativ zackig unterwegs. Trotzdem gibt es immer etwas zu optimieren! Die Mühe hat sich in diesem Fall auch gelohnt und das Blog erhält nun 100 Punkte bei Google Page Speed. Ich möchte folgend aber keine Schritt-für-Schritt-Anleitung darüber verfassen, wie man 100 Punkte bei Google Page Speed erreicht. Jede WordPress-Seite ist individuell und erfordert spezifische Maßnahmen. Performance-Optimierung ist auch recht kompliziert und man kann über das Thema ganze Bücher verfassen. Nachstehend möchte ich deswegen mehr einen groben Überblick geben und ein paar prinzipielle Gedanken zum Thema WordPress Performance aufschreiben.

100 Punkte bei Google Page Speed

Generelle Überlegungen

Wenn ein Besucher eine Internetseite aufruft, bestimmen im Wesentlichen drei Faktoren, wie schnell die Internetseite angezeigt wird.

  1. Die Geschwindigkeit des Servers
  2. Die Geschwindigkeit der Leitung
  3. Die Geschwindigkeit des Browsers

Wenn man sich diese Faktoren näher anschaut, dann stellt man fest, dass man keinen dieser Faktoren direkt beeinflussen kann. Zwar können wir die Geschwindigkeit des Servers indirekt über den gewählten Hosting-Tarif steigern, aber im privaten Umfeld sind dezidierte Hochleistungsserver kaum finanzierbar. Die Geschwindigkeit der Übertragungsleitung hängt vorrangig davon ab, über welches Medium sich der Besucher ins Internet einloggt. Unterwegs mit dem Smartphone beispielsweise über ein schnelles UMTS- oder langsames 3G-Netz. Natürlich gibt es auch noch den Übertragungsweg im Internet zwischen den einzelnen Routern, Internetknoten und Backbones sowie die Anbindung des Rechenzentrums, in dem die Internetseite gehostet wird. Aber der Flaschenhals ist meistens die Leitung des Nutzers. Und die Geschwindigkeit des Browsers können wir ebenso wenig beeinflussen. Zwischen den großen Namen wie Chrome, Safari, Edge und Firefox gibt es hier tatsächlich spürbare Unterschiede. Stünden diese drei Faktoren in unendlichem Umfang zur Verfügung, müsste man theoretisch gar keine Performance Optimierung betreiben.

Die drei wesentlichen Faktoren der WordPress Performance (Browser, Leitung, Server)

Das bedeutet, wenn man nun die Geschwindigkeit der eigenen Seite verbessern möchte, gilt es Maßnahmen zu treffen, welche sich implizit positiv auf die Datenübertragung, die Antwortzeit des Servers und die Verarbeitungsgeschwindigkeit im Browser auswirken. Man muss also Wege zu finden, um die Internetseite schneller zu generieren, zu transportieren und anzuzeigen.

Hosting

Wenn ein Besucher eine Adresse in den Browser eintippt, schickt der Browser eine Anfrage (einen HTTP-Request) an den entsprechenden Server und wartet danach auf Antwort. Wie schnell der Server antwortet, hängt vorrangig davon ab, wie leistungsfähig er ist. Die Leistung eines Computers wird von vielen unterschiedlichen Faktoren determiniert. Primäre Einflussfaktoren sind aber die Schnelligkeit des Prozessors, die Größe des Arbeitsspeichers sowie die Geschwindigkeit des Speichersystems. Diese Parameter können wir letztendlich nur über unseren Geldbeutel beeinflussen. Sofern man keinen dezidierten Server betreibt, wird der Server in der Regel mit anderen Kunden geteilt. Je preiswerter der Tarif, umso mehr Kunden teilen sich einen Server. Die Anzahl der Kunden gibt jedoch auch nur Hinweise aber keine Sicherheit darüber, wieviel Rechenkraft der eigenen WordPress zur Verfügung steht. Das liegt daran, dass man nicht sagen kann, wie rechenintensiv die Webapplikationen der anderen Kunden sind und wie viele Besucher sie haben.

Anzahl Kunden beim Shared Hosting

Plugins

Im Kontext des Servers kann man also nur indirekt an der eigenen Internetseite ansetzen und dafür sorgen, dass der Server so wenig Zeit wie möglich braucht, um die Internetseite durchzurechnen und an den Browser zu schicken. Im Wesentlichen bedeutet dies, das WordPress im Backend schlank zu halten und so wenige Plugins wie möglich einzusetzen. Jedes Plugin fügt WordPress weiteren Code hinzu, der bei jedem Seitenaufruf vom PHP-Interpreter eingelesen und verarbeitet werden muss. Auch die Menge der Datenbankabfragen und die Anzahl der HTTP-Requests steigt mit jedem weiteren Plugin.

Lines of Code

Eine Empfehlung über die optimale Anzahl von Plugins möchte ich an dieser Stelle nicht aussprechen. Im Netz liest man oft, man sollte nicht mehr als 10 Plugins einsetzen. Aus meiner Sicht macht es keinen Sinn, sich hier eine künstliche Grenze zu setzen. Wenn man eine Funktionalität benötigt, dann sollte man darauf auch nicht verzichten. Schließlich hat man sich das WordPress zugelegt, um die Welt zu gestalten und nicht, um sich erneut in seinen Möglichkeiten zu limitieren. Deswegen gilt das unscharfe Paradigma, sich auf das Wesentliche konzentrieren und nur solche Plugins zu installieren, die man auch wirklich braucht. Lieber kleine Plugins wählen und deren Funktionalität vollständig nutzen, anstatt große Plugins einzusetzen, dessen meiste Funktionen man gar nicht benötigt. Im Widerspruch dazu können oftmals mehrere kleinere Plugins durch ein größeres Plugin ersetzt werden. In vielen Fällen ist auch ein simples Code-Snippet in der functions.php die bessere Wahl. Es gilt die richtige Mitte zu finden. Obwohl dieses Blog sehr minimalistisch daher kommt, arbeiten hier übrigens im Hintergrund tatsächlich 17 Plugins.

Datenmenge

Man kann zwar auf die Größe und Geschwindigkeit der Übertragungsleitung nicht einwirken, aber man kann die Datenmenge beeinflussen, welche über die Leitung geschickt werden muss. Es ist ein gehöriger Unterschied, ob zur Darstellung einer Internetseite 2 oder 10 Megabyte übertragen werden müssen. Die Datenmenge wird von vielen verschiedenen Faktoren bestimmt. Hier empfiehlt es sich, das eigene WordPress mit Hilfe von Messdiensten wie Pingdom kritisch analysieren, um die dicken Brocken zu identifizieren. Dabei erlebt man oft eine Überraschung. Mir persönlich war zum Beispiel bislang nicht klar, wieviel Raum JavaScript für sich einnimmt. Die Startseite von unmus bringt übrigens 440 KB auf die Waage (sie würde also noch auf eine Diskette passen).

Das Gewicht einer Internetseite

Theme

Je leichtgewichtiger das Theme, umso besser. Leider kann man die Leichtgewichtigkeit von außen kaum feststellen. Allein Experten und Programmierer sind in der Lage, sich hier ein richtiges Bild zu machen. Deswegen möchte ich auf diesen Punkt auch nicht weiter eingehen. Eine Sache ist aber interessant: Überraschenderweise ist ein Responsive Theme strenggenommen eigentlich nachteilig für die Geschwindigkeit, was sehr interessant ist. Das Layout eines Themes wird bekanntlich in der Datei style.css gespeichert. Diese Datei enthält jeweils alle Formatvorlagen (Stylesheets) für Smartphones, Tablets und Desktops. Jedes Endgerät lädt beim Aufruf einer Internetseite die komplette Datei style.css und verwendet dann jedoch nur diejenigen Stylesheets, welche für das Endgerät gedacht sind. Damit werden also recht viele Daten unnötig übertragen und vom Endgerät letztlich nur weggeschmissen.

CSS @ Responsive Design

Bilder

In der Regel sind die Bilder für den meisten Traffic verantwortlich. Das liegt am Dateityp. Ein Bild erfordert einfach mehr Speicherplatz als ein Text. Deswegen muss man ihnen besondere Aufmerksamkeit schenken. Auch hier in diesem Blog sind die Bilder im Schnitt für 60 % des Gewichts verantwortlich.

Image Traffic

Bild-Kompression

Um Bilder schnell auszuliefern, sollte man sie bestmöglich komprimieren. Die Kompression kann man sich gedanklich vereinfacht wie Tetris vorstellen. Sie stapelt einfach die Bits durch schlaue Mechanismen in einer Weise, dass kein Platz verschwendet wird. Es gibt Kompressionsalgorithmen, welche die Qualität eines Bildes nicht beeinflussen, und solche mit Qualitätsverlust. Dabei gilt, je höher die Kompression, umso schlechter das Bild. Ein leichter Qualitätsverlust fällt kaum ins Auge, wogegen eine hohe Kompression die Bilder in der Regel unscharf wirken lässt. Es gilt hier die richtige Mitte zu finden. Man kann die Optimierung lokal auf dem Rechner mit Programmen wie Photoshop oder ImageOptim durchführen oder durch Plugins wie Optimus, ShortPixel oder Imagify direkt in WordPress erledigen lassen.

Bildoptimierung

WordPress Einstellungen

Die Kompression ist jedoch nur die halbe Miete und man sollte auch die richtige Bildversion in die Beiträge und Seiten einbauen. WordPress erstellt nach dem Upload verschiedene Größen eines hochgeladenen Bildes (z.B. klein, mittel, groß). Wenn man nun ein Bild einfügt, sollte man darauf achten, dass die Bildgröße zumindest ungefähr der Größe der Anzeigefläche entspricht. Ausschlaggebend ist die Breite. Wenn der Seitenbereich für Beiträge im WordPress Theme nur 700 Pixel breit ist, sollte man auch ein Bild mit 700 Pixel Breite in den Text einfügen und nicht die Originalversion, die vielleicht 2400 Pixel Breite hat. Die Größen der Bilder, welche WordPress nach dem Upload anlegt, kann man in WordPress unter den Medien-Einstellungen definieren und idealerweise sollten diese Werte jeweils auf das Theme angepasst werden. Beim einem Wechsel des Themes lassen sich übrigens alte Bilder mit Plugins wie Regenerate Thumbnails auf die neuen Werte berechnen.

WordPress Einstellungen Medien

Dateiformat

Auch das Dateiformat hat einen wesentlichen Einfluss auf die zu übertragende Datenmenge. Die beliebtesten Formate im Internet sind JPG, PNG und GIF. Abhängig vom Motiv sollte man das dafür passende Format wählen. Die Unterschiede zwischen den einzelnen Formaten betragen gerne mal mehrere hundert Kilobyte für gleiche Bild. JPG ist besonders für echte Fotos geeignet, während GIF bei Illustrationen mit wenigen Farben seine Stärken ausspielt. PNG versucht dagegen, die Vorteile von JPG und GIF in einem Format zu vereinen. Um das richtige Format für ein Bild zu finden, experimentiert man Besten in der Bildbearbeitung. Auch die Meta-Daten der Bilder kosten übrigens Speicherplatz (also Performance) und können entfernt werden. Wobei dies aus semantischer Perspektive nachteilig ist, weil es die Lesbarkeit für Maschinen erschwert.

Bildformate

GZIP Komprimierung

Nicht nur Bilder können komprimiert werden, sondern auch viele andere Datentypen, welche über die Leitung vom Server zum Browser geschickt werden. Man kann sich das gedanklich so vorstellen als wenn eine ZIP-Datei übertragen würde. Die Komprimierung des Datenverkehrs muss serverseitig aktiviert werden. Bei Apache erfolgt die Komprimierung über das Modul mod_deflate. In den vielen Fällen ist die Kompression vom Hosting-Provider auch schon voreingestellt. Falls nicht, kann man die Kompression in der Regel über Direktiven in der Datei .htaccess auf dem Webspace manuell aktivieren.

GZIP Kompression

Caching

Caching bedeutet, dass bestimmte Inhalte irgendwo auf dem Weg zwischen Besucher und WordPress zwischengespeichert werden, damit sie schneller angezeigt werden können. Es gibt zwei Arten von Caching. Lokales Caching im Brower und WordPress-seitiges Caching.

Browser-Caching

Um eine Internetseite im Browser darzustellen, muss der Browser zuvor alle Elemente der Internetseite (HTML, Bilder, CSS) auf das Endgerät kopieren. Diese Elemente werden bei jedem Abruf der Internetseite neu vom Server geladen. Genau hier setzt das Browser-Caching an, indem der Browser die geladenen Elemente nicht wegwirft, sondern sich die Dateien für den nächsten Besuch vorhält. Beim nächsten Besuch müssen die Daten also nicht erneut vom Server geladen werden, sondern werden einfach aus dem lokalen Browser Cache genommen. Eigentlich muss man hier gar nichts tun, weil der Browser mehr oder weniger das Caching automatisch durchführt. Über die Datei .htaccess kann man dem Browser jedoch noch zusätzlich ein „Haltbarkeitsdatum“ für die Elemente mitgeben.

Browser Caching

Wichtig für das Verständnis: Der Geschwindigkeitsvorteil entsteht also erst beim zweiten Besuch eines Besuchers. Andere Besucher erlangen durch das Browser-Caching keinen Geschwindigkeitsvorteil.

WordPress Caching

Im Kontrast dazu kommt WordPress-seitiges Caching allen Besuchern zu Gute. Wenn man eine WordPress-Seite aufruft, passiert im Prinzip folgendes: Der Code von WordPress wird vom PHP-Interpreter eingelesen und verarbeitet (man könnte auch sagen, WordPress wird gebootet), WordPress führt viele Datenbankabfragen werden durch und am Ende baut WordPress die Internetseite zusammen und übergibt sie dem Webserver zur Auslieferung. Das ist alles recht zeitaufwändig. Genau hier setzt das WordPress-seitige Caching an. Die fertige HTML-Seite wird dabei nach dem Abruf zusätzlich als Datei auf dem Dateisystem des Servers abgelegt. Ruft nun der nächste Besucher die gleiche Seite auf, muss der zuvor dargestellte Prozess nicht mehr vollständig durchlaufen werden und WordPress nimmt einfach die fertige Seite vom Dateisystem.

WordPress Caching

Im Detail ist Caching ein hochkomplexer Vorgang bei dem es viele Feinheiten zu beachten gibt. Die Konfiguration eines Caching-Plugins ist äußerst anspruchsvoll. Die Mühe lohnt sich aber, denn Caching kann WordPress wirklich zur einer Rakete machen. Die bekanntesten Caching Plugins für WordPress sind W3 Total Cache, WP Super Cache und WP Rocket.

Minifizierung

Die Minifizierung ist ein Prozess, der auf HTML, CSS und JavaScript angewendet wird und die Zielstellung verfolgt, die zu übermittelnde Dateimenge so gering wie möglich zu halten. HTML, CSS und JavaScript Dateien enthalten normalerweise viele Leerzeichen, Kommentare und Steuerzeichen (ein Zeilenumbruch ist beispielsweise ein Steuerzeichen). All diese Zeichen sind für den Browser eigentlich irrelevant. Der Browser rendert eine Internetseite auf Basis des HTML-Markups. Steuerzeichen wie Zeilenumbrüche oder doppelte Leerzeichen beachtet er gar nicht. Bei der Minifizierung werden nun diese „unnötigen“ Zeichen von WordPress vor der Übermittlung an den Browser entfernt und damit werden in der Regel ein paar weitere Kilobyte für die Übertragung gespart. Technisch realisieren kann man das relativ einfach über entsprechende Plugins.

HTML Minification

Zusammenfassung

Die Zusammenfassung zielt auf den Sachverhalt, dass die Übermittlung einer gegebenen Datenmenge über eine einzelne Datei schneller zu bewerkstelligen ist als über mehrere Dateien. Das hängt damit zusammen, dass jede Datei einen gewissen Overhead in der Kommunikation und Verarbeitung erzeugt. Die Zusammenfassung wird hauptsächlich auf CSS und JavaScript-Dateien angewendet. Eigentlich hat ein WordPress Theme nur eine einzige style.css Datei, aber in der Regel binden Plugins weitere Stylesheets in den HTML-Seitenkopf ein. Die Zusammenfassung geht nun hin und konsolidiert all diese Dateien in einer Datei und ermöglicht damit eine schnellere Übertragung. Auch dies kann man über entsprechende Plugins realisieren.

Zusammenfassung

Rendering

Jetzt wird’s langsam kompliziert! Aber bevor es weitergeht, muss man den Prozess im Browser besser verstehen. Was passiert also genau und in welcher Reihenfolge, wenn man mit dem Browser eine Internetseite aufruft? Der Browser sendet zuerst einen HTTP-Request an eine URL. Jetzt geschieht erst einmal allerlei komplizierter Netzwerkkram, der hier ausgeblendet werden soll. Der Webserver nimmt letztlich die Anfrage entgegen, generiert die entsprechende Internetseite und schickt sie an den Browser zurück. Und zwar nur die HTML-Datei, ohne Bilder, style.css, JavaScript oder anderen eingebetteten Medien. Der Browser liest nun die Datei ein und beginnt das HTML zu parsen. Parsen bedeutet, die Daten in eine für den Browser verständliche Semantik zu übersetzen. Sobald der Browser beim Parsen auf ein referenziertes Element trifft (ein Bild, eine CSS- oder eine JavaScript-Datei), wird dieses Element wiederum über einen weiteren HTTP-Request vom Webserver nachgeladen. Welche Elemente in welcher Reihenfolge geladen werden, wird also durch die Stelle im HTML-Quellcode determiniert. Während dieses Prozesses sieht der User im Browser eine weiße Seite.

White Page

Erst wenn der Browser alle referenzierten Elemente abgerufen hat, beginnt er damit intern die berühmten DOM- und CSDOM-Modelle zu erstellen. Sobald dies erledigt ist, kann der Browser die Internetseite rendern und dem User präsentieren. In diesen Prozess kann man nun eingreifen und den Browser derart beeinflussen, damit er sofort mit der Anzeige der Internetseite beginnt, obwohl er noch gar nicht alle dafür benötigen Elemente geladen hat.

Asynchrones Laden

Das Rendering im Browser ist prinzipiell auf Synchronität ausgelegt. In diesem Kontext bedeutet Synchronität, der Browser bearbeitet alles nacheinander. Wenn er beim Parsen des HTML-Code auf referenzierte Datei trifft, dann lädt er erst diese Datei, bevor er mit dem Parsen weitermacht. An dieser Stelle setzt das asynchrone Laden an, welches sich vor allem für CSS-Dateien eignet. Durch verschiedene Maßnahmen kann man dem Browser sagen, dass er das Parsen fortsetzen soll und die referenzierte Datei parallel im Hintergrund laden. In der Regel wird damit das Parsing und das darauffolgende Rendering schneller durchlaufen. Dieser Sachverhalt führt jedoch auch dazu, dass der Browser die Internetseite oft schon anzeigt, obwohl er die erforderlichen Stylesheets noch gar nicht vollständig geladen oder verarbeitet hat. Diese werden dann nachträglich in der Anzeige ergänzt.

unmus ohne CSS

Zwar lädt die Internetseite nun ruckizucki, aber optisch führt dies zu seltsamen Effekten. Der Browser zeigt dem User nämlich das raue HTML an und eine gefühlte Minisekunde später wird die Anzeige mit den Stylesheets aufgefrischt und alles sieht genauso aus, wie es aussehen soll. Diesem unschönen Effekt kann man mit dem Critical Path CSS entgegen treten.

Critical Path CSS

Above the Fold bezeichnet den oberen Bildschirmausschnitt einer Internetseite, den man im Browser ohne zu scrollen sieht. Das nötige CSS, um diesen ersten Bildschirmausschnitt darzustellen, nennt man Critical Path CSS. Die Zielstellung besteht nun darin, dieses kritische CSS direkt in den HTML-Seitenkopf zu packen, damit der Browser vom Fleck weg alles hat, um den Above the Fold Abschnitt in finaler Formatierung anzuzeigen. Diese Maßnahme der Performance Optimierung ist von allen Aspekten am Schwierigsten umzusetzen. Nun, wie macht man das?

Above the Fold

Die Schwierigkeit in der Umsetzung liegt primär darin, die Above-the-fold-relevanten CSS-Befehle in der style.css zu identifizieren. Man muss nämlich herausfinden, welche CSS-Befehle für die Anzeige im Above the Fold benötigt werden, und welche nicht. Hierfür gibt es zwar verschiedene Web-Tools, die aber nur so mittel funktionieren. Erschwerend kommt hinzu, dass die relevanten Stylesheets nicht auf allen Seiten die Gleichen sind. Beispielsweise benötigen die WordPress-Beiträge meist ein anderes CSS als die WordPress-Seiten. Letztlich kommt man nicht umhin, die Datei styles.css sowie die dazugehörigen HTML-Templates des WordPress-Themes Schritt für Schritt händisch zu analysieren. Hierfür benötigt man auch recht fundiertes Wissen über HTML und CSS. Der Aufwand mag im ersten Moment auch erschrecken, aber eigentlich ist die Aufgabe an einem Nachmittag machbar zu erledigen. Um das Critical Path CSS am Ende in den HTML-Seitenkopf zu packen, kann man wieder ein Plugin verwenden (oder man erstellt ein kleines Snippet).

Damit ist der Browser nun in der Lage den Above-the-Fold-Abschnitt quasi sofort und unmittelbar dem User in seiner ganzen Schönheit zu präsentieren. Im Hintergrund ist der Browser weiterhin damit beschäftigt, den Rest der Seite zu rendern. Bis der User jedoch die Seite kognitiv erfasst, sich orientiert hat und bereit weiter zu scrollen, hat der Browser meistens die Seite vollständig gerendert. Witzigerweise wird durch diese Maßnahme die absolute Gesamtmenge der zu übertragenden Daten erhöht, weil das Critical Path CSS eigentlich doppelt geladen wird. Einmal im HTML-Header und einmal mit der Datei style.css. Das macht aber nichts, weil die style.css durch die zuvor beschriebene Asynchronität im Hintergrund geladen wird.

JavaScript verzögern

Eine WordPress-Seite bestehen nicht nur aus HTML, sondern auch aus JavaScript. Tatsächlich ist es sogar so, dass der Anteil der JavaScript-Dateien den Anteil des eigentlichen HTMLs oft übersteigt. Beispielsweise werden auf der Startseite dieses Blog rund 90 KB JavaScript geladen, aber nur 20 KB HTML. Dabei ist zu beachten, dass JavaScript nicht auf dem Server, sondern im Browser ausgeführt wird. Normalerweise befindet sich der JavaScript-Code im HTML-Header. Das bedeutet, der Code wird ausgeführt, noch bevor der Browser die Seite darstellt. Nun gibt es JavaScript-Dateien, die sind zur Anzeige der Seite erforderlich und dessen Funktionalität muss sofort zur Verfügung stehen. Dazu gehören beispielsweise JavaScripts, welche für die Klapp-Navigationen auf den mobilen Versionen der Internetseiten benötigt werden. Es gibt aber auch JavaScripts, welche für die Darstellung im Browser irrelevant sind (beispielsweise der Besucherzähler). Diese nicht-kritischen JavaScripts können vom Browser auch später geladen werden.

Kritisches Java und nicht so wichtiges Java

Hierfür gibt es zwei Möglichkeiten. Die erste Möglichkeit ist, das betroffene JavaScript in den HTML-Footer zu verschieben. Damit wird das betroffene JavaScript erst am Seitenende geladen. Die zweite Möglichkeit besteht darin, die JavaScripts zu verzögern. Verzögern bedeutet, dass der Browser das entsprechende Script erst ausführt, wenn die Seite fertig gerendert ist. Die Verzögerung wird im Quellcode recht einfach erwirkt, indem man dem JavaScript HTML-Markup das Attribut defer hinzufügt. Bei WordPress muss man das natürlich wieder über ein Plugin regeln.

Externe Quellen

Mittlerweile ist es üblich, Inhalte im Blog einzubetten, die von externen Quellen stammen. Das beginnt mit einem YouTube-Video in einem Beitrag und endet mit der Tweet-Timeline auf der Sidebar. Diese externen Daten werden über JavaScript vom Browser nachgeladen und kosten natürlich wieder Geschwindigkeit. Aus diesem Grund sollte man sich gerade bei den eingebetteten Inhalten auf das nötigste beschränken. Die Optimierung dieser Quellen ist besonders schwierig, weil man die Datenquellen nicht kontrolliert. Beispielsweise kann man nicht dafür sorgen, dass die Inhalte komprimiert oder Browser-seitig gecacht werden. Man sollte aber jede Einbettung individuell betrachten, weil man hier nichts pauschalisieren kann. Ein interessantes Beispiel sind die Google Fonts.

Externe Quellen

Google Fonts

Beim Einsatz von Google Fonts werden beim Rendern der Internetseite die nötigen CSS-Befehle sowie die Schriftdateien dynamisch vom Browser von den Google Servern geladen. Das kostet natürlich wieder Zeit. Nicht ohne Grund verwendet das WordPress Backend seit Kurzem keine Google Fonts mehr, sondern lokale Systemschriften. Auch dieses Blog nutzt Google Fonts. Im Rahmen dieser Performance-Evaluierung habe ich nun das Theme dahingehend modifiziert, dass die Schriftdateien vom eigenen Webspace anstatt vom Google Server geladen werden. Danach habe ich überraschend festgestellt, dass ich mit dieser Maßnahme die Performance dieses Blogs reduziert habe. Einerseits ist Datenmenge eines Seitenabrufs um rund 150 Kilobyte gewachsen. Andererseits hat der Abruf der Schriftdateien laut Messung spürbar länger gedauert.

Google Fonts

Den Anstieg der Datengröße kann ich mir nur so erklären, dass Google nur diejenigen Styles ausliefert, welche der anfragende Browser (z.B. Safari 10) benötigt. Über den lokalen Webspace werden (ohne größeren technischen Aufwand zu betreiben) leider alle Styles pauschal für alle Browser ausgeliefert. Und der längere Abruf bedingt sich vorrangig daraus, dass Google natürlich wahnsinnig schnelle Server hat. Da kann meine Shared Hosting Umgebung logischerweise nicht mithalten. Aus diesem Grund habe ich das zurückgebaut und die Fonts werden nun wieder von Google geladen.

HTTP Requests

Tatsächlich ist es so, dass es aus Performance-Sicht (fast) egal ist, ob eine Datei vom eigenen Server oder von externen Quellen geladen wird. Der Abruf einer Resource wird vom Browser initiiert. Technisch gibt es zwischen lokalen oder externen Quellen keinen Unterschied. Es ist sogar so, dass die externen Quellen in der Regel viel, viel schneller ihre Inhalte ausliefern als die eigene Hosting-Umgebung. Facebook, Google, Twitter betreiben eine verteilte Hochleistungsinfrastruktur, die weit über die Möglichkeiten im privaten Kontext hinaus geht. Im Kontext der Performance Optimierung sollte der Fokus also nicht darauf liegen, externe Quellen zu vermeiden, sondern die Anzahl der HTTP-Requests zu vermeiden (jede Datei führt zu einem HTTP-Request). Und das gilt für das eigene WordPress gleichermaßen. Jeder weitere HTTP-Request, den der Browser auslösen muss, um eventuell ein weiteres Stylesheet eines Plugins zu laden, kostet Zeit. Für einen gewöhnlichen Beitrag im Zimtwolke-Format hier im Blog muss der Browser in der Regel 14 HTTP-Requests absenden.

HTTP Requests

Messung

Durch den Einsatz von Google Fonts erhalte ich nicht mehr die volle Punktzahl bei Pingdom. Problem ist hierbei nicht die externe Quelle an sich, sondern der Sachverhalt, dass Google die CSS-Datei ohne „Ablaufdatum“ für den Browser-Cache ausliefert. Integriere ich die Google Fonts lokal erhalte ich 100 Punkte, verlangsame aber meine Internetseite. Dieses Beispiel zeigt, dass bei solchen Performance Messungen weniger die absolute Geschwindigkeit einer Internetseite gemessen wird, sondern vielmehr die technischen Maßnahmen geprüft werden, die man implementiert hat, um die Seite performanter zu machen. Ob damit eine Seite auch schneller wird, steht auf einem anderen Blatt. Aus meiner Sicht heraus, ist dieser Ansatz eigentlich auch gar nicht so verkehrt. Das Resultat der Messung gibt also vorwiegend Hinweise darauf, ob man die Ladezeit der eigenen Seite noch verkürzen könnte. Weiterhin solle man auch nicht den Fehler machen und immer nur die Startseite auf Geschwindigkeit zu optimieren. Viel wichtiger sind eigentlich die Unterseiten. Dort findet man viele Überraschungen. Vor allem Single Post Seiten, Archive, CPT und Pages sollte man sich anschauen. Die bekanntesten Messstationen sind Google Page Speed, Pingdom und GTmetrix.

Pingdom Results

Sonstiges

Neben den bisher beschriebenen Aspekten gibt es noch viele weitere Maßnahmen, die man zur Steigerung der Performance implementieren kann. Beispielsweise Lazy Load. Lazy Load bezieht sich auf Bilder und Videos. Damit werden Bilder im Blog dynamisch nachgeladen, wenn der User nach unten scrollt und das Bild in das Sichtfenster gelangt. Auf diesem Blog würde Lazy Load die Dateimenge noch mal um weitere 50 % senken. Nachteil ist, dass hierfür weitere Anwendungslogik (JavaScript) erforderlich ist, welche das Rendering im Browser hinauszögern. In absoluten Zahlen erhöht sich auch die Datenmenge der Webseite (aber nur wenn der User auch ganz nach unten scrollt).

Das Internet macht unendlich viele Vorschläge, wie man die WordPress Performance immer weiter steigern kann. Beispielsweise soll man auch die Datenbank regelmäßig aufräumen (z.B. Revisionen entfernen). Dagegen will ich nichts sagen, schließlich ist Ordnung nie verkehrt. Aber einen Geschwindigkeitsvorteil wird man damit nicht unbedingt spüren, dazu sind die Datenbanken viel zu schnell (es sei denn, man hätte nach 10 Jahren erstmals aufgeräumt).

Ein CDN wird auch gerne empfohlen. CDN bedeutet Content-Delivery-Network. Ein solches Netzwerk spiegelt die Inhalte des Blogs und hilft quasi bei der Auslieferung. Aus meiner Sicht lohnt sich das aber erst so richtig, wenn man in der ersten Liga angekommen ist und täglich tausende von Besuchern bewältigen muss. Weiterhin könnte ein CDN sinnvoll sein, wenn man viele Besucher von anderen Kontinenten hat. Dieses Blog wird im Schnitt in einer halben Sekunde an den Besucher ausgeliefert. Aber nur, wenn der Aufruf aus Europa erfolgt. In Australien muss man tatsächlich 3 bis 4 Sekunden warten, bis die Startseite im Browser erscheint.

Übrigens, die Verschlüsselung via https wirkt sich zwar positiv auf das Google Ranking aus, aus Geschwindigkeitssicht ist die Verschlüsselung aber eher nachteilig. Das liegt daran, dass der Datenverkehr zwischen Browser und Server fortlaufend verschlüsselt und wieder entschlüsselt werden muss. Es soll jetzt aber niemand auf die Idee kommen, die Verschlüsselung wieder zu deaktivieren. Verschlüsselung sticht Performance!

Abschließend ist noch erwähnenswert, dass man automatische Wartungsarbeiten wie beispielsweise Backup-Erstellung oder Sicherheits-Scans immer für die Nacht einplanen sollte. Diese Routine-Arbeiten sind sehr performance-intensiv, zulasten der Besucher, die sich zeitgleich auf dem Blog herumtreiben. Es ist zwar überall irgendwo gerade Nacht, aber ich meine damit die Nacht derjenigen Zeitzone, wo die meisten Besucher sitzen.

Um die oben dargestellten Aspekte vollständig umzusetzen, benötigt man nicht für jedes Thema ein eigenes Plugin. Die großen Performance- und Caching-Plugins decken weitgehend all die nötige Funktionalität ab. Und einige Arbeiten müssen auch nur einmalig per Hand durchgeführt werden. Bei jeder Änderung ist es aber zwingend notwendig, die eigene Internetseite ausgiebig zu testen. Besonders Minifizierung, Zusammenfassung und asynchrones/verzögertes Laden machen gerne etwas kaputt und erfordern eine Feinkonfiguration oder Ausschluss bestimmter Dateien. Der Teufel steckt hier wirklich im Detail.

Der Teufel steckt im Detail

Schlussbetrachtung

Performance Optimierung ist ein sehr komplexes Thema, welches sehr schnell in technischen Details endet. Man darf nicht abnehmen, dass man dafür einfach so ein Plugin installiert und das war’s dann. Man muss vieles ausprobieren und mit den Einstellungen experimentieren. Wenn man sich länger mit dem Thema beschäftigt, kann das durchaus auch süchtig machen. Höher, schneller, weiter! Da muss man aufpassen, dass man die Kirche im Dorf lässt. Schließlich sollte der Fokus immer noch darauf liegen, die Mission zu erfüllen (Inhalte zu publizieren). Denn die Performance-Optimierung an sich kostet ebenfalls viel Zeit. Es gibt nicht „den“ Schalter, sondern Performance-Optimierung setzt sich aus vielen, vielen einzelnen Maßnahmen zusammen, welche sich langsam zu einem spürbaren Ergebnis addieren. Aus Betriebssicht ist das Thema eher schwierig, weil die technische Komplexität des eigenen Blogs spürbar ansteigt. Und technische Komplexität ist immer schlecht. Im Kontrast dazu schränkt das Paradigma as Lean as Possible die funktionalen Möglichkeiten von WordPress ein. Am Ende muss man hier immer eine praktikable Balance finden.

Über den Autor
Marco Hitschler wohnt in Mannheim und schreibt auf diesem Blog beliebige Texte in das Internet hinein. Sein Handwerk ist die Informatik und beruflich arbeitet er im Projektmanagement. Wenn man einmal mit dem Bloggen angefangen hat, kann man nicht mehr aufhören. Furchtbar! Infolgedessen wird auf diesem Blog ganz kunterbunt in verschiedenen Formaten publiziert.
2 Kommentare
  1. Henning Uhle 22. September 2017

    Hallo Marco, da hat sich ja jemand Gedanken gemacht. Danke für diesen Deep Dive. Es ist nicht zu technisch, aber eben auch nicht oberflächlich.

    In Sachen Optimierung kann ich aus meiner eigenen Erfahrung sagen, dass man da sehr viel Zeit darauf verwenden kann. Man findet immer wieder etwas neues, was man sich vornehmen kann. Und man muss aufpassen, dass man sich nicht verheddert.

    Der Artikel ist aber eine gute Orientierung, womit man sich beschäftigen kann. Und es werden auch ein paar Hintergründe beleuchtet. Das finde ich großartig. Danke dafür.

    Viele Grüße,
    Henning

  2. marco 22. September 2017

    Hallo Henning.

    Es war tatsächlich gar nicht so einfach, bei diesem Text die richtige Mitte zu finden, zwischen technischen Details und grobem, thematischem Anriss ohne Mehrwert. Am Ende war ich mir sehr unsicher, ob mir das gelungen ist. Letztendlich soll der Artikel nur eine fundierte Ausgangsbasis für weitere Recherchen sein. Deswegen, vielen Dank für dein Feedback!

    Das Schlimme ist, (nach all den Mühen) Performance Optimierung findet einfach kein Ende. Es gibt immer nochwas und nachwas, das man optimieren kann. Deswegen muss man sich hier wirklich disziplinieren. Ich hab das für mich so gelöst, dass ich mir Potentiale vermerke und mich dann periodisch immer mal wieder dem Thema zuwende.

    Danke für deinen Kommentar.

    Schöne Grüße
    Marco

Schreibe einen Kommentar

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