Nach dem wir Euch bisher erklärt hatten, wie wir ins Thema Webseitenoptimierung eingestiegen sind und welche Analyse-Tools wir verwendet haben, wollen wir Euch in diesem Beitrag konkret zeigen, was wir auf unserer eigenen Seite umgesetzt haben.

Teil 1: Unser Einstieg in die Webseiten-Optimierung
Teil 2: Tools zur Webseiten-Analyse
Teil 3: Unsere Umsetzung der Webseiten-Optimierung

Wir haben die vergangenen Wochen genutzt, unsere Webseite etwas zu modernisieren. An ein paar Stellen haben wir das Layout aufgefrischt und neue Social Buttons eingefügt. Zudem haben wir kräftig am Code hinter den Kulissen gearbeitet. Die Veränderungen sind seit einer Woche online, nachdem wir alle Anpassungen am Code intern getestet hatten.
Falls Euch durch unsere Umbauarbeiten Unannehmlichkeiten entstanden sind, entschuldigen wir uns dafür und bitten Euch gleichzeitig um Eure Mithilfe: Meldet uns Darstellungsfehler, wenn bei Euch im Browser etwas nicht so aussieht, wie es sollte. Bitte macht einen Screenshot und schickt uns diesen zusammen mit Angaben zur Browserversion und OS an unsere E-Mail-Adresse, die Ihr unter Kontakt findet.

„Wir hatten uns zwei Ziele gesetzt: Die Auslieferung der Webseite vom Server sollte beschleunigt werden und die Seite für die Crawler der Suchmaschinen besser lesbar sein.“ (Monk-Trader von hitzestau)

Was haben wir getan?
Eine grosse Hilfestellung für unsere Arbeit waren die Verbesserungshinweise der Analyse-Tools, die wir Euch im zweiten Teil dieser Serie vorgestellt haben. Die folgenden Erklärungen haben wir versucht möglichst einfach zu halten, damit sie auch für Neueinsteiger ins Thema verständlich sind.
Hier die Kurzfassung:

  • Grafiken in Sprites zusammengefasst
  • Komprimierung der Datenübertragung
  • Komprimierungen am Code
  • Browser-Cache aktiviert
  • Grösse der MySQL-DB reduziert
  • php-Version angepasst
  • Plugin Jetpack entfernt
  • Bildergrösse reduziert

Und wer mehr wissen will, findet hier mehr Erklärungen im Detail:

  1. Grafiken in Sprites zusammenfassen
    Den Ausdruck Sprite hatten wir schon im ersten Teil erwähnt. Ein Sprite ist eine Grafikdatei, die verschiedene einzelne Elemente zusammenfasst. Am besten zeigen wir Euch gleich ein Beispiel. Dies ist das Sprite für den Header auf der Frontseite, es enthält alle zur Darstellung notwendigen Elemente.CSS-Sprite des Featured Header
    Unser Sprite für den so genannten Featured Header auf der Frontseite.Die einzelnen Elemente wie beispielsweise der Hintergrund und die kleinen Pfeile sind normalerweise alles einzelne Dateien, deren Aufruf immer eine einzelne Anfrage an den Server, also einen so genannten Request, darstellt. Ein Sprite reduziert die Anzahl Requests, was zu den wichtigsten Ziel der Webseitenoptimierung zählt. Im Falle unseres Headers heisst das eine Reduktion von sechs auf eins. Wer mehr über das Thema Sprite wissen will, findet hier einen guten Einstieg ins Thema: CSS-Sprites (Wikipedia).Ein Sprite kann von der Dateigrösse her leicht grösser sein als die Summe der einzelnen Elemente, aus denen es besteht. Das ist aber nicht weiter schlimm, da es einfacher ist, eine etwas grössere Datei am Stück zwischen Webserver und Browser zu übertragen als mehrere kleinere, einzelne Dateien.Andere Sprites sind die Social Buttons im rechten Balken, der Hintergrund und verschiedene Elemente der Seite wie unter anderem die „Mehr“-Buttons. Um die Datenmenge zu reduzieren, haben wir die Grafiken auf fünf Sprites zusammengefasst und nicht in ein grosses. Die Grösse der Sprite-Dateien kann man zusätzlich mit einem Tool wie TinyPNG reduzieren. Ein Sprite kann man gut mit Adobe Photoshop selber erstellen, im Web findet Ihr gute Anleitungen dazu. Manchmal muss es aber kein Sprite sein: die abgerundeten Ecken des weissen Content-Teils auf der Webseite sind anstatt als Hintergrundbild wie bisher neu via CSS gelöst.

  2. Komprimierung

    Es gibt verschiedene Arten der Komprimierung. Wie wir es im ersten Teil beschrieben hatten, werden auch bei uns die Daten zwischen Webserver und Browser komprimiert übertragen. Eine andere Art der Komprimierung bedeutet Eingriffe in den Codes des Templates. Das Plugin W3 Total Cache, welches wir auf Anraten unseres Webhosters cyon eingerichtet haben, fasst Codeteile wie JavaScripts und CSS-Dateien zusammen. Bei unserem Template war das CSS auf fünf Dateien verteilt, was ja auch fünf Requests bedeutete. Das Plugin hat das gesamte CSS in eine Datei zusammengefasst. Dasselbe gilt für die verschiedenen JavaScripts. Neu sind alle Scripts an zwei Orten zusammengefasst: eines im Header-Teil und eines im Body-Teil des Codes. Dadurch wird das Ausführen der Seite beschleunigt. Diese Form der Webseitenoptimierung fällt unter den Begriff Minification, was so viel bedeutet wie alle unnötigen Zeichen und Zeilen im Code zu entfernen ohne an der Funktionalität etwas zu ändern.

    „Die Reduktion der Anzahl Requests und der Datenmenge sind wirklich zwei Mammutsaufgaben.“ (Monk-Trader von hitzestau)

  3. Browser-Cache aktivieren
    Mit Hilfe von W3 Total Cache lässt sich dem Browser eines jeden Besuchers mitteilen, dass er statische Elemente wie zum Beispiel Bilder im Cache speichern soll. Beim nächsten Ansurfen der Seite müssen die Elemente nicht neu vom Server geholt werden, was wiederum die Ladezeit verkürzt.

  4. Grösse der MySQL-DB
    Die Grösse der MySQL-Datenbank spielt ebenfalls eine Rolle. WordPress protokolliert von jedem Artikel mit einer automatischen Speicherung alle laufenden Veränderungen, so dass jeder Artikel in verschiedenen Versionen abgespeichert ist. Wir haben rückwirkend alle alten Versionen unserer Artikel gelöscht, was die Grösse der Datenbank um 2/3 reduziert hat.

  5. php-Version anpassen

    Die auf dem Server aktive php-Version kann eine Rolle spielen, wie schnell der Code ausgeführt werden kann. Durch die Anpassung der php-Version konnten wir eine Verbesserung erreichen. Wenn man die php-Version auf dem Server anpasst, muss man immer darauf achten, dass das WordPress und alle Plugins weiterhin funktionieren. Wenn alter php-Code verwendet wird, kann es beispielsweise wegen Veränderungen in der Syntax zu Konflikten und Fehlern kommen.

  6. Plugin Jetpack entfernt

    Bisher haben wir das Plugin Jetpack auf unserer Webseite verwendet. Neben einer Statistik hat uns Jetpack die Rubrik „Oft gelesen“ in der rechten Spalte gemacht. Wir haben Jetpack entfernt und die Rubrik durch ein anderes Plugin ersetzt. Damit konnten wir die Serverwartezeit um 200ms reduzieren. Wir denken, dass sagt einiges über Jetpack aus. Jetpack enthält viele Funktionen, von denen wir die meisten nie genutzt haben, trotzdem sind sie im Code vorhanden und blähen diesen unnötig auf.

  7. Bildergrösse reduzieren

    Schöne Bilder sind zwar eine feine Sache, aber sie tragen auch viel zur gesamten Datenmenge einer Webseite bei, die bei jedem Aufruf übertragen werden muss. Natürlich sollte man schon beim Ausgeben der Bilder aus einem Programm wie Photoshop oder Lightroom auf die Dateigrösse achten. Mit dem Plugin WP Smush.it haben wir die Grösse der Bilddateien nachträglich reduziert. Es optimiert die JPG-Kompression und entfernt alle Metainformationen aus den Bildern. Damit erreicht es im Schnitt eine Reduktion zwischen fünf und zehn Prozent der Dateigrösse. Das mag nicht nach viel tönen, aber das summiert sich hoch, wenn man mehrere Bilder auf einer Seite oder in einem Beitrag hat. Dasselbe gilt, wenn die Seite oft aufgerufen wird: Die Trafficmenge reduziert sich.

  8. Der Moment der Wahrheit: Hat es sich gelohnt?

    Soweit unser Überblick über die wichtigsten Massnahmen, die wir umgesetzt haben. Jetzt kommt natürlich die grosse Frage, ob all die Mühen und Arbeitsstunden auch wirklich etwas gebracht haben. Das Tool Pingdom, welches wir Euch im ersten Teil schon vorgestellt hatten, erlaubt im Reiter History einen Blick in die Vergangenheit. Die Grafiken reichen bis ungefähr zum 5. Juli 2013 zurück, auch wenn wir schon gewisse Optimierungen vor diesem Datum umgesetzt hatten, zeigen die Screenshots sehr deutlich, dass wir unter anderem die Anzahl Requests reduzieren und den Page Speed Score deutlich verbessern konnten.

    Erfolgskontrolle mit Pingdom
    Für Vollansicht hier klicken

    Erfolgskontrolle mit Pingdom
    Für Vollansicht hier klicken

    Und präsentiert sich aktuell unsere Webseite in den Wertungen der drei Analyse-Tools:

    Wertung mit PageSpeed InsightsWertung mit YSlowWertung mit Pingdom
    Für Vollansicht hier klickenFür Vollansicht hier klickenFür Vollansicht hier klicken

    trans500-20

    Die Grösse der Startseite haben wir ebenfalls reduzieren können. Von ursprünglich 470 K sind wir jetzt bei einer Datenmenge von rund 330 K.

    Also können wir mit guten Gewissen sagen, dass wir unsere Ziele erreicht haben und sich die Arbeit gelohnt hat: Die Datenmenge und die Anzahl Requests wurden reduziert und die Seite wird schneller ausgeliefert.

Fazit
Unser Fazit lautet, um bei Google mit der eigenen Webseite eine gute Präsenz zu erreichen, muss man recht viel Arbeit reinstecken und auch die von den Suchmaschinen gestellten Anforderungen sind auch nicht mehr so einfach zu erfüllen. Es gibt viele Ansätze eine Webseite schneller zu machen und nicht alle Faktoren, welche die Geschwindigkeit einer Webseite bestimmen, kann man gleich gut beeinflussen, vor allem wenn die Webseite wie unsere auf einem Shared Hosting läuft. Mit den hier zusammengefassten Massnahmen ist die Optimierung unserer Webseite aber noch nicht abgeschlossen – wobei wirklich absolut fertig ist man damit sowie so nie.

„Frustgefühle gehören dazu, wenn man versucht, die eigene Webseite zu optimieren. Nicht alles, was man ausprobiert, hat auch die gewünschte Wirkung.“ (Archangel von hitzestau)

Webseiten-Optimierung ist zweifelsohne ein Thema das ganze Bücher und Workshops füllt. Es ist für Blogs und Newsseiten genauso wichtig wie für einen Online-Shop, bei dem es auch um Absprungraten oder Conversion Rates geht. Ziele und Umsetzung können sich natürlich jeweils unterscheiden. Wir haben hier das komplexe und vielschichtige Thema auf ein paar Aspekte der OnPage-Optimierung beschränkt, weil wir bisher nur Massnahmen aus diesem Teilbereich umgesetzt haben.

Ausblick
Mit den uns zur Verfügung stehenden Mitteln haben wir erreicht, was wir konnten. Das Thema Meta-Keywords- und Descriptions werden wir noch angehen und damit auch unsere Blog-Serie weiter fortsetzen. Andere Massnahmen ziehen zusätzliche Anbieter oder einen neuen Server nach sich, sind also mit Kosten verbunden. Dazu zählt auch eine so genannte CDN-Lösung. CDN steht für Content Delivery Network (Wikipedia). Statische Elemente wie beispielsweise Bilder lassen sich auf Suddomains auslagern, die auf anderen Servern gehostet sind. So können sich die Requests auf mehrere Server gleichzeitig verteilen lassen, was die Auslieferung der gesamten Webseite wiederum beschleunigt. Meistens sind pro Server zehn Requests gleichzeitig möglich. Durch eine Verlagerung der statischen Elemente auf eine Subdomain lässt sich auch die Übertragung der angehängten Cookies verhindern, diese Reduktion des Overhead ist wieder eine Verkleinerung der Datenmenge die übertragen wird. Das ganze Thema CDN ist für uns absolutes Neuland. Falls Ihr schon damit Erfahrungen habt und einen guten Anbieter kennt, freuen wir uns über Eure Tipps und Meinungen in den Kommentaren.

Im Zusammenhang mit dem WordPress steht auch das Thema Security noch auf unserer Agenda. Auch darauf werden wir in einem kommenden Beitrag näher eingehen.


Die Kommentarfunktion ist auf Grund der DSGVO geschlossen!