124% schnellere Ladezeit mit Wordpress

124% schnellere Ladezeit – Wie ich meine Ladezeit mehr als halbiert habe.

Nach dem ich diesen Blog neu aufgesetzt habe und die ersten paar Artikel veröffentlicht habe, habe ich gerade mal wieder etwas am System optimiert. Dabei bin ich auch über die sehr schlechte Performance-Bewertung von Google gestolpert, bei der mein Blog in der Standard-Installation auf gerade mal 51 Punkte auf Mobile, bzw. 59 Punkte auf Desktop kommt. Und auch die Ladezeit bei Neueinsprüngen ist mir echt zu langsam. Ich mag schnelle Webseiten. Nach den Optimierungen war die Ladezeit 124% schneller. Das zeige ich auch in einem Vergleich der Ladezeiten in einem Video. Was ich gemacht habe und wie du das nachmachen kannst, ließt du in diesem Artikel.

Webseiten-Performance messen

Google bietet mit dem Tool „PageSpeed Insights“ eine sehr gute Möglichkeit die Performance von Webseiten zu prüfen. Dabei werden verschiedene Bereiche geprüft, welche die Ladezeit der Webseite beeinträchtigen und damit das Nutzererlebnis verschlechtern.

Zusätzlich bietet Pingdom ein super Tool an, mit dem die Anzahl der Requests und die Menge an Datentraffic gemessen werden kann.

Eine schnelle Webseite kann die Conversion-Rate massiv steigern und so zu mehr Umsatz führen. Aber auch Google als Suchmaschine hat Interesse an schnellen Webseiten, denn einerseits wollen Nutzer schnelle Webseiten und andererseits spart Google bei schnellen Webseiten viel Zeit und Performance (und damit Geld) beim Crawlen der Webseite. Die Ladezeit einer Webseite ist daher auch ein SEO-Faktor und kann Rankings beeinflussen.

Die Bewertung ist natürlich bei jeder Webseite anders. Im folgenden zeige ich an meiner eigenen Seite auf, wie ich die Performance verbessert habe. Bei deiner eigenen Webseite kann dies ganz anderes aussehen, aber die meisten Tipps sollten ebenfalls passen.

Ausgangslage – Start der Optimierungen

Bisher habe ich keinerlei Optimierungen an der Seite gemacht. WordPress und ein Thema installiert. Das war’s. Sowohl Mobile, als auch auf dem Desktop bewertet Google meine Seite sehr schlecht. Es werden einige Punkte genannt, die verbessert werden sollten. Aber immerhin habe ich bei der Bewertung der Nutzererfahrung auf Mobile-Geräten 100 von 100 Punkten bekommen.

Pagespeed: Ursprung Mobile

Pagespeed: Ursprung Desktop

Optimierungen

Ich muss also unbedingt was an meiner Webseite schrauben, um schnellere Ladezeiten zu bekommen. Im folgenden gehe ich auf einige Punkte genauer ein, die die größten Veränderungen gebracht haben. Das ist keine vollständige Liste, sondern es lässt sich noch einiges mehr machen. Es sind aber die schnellsten und einfachsten Anpassungen, die du selbst auch nach machen kannst.

JavaScript- und CSS-Ressourcen im Footer laden

Im Head-Bereich einer Webseite werden oftmals die verschiedensten JavaScripte und CSS-Dateien geladen. Der Browser der Nutzers versucht diese sofort zu laden. Wenn diese jedoch nicht zwingend für die Darstellung im oberen Bereich benötigt werden, verlangsamt dies nur die Ladezeit. Alle Scripte und CSS-Files die nicht unbedingt direkt im Sichtbaren-Bereich des Nutzers zu sehen sind, sollten daher möglichst spät geladen werden. Das wäre dann kurz vor dem schließenden Body-Tag.

Damit ich mein Template nicht selbst anpassen muss, habe ich hier ein WordPress-Plugin benutzt. Das Plugin „Async JS and CSS“ bietet eine Hand voll Einstellungen und ermöglicht es, das Javascripte asynchron geladen und CSS-Files möglichst spät geladen werden.

Mit dem Plugin ist es auch Möglich die ganzen CSS direkt im Header mitzuliefern und so auf externe Dateien zu verzichten. Da dies jedoch die benötigte Bandbreite wieder unnötig stark erhöht, nutze ich die Variante, bei der die Ressourcen über Link-Elemente im Footer, statt im Header geladen werden.

Wenn alle externen Ressourcen im Footer geladen werden, kann es beim Ladevorgang ganz kurz zu einer eher hässlichen Darstellung der Seite kommen, da die ersten Inhalte bereits da sind, Schriften und CSS ggf. aber noch nicht. Wenn ich alle Ressourcen im Footer lade, tritt das bei mir für einen Bruchteil einer Sekunde auf (Später im Vergleichsvideo gut zu sehen!). Da ich das tatsächlich recht doof finde, lade ich zwei Ressourcen nicht im Footer. Im Plugin lassen diese sich in der Ausschlussliste hinterlegen. Damit muss man ein wenig herum experimentieren.

Hinweis: Es kann aus passieren, das Plugins nicht mehr funktionieren. Dann müssten die für das Plugin notwendigen Ressourcen ebenfalls in der Ausschlussliste des Plugins hinterlegt werden und somit normal im Header geladen werden. Dann läuft alles wieder normal. Hier muss leider einiges herumexperimentiert werden. Hat bei mir ca. 15 Minuten gedauert. Das kann sich aber lohnen, da dadurch der sichtbare Bereich der Webseite wirklich schneller geladen wird.

Performance-Gewinn: 10 Punkte Mobile & 6 Punkte Desktop

Mehr zur Optimierung von CSS in der Google-Dokumentation:
https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

Bilder optimieren

Bilder sollten möglichst stark komprimiert werden um Bandbreite beim Aufrufen der Webseite zu sparen. Natürlich sollte die Qualität des Bildes nicht darunter leiden. Dennoch lassen sich Bilder meist sehr stark bei gleichbleibender Qualität komprimieren. Am besten sollten die Bilder direkt auf dem PC vor dem hochladen komprimiert werden. Tools dafür sind neben der kostenpflichtigen Grafiksoftware Photoshop das kostenlose Tool GIMP.

Laut dem PageSpeed von Google kann ich meine Bilder um 27% komprimieren, ohne dabei die Bildqualität wesentlich zu verschlechtern. Da ich WordPress nutze, bietet es sich hier super an, ein Plugin zu nutzen. Ich benutze das Plugin „EWWW Image Optimizer„. Nach der Installation ist es möglich über die „Massenoptimierung“ alle bereits in WordPress hochgeladenen Bilder zu optimieren. Wie viel Speicherplatz dabei eingespart werden kann ist sehr unterschiedlich und hängt von verschiedenen Faktoren ab. Mit EWWW konnte ich meine Bilder um durchschnittlich 32% verkleinern, ohne das die Qualität sichtbar schlechter wurde.

Hinweis: Das Plugin verlangsamt den Upload bei neuen Bildern recht stark. Der Upload großer Bilder kann dann schnell mal 5-10 Sekunden dauern, je nach Performance des Webservers. Das liegt daran, dass das EWWW-Plugin direkt das Bild komprimiert und dafür recht viel Performance benötigt.

Performance-Gewinn: 4 Punkte Mobile & 9 Punkte Desktop

Mehr zur Bilder Optimierung in der Google-Dokumentation:
https://developers.google.com/speed/docs/insights/OptimizeImages

Browser-Caching

Der Browser kann statische Inhalte, also u.a. Bilder, CSS- und JavaScript-Dateien lokal speichern und dann bei einer erneuten Anfrage diese Daten direkt abrufen, ohne den Webserver erneut anfragen zu müssen. Der Vorteil beim Browser-Caching ist also eine schnellere Ladezeit. Außerdem wird dadurch aber auch die Anzahl der Anfragen an den eigenen Webserver massiv gesenkt. Dieser kann damit viel mehr Last ertragen, was bei großen Webseiten die Kosten senken kann. Nachteil ist allerdings, dass es passieren kann, dass Nutzer noch alte Inhalte haben. Bei Browser-Caching wird angegeben, wie lange die statischen Inhalte gültig sind. Solange wird der Browser diese Datei nicht erneut vom Webserver abrufen. Wird also z.B. die CSS-Datei der Webseite verändert, müsste diese unter einem neuen Dateinamen abgespeichert werden, damit Browser diese neu abrufen. Das kann man einfach durch eine Versionsangabe oder ähnliches in der URL machen:

Ursprüngliche CSS-Datei:

http://example.com/css/styles.css

Neue CSS-Datei:

http://example.com/css/styles.css?version=123

Ein modernes aktuelle WordPress-Theme sollte damit kein Problem haben und die Versionierung bereits eingebaut haben. Bitte trotzdem unbedingt prüfen 😉 Oder du lässt auch diesen Punkt von einem Plugin machen. Dazu im nächsten Kapitel mehr.

Dabei spielt es keine Rolle, welcher Parameter mit welchem Wert an die URL angehängt wird. Wichtig ist nur, dass die URL sich unterscheidet. Der Browser des Nutzers wird diese neue Datei bei dem nächsten Besuch vom Webserver abrufen.

Browser-Caching wird über das Apache-Modul „expires“ gesteuert. Ein Standard-Webspace sollte dieses Modul bereits aktiviert haben. Wenn nicht könntest du bei deinem Webhoster nachfragen. Wenn du einen Server mit SHH-Zugang hast, kann das Apache-Modul mit den beiden folgenden Zeilen einfach aktiviert und der Webserver neu gestartet werden.

$ a2enmod expires
$ service apache2 restart

Die Konfiguration selbst wird in der .htaccess-Datei hinterlegt. Eine sehr gute Konfiguration habe ich bei „HTML 5 Boilerplate“ gefunden (Download). Da sind bereits alle notwendigen Dokumenten-Arten einzeln hinterlegt. Die Codezeilen müssen in die .htaccess-Datei eingefügt werden.

Performance-Gewinn: 3 Punkte Mobile & 4 Punkte Desktop

Mehr zu Browser-Caching in der Google-Dokumentation:
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching

W3 Total Cache als WP-Plugin

Eigentlich bin ich ja nicht so der WordPress-Plugin-Fan, sondern mache vieles lieber selbst. Da das aber manchmal sehr aufwendig sein kann, kann auch hier wieder ein Plugin sehr weiter helfen. Ich nutze „W3 Total Cache“ um folgende Punkte zu optimieren:

  • Antwortzeit des Servers
  • JavaScript reduzieren
  • CSS reduzieren
  • Komprimierung aktivieren

W3 Total Cache erzeugt lokal auf dem Webserver einen Cache und speichert darin Website-Daten ab. Dadurch kann die Webseite bei Anfragen schneller bei Ausgeliefert werden. Somit reduziert sich die Antwortzeit des Servers.

Dazu lassen sich diverse Optionen in dem Plugin einstellen. Die meisten WordPress-Blogs sollten kein Problem haben, wenn alle Optionen aktiviert werden. Sollte doch etwas nicht funktionieren, einfach mit den Einstellungen und unterschiedlichen Caches bisschen rumspielen. Der Geschwindigkeits-Vorteil war hierbei aber tatsächlich gar nicht mehr sooo groß.

Endergebnis

Um die Optimierungen Vergleichen zu können habe ich diese als Video aufgezeichnet. Um die Ladezeiten besser erkennen zu können, habe ich meine Netzwerkgeschwindigkeit auf 200kb/sec gedrosselt. Dadurch laden alle Elemente langsamer und der Unterschied ist deutlicher zu sehen. Die Sekunden in dem Video sind also eigentlich viel schneller, wenn es eine normale Internetverbindung ist. Es geht dabei eigentlich nur um den Vergleich untereinander.

Außerdem ist für mich der Zeitpunkt relevant, zu dem der relevante Inhalt im sichtbaren Bereich geladen und korrekt dargestellt wird und nicht der Zeitpunkt, wenn wirklich alle Inhalte verfügbar sind.

In dem Video vergleiche ich drei Varianten.
1) keine Optimierungen
2) die Einstellungen, für die ich mich letztendlich entschieden habe. Dabei habe ich nicht alle Features der Plugins genutzt.
3) maximale Einstellungen der Plugins

Bei der dritten Variante (ganz Rechts) sieht man sehr gut, was ich mit der Schrift meinte, die zwischenzeitlich eher bescheiden aussieht. Außerdem sieht man gut, wie schnell der reine Text eigentlich da sein könnte, wenn nicht haufenweise CSS und Javascript das Laden und Rendern verzögern würde.

Video-Vergleich

Und hier der Video-Vergleich:
Wie gesagt: Die Sekunden sind keine echten Ladezeit-Sekunden!

Freelancer. Blogger. Affiliate. Und auf Weltreise.

Kommentar verfassen