Die wohl am meisten unterschätzte SEO-Komponente

Wenn Content King ist, dann ist Page Speed Queen.

Das Thema Ladezeit hatten wir am Anfang unserer Projekte wenig bis kaum berücksichtigt.

Wir wussten ja, dass alle Bilder eine angemessene Größe hatten und der Blog mit den ganzen Widgets echt pfiffig daher kam.

Regelmäßiger Content und ein bisschen Backlink-Aufbau brachten uns schon sehr bald die ersten Besucher. Alles schien top zu laufen.

Aber dann fragten wir uns…

Wie lange dauert es eigentlich unsere Seite ohne Browsercache zu laden? Oder anderes gesagt:

Wie lange muss jemand warten, der unsere Seite noch nie besucht hat?

Antwort damals: 14 Sekunden!

Mit so einem katastrophalen Ergebnis hatte niemand gerechnet. Als wir den Page Speed auf zugegeben immer noch miese 7 Sekunden verbessert hatten, passierte allerdings etwas Erstaunliches:

Unsere Besucherzahlen machten einen signifikanten Sprung nach oben.

Google mag anscheinend schnelle Ladezeiten besonders gerne! Grund genug, sich mit diesem Thema genauer zu beschäftigen. Oder?

WordPress und all seine tollen Widgets

Ein WordPress Blog ist schnell aufgesetzt.

Ein chices Theme angeguckt, ein paar nette Widgets installiert und schon kommt das Teil recht professionell daher.

Für den persönlichen Touch noch ein paar Bilder angepasst, läuft!

Gefühlt ist die Ladezeit auch nicht so schlecht, schließlich vergisst man gerne, dass das Meiste aus dem Cache geladen wird. Zudem sind noch kaum Artikel online, welche evtl. Widgets ausbremsen könnten.

Wir hatten z. B. eine zusätzliche Navigation (Baumstruktur in JavaScript) mit aufgenommen. Am Anfang, als noch wenig Artikel geschrieben waren, fiel dies kaum ins Gewicht. Später, bei ca. 50 Artikeln hatte nur das Laden dieser einzigen Navigation stolze 5 Sekunden in Anspruch genommen.

Das Teil flog sofort raus!

Zusammenfassend kann gesagt werden: Überprüfe regelmäßig deinen Blog mit unvoreingenommenen Adleraugen.

Gerade wenn am Anfang noch wenig Artikel vorhanden sind, fällt ein schlecht programmiertes oder sinnfreies Widget nicht so sehr ins Gewicht.

Dies kann sich allerdings schneller ändern, als dir lieb ist! 😉

(Update: Wir haben mittlerweile mit Chimpify eine eigene sehr performante WordPress Alternative entwickelt!)

Wie du das elend sichtbar machst

Willst du also wissen, wo du stehst, dann genügt ein kurzer Besuch auf…

• WebPagetest, oder…
• Pingdom Website Speed Test, oder…
• Google PageSpeed

Dort kannst du quasi deine Seite auf Herz und Nieren testen. In der Regel besteht da jede Menge Handlungsbedarf! 😉

Wie du deinen Page Speed optimierst

Grundsätzlich existieren 3 verschiedene Ansatzpunkte:

1. Zeit verkürzen, die der Server braucht, um die benötigten Daten zusammen zustellen (= „Response Time“ oder „Time to first Byte“)
2. Zeit verkürzen, die die tatsächliche Übertragung zum Besucher in Anspruch nimmt
3. Zeit verkürzen, die der Browser des Besuchers braucht, um den Inhalt darzustellen.

Diese Grafik veranschaulicht das nochmal ein wenig bildhafter…

Bei den Themen in dieser Rubrik muss aber immer nach dem konkreten Einsatzszenario der Webseite ab gewägt werden – was für A super funktioniert, kann bei B bremsen.

Peer Wandiger beschreibt z.B. in seinem Artikel, dass man Ladezeiten verringern kann, indem man die kompletten Seiten von einem Plugin vorgenerieren lässt, zwischenspeichert und anschließend nur noch statische HTML-Dateien ausliefert.

Damit hat man natürlich die Response Zeit stark minimiert, wenn das Szenario passt. Das ist aber nicht immer möglich oder praktikabel, z. B. wenn sich Inhalte häufig ändern oder ein Warenkorb aus einem Shop im Blog angezeigt wird.

Wenn man ein eigenes Template und eigene Plugins geschrieben hat, kann man zusätzlich mal mit offenen Augen durch seinen Code gehen und nach Überresten von früheren Versionen suchen.

Datenbankabfragen, deren Ergebnis gar nicht (mehr) benutzt wird, sind dabei ein Klassiker.

Wie du deine Response Time verringerst

Sobald eine Anfrage an den Server gestellt wird, marschiert dieser los und sucht sich alle benötigten Daten zusammen.

Hier kannst du deinem Server das Leben leichter machen, indem du folgende Dinge beachtest…

Räume deine Startseite auf

Klar dauert es lange bis zehn oder mehr komplette Artikel mit den ganzen Bildern und Social Plugins geladen sind.

Biete auf der Startseite die Artikel in Kurzform an und packt die Social Plugins dann unter Details. Hier wird schließlich nur ein Artikel geladen und du hast dort mehr Luft für weitere Inhalte.

Mit www oder ohne?

Prinzipiell ist es egal, ob deine Seite unter http://www.[DeineSeite].de oder erreichbar ist.

Achte nur darauf, dass es überall gleich hinterlegt ist. Dies betrifft sämtliche Pfadangaben zu evtl. Skripten, CSS-Dateien oder Bildern. Mal mit oder mal ohne führt zu einer zusätzlichen DNS-Anfrage, die völlig überflüssig ist!

Hosting

Natürlich hat auch das Hosting einen enormen Einfluss auf die Ladegeschwindigkeit (das soll hier nur der Vollständigkeit halber erwähnt werden).

Es macht halt einen Unterschied, ob du dir die Rechenpower mit mehreren hundert Webseiten teilen musst, oder eben nicht.

Gönnst du dir für dein Web-Projekt einen eigenen VServer oder Root-Server, hat man in der Konfiguration alle Freiheiten und kann ordentlich an der Performance-Schraube drehen.

Neben der Tatsache natürlich, dass dir sowieso mehr Rechenleistung zur Verfügung stehen.

Datenbank

Die meiste Zeit bis die ersten Daten übertragen werden geht dafür drauf, die benötigten Daten aus der Datenbank zu laden. Sie ist also auf jeden Fall einen genaueren Blick Wert.

Du solltest der Datenbank genügend Arbeitsspeicher geben, damit sie effizient arbeiten kann. Das können je nach Szenario auch gerne mal 50% des gesamten Speichers sein.

Dinge, die du dabei beachten solltest, sind…

• Sind eigene Tabellen erstellt worden? Sind dabei Indexes gesetzt? Indexes können bei SELECT und JOIN Abfragen einen deutlichen Geschwindigkeitsvorteil bringen, machen INSERTs jedoch langsamer, da der Index neu aufgebaut werden muss. Für Primärschlüssel werden automatisch Indexes angelegt.
• Diese Indexes werden in Buffern im Arbeitsspeicher vorgehalten. Hierfür sollte ausreichend Platz zur Verfügung stehen, damit sie nicht für jede Abfrage neu gelesen werden müssen. In MySQL heißen die entsprechenden Variablen je nach eingesetzter Storage Engine „key_buffer“ (für MyISAM) bzw. „innodb_buffer_pool_size“ (für InnoDB). Ein guter Anfangswert ist 96MB, anschließend muss man schauen, ob man mehr oder weniger benötigt.
• Gerade bei Blogs werden viele Abfragen immer und immer wieder an die Datenbank gestellt, z. B. „gib mir alle Kategorien“. Hier hilft es, den Query Cache zu aktivieren, um die Ergebnisse im Speicher vorzuhalten, statt jedes Mal eine neue Selektion laufen zu lassen. Es genügt hierfür der Variable „query_cache“ einen Wert > 0 zu geben. Je nach Speichergröße kann man hier mal mit 64 MB anfangen zu experimentieren.

Für das Tuning von Datenbanken empfehle wir die Skripte mysqltuner.pl und tuningprimer.sh, die die Laufzeitinformationen des Servers auslesen und dir gute Tipps an die Hand geben.

Übertragungszeit verkürzen

Um die Übertragungszeit zu verkürzen, sollte Alles was durch den Draht muss, möglichst klein sein.

Dies betrifft vor allem die Bilder, den Code und die Header-Daten.

Bilder optimal komprimieren und Header-Daten minimieren

Hier musst du den Spagat zwischen Größe und Aussehen schaffen.

Auf keinen Fall die Bilder im HTML-Code oder per CSS kleiner machen. Jedes zusätzliche Byte verbrennt ein paar Millisekunden kostbare Ladezeit.

Sobald deine Seite soweit steht, dann geh einmal konsequent alle Bilder durch und optimiere diese auf Größe und Aussehen. Wetten, dass da unterm Strich etliche KB zusammen kommen?

Bedenke zudem, dass bei jeder Anfrage an den Webserver zusätzlich zum Inhalt ein paar Header-Daten übertragen werden. Bei vielen kleinen Grafiken kann das erheblicher Overhead erzeugen.

Es ist also fast immer sinnvoll, mehrere kleine Grafiken in eine große Grafik zusammen zu fassen und per CSS nur einen Ausschnitt anzuzeigen (Stichwort: „image sprites“). Dies gilt genau so für Skripte. Fasse viele kleine JavaScript-Dateien in eine große Datei zusammen.

In Echtzeit komprimieren

Ein Klassiker ist es, seine Inhalte vor der Übertragung vom Server per GZip komprimieren zu lassen und das gepackte Ergebnis an den Browser zu schicken.

Wird überall empfohlen und so spart man häufig auch etliche KiloByte. Du musst dabei bedenken, dass der Server für jeden Besucher die Inhalte in Echtzeit packt, d. h. die CPU-Last wird steigen (Stichwort: „Hosting“).

Ebenso muss der Client die Daten erst wieder entpacken, bevor er sie verarbeiten kann. Für bestimmte Dateiformate (z. B. JPEG-Grafiken) sollte man sich diesen Overhead sparen, da diese Formate bereits gepackt sind und sich kaum eine Einsparung in der Übertragungsmenge ergibt (Stichwort: „apache deflate“).

Rendering Zeit verkürzen

Nachdem alle Daten an den Browser übertragen sind, müssen diese noch dargestellt werden.

Dabei kann man dem Browser ein wenig unter die Arme greifen. Je nachdem, ob man einen Firefox, Internet Explorer, Chrome oder Opera „vor der Flinte“ hat, bringt das ein wenig mehr oder weniger.

HTML-Code validieren

Der Browser stellt sich genau zwei Fragen…

1. Was soll ich von den Daten anzeigen?
2. Wie soll ich die Daten anzeigen?

So kann es für den Browser durchaus aufwändig sein und lange dauern, bis er ggf. „hineininterpretiert“ hat, was er tun soll (Rendering Time).

In einem Projekt haben wir erlebt, dass durch einen groben Schnitzer knapp 30% des Page Speeds benötigt wurden, nachdem (!) das letzte Byte übertragen war.

Denke also immer daran, den HTML-Code weitestgehend W3C-Konform zu machen (validieren), um den Browser nicht zum „raten“ zu zwingen.

Bilder mit width und height

Total simpel, aber oft vergessen oder unterschätzt:

Breite und Höhe bei Bildern angeben. So kann der Browser einfach Platz lassen und weiter rendern, ohne dass das Bild geladen sein muss.

Umgang mit JavaScript und CSS

Javascript-Dateien blockieren beim Laden das Rendering, weil sie theoretisch den Objekt-Baum im HTML verändern könnten.

Sie gehören deswegen möglichst ans Ende der Seite. CSS-Dateien werden dagegen parallel geladen und gehören in den Kopf der Seite.

Fazit

Die Praxis zeigt, dass eine konsequente Optimierung der Ladezeit einen erheblichen Einfluss auf SEO hat.

Oft gilt das Motto: „Kleine Ursache, große Wirkung“. Das heißt eine Veränderung/Verbesserung muss gar nicht unbedingt kompliziert sein und umfangreiche Programmierarbeiten bedeuten.

Für das Testsieger-Blog konnten wir mit den eher einfachen Optionen den Page Speed von durchschnittlich 8-14 Sekunden auf konstant ca. 3 Sekunden reduzieren. Davon brauchen wir etwa 1.8 Sekunden, um unseren Inhalt zu übertragen, der Rest sind Grafiken und Icons von Dritt-Anbietern.

Arbeitsaufwand, etwa 4 bis 6 Stunden.

Und das Ergebnis kann sich sehen lassen:

So konnten wir die Besucherzahlen deutlich steigern – im Durchschnitt und auf einen längeren Zeitraum haben wir sie sogar verdoppelt (weitere SEO-Maßnahmen haben erst später angefangen).

Das war ein Gastartikel von Sebastian Leitner (von Dein-Bikeshop) und Oliver Krimmer (von DeinTestsieger). Wir wünschen dir viel Spaß und Erfolg auf deiner Jagd nach den nächsten Millisekunden!

Hast du noch andere Tipps, um die Ladezeit zu verringern?