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! 😉

Wie du das elend sichtbar machst

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

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…

page-speed-uebersicht

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:

page-speed-besucherentwicklung

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?

Schließe dich jetzt über 14.000 Davids dieser Welt an

Erhalte wie andere kleine Unternehmen, Startups, Solopreneure und Problogger frische Inbound-Marketing-Inhalte. Lass damit dein Unternehmen wachsen, wie die Goliaths es tun:

28 Kommentare

  • Danke für deinen empfehlenswerten Beitrag. Viele gute Tipps und Vorgehensweisen konnte ich für mich mitnehmen.
    Ich persönlich finde das Vorgehen für Richtig guten Content als Gastautor perferkt.

    Was meint ihr ?
  • Der korrekte Plural von Index lautet übrigens Indizes (Indexe geht auch noch als korrekt durch) und nicht Indexes ;)

    JavaScript gehört nicht zwangsläufig ans Ende der Seite. Mit "defer" oder asynchronem Laden sollte man auch schon weiterkommen. Als Alternative zu einem richtigen CDN könnte notfalls auch einfach eine eigene Subdomain herhalten. Hauptsache sie ist Cookie-frei; da gehen dann die Requests auch schneller, obwohl es noch auf dem gleichen Server ist.

    Die Server-Software selbst kann übrigens auch entscheidend sein. Der Apache ist bekanntermaßen ziemlich langsam, weswegen nginx zu einer sehr beliebten Alternative geworden ist. Gleiches gilt für MySQL. Wer es einfach haben möchte, setzt einfach auf MariaDB. Ist von den MySQL-Entwicklern, die einfach keine Lust auf Oracle hatten und daher mit einem Fork weitergemacht haben, der performanter ist. Wikipedia ist übrigens auch von MySQL auf MariaDB umgestiegen.

    Noch kritischer sind die Optimierungen hinsichtlich mobiler Endgeräte. Viele setzen einfach auf Responsive Webdesign, liefern aber die gleichen großen Bilder etc. aus, die eigentlich für die Desktop-Seite optimiert sind.
  • Hast Du mal Cloudflare versucht?
  • Danke für den Tipp Micah, schau ich mir mal an! :)
  • Wer sein Wordpress auf einem Server in den USA gehostet hat, der kann über das Jetpack Plugin das Modul Photon (CDN) aktivieren. Hierbei werden Grafikdaten vom WP Netzwerk zwischengespeichert und sehr schnell an den Besucher ausgeliefert. Zusätzlich schont die Aktivierung eigene Server-Resourcen.

    Von Wordpress-Betreibern außerhalb der Staaten sollte Photon gemieden werden, da in Europa das CDN von Wordpress nicht ausgebaut ist und die Auslierung dann sogar länger dauern kann.
  • Hi Steven,

    danke für den Tipp!

    Gibt es eigentlich gute CDN-Lösungen in Deutschland? Damit wollte ich mich in ferner Zukunft beschäftigen...
  • @Sebastian,

    um deine Plugins bezüglich der Ladezeit zu überprüfen, installiere mal das Plugin "P3 Plugin Performance Profiler". Das gibt dir Auskunft über die Ladezeiten der Plugins auf verschiedenen Seiten.

    Gruß Sven
  • [...] affenblog.de gab es diese Woche einen ausführlichen Artikel zur Bedeutung der Seitenladezeit für SEO. [...]
  • Hallo Vladi,
    bin recht froh, daß Du mich per mail auf diesen Artikel aufmerksam gemacht hast.
    Sind inaktive Plugins auch verantwortlich für Geschwindigkeit und sind Euch Plugins bekannt, die "verlangsamen"?

    LG Sylvia
  • Hi Sylvia,

    meiner Meinung nach sollten inaktive Plugins die Geschwindigkeit wenig bis gar nicht verlangsamen.

    Generell verlangsamen alle Plugins, weil die quasi Ballast sind.

    Aber ich bin da nicht Techniker genug, was sagen Oliver und Sebastian? :)
  • Hi,
    gute Frage. Wenn ich ehrlich bin, dann kann ich das gar nicht beantworten. Zumindest nicht mit Zahlen oder Messungen unterlegt. Wenn ich ein Plugin nicht mehr brauche, dann lösch ich es immer. Kann ich ja ganz easy wieder installieren, wenn ich es doch noch mal brauche.
    Ich vermute aber, dass das kaum Einfluss haben wird. Ich vermute die Abfrage von Wordpress an die Datenbank lautet etwa "gib mir alle aktiven Plugins", d. h. die Filterung passiert durch MySQL. Die ist gut in sowas ... d. h. meine These: wenn es nicht hunderte inaktive Plugins sind, dann wird man davon nichts merken.
    Falls das aber wirklich mal jemand ausprobiert und gemessen hat, würd mich das auch interessieren!

    VG,
    Sebastian
  • Wow Vladi,

    der Beitrag war gut. Mit so etwas habe ich mich noch nie beschäftigt. Werde ich aber wohl in Zukunft machen müssen.

    Grüße Gerhard
  • Hey Gerhard,

    vielen Dank!

    Ich denke auch, das Thema Ladezeit kann man in Zukunft in Angriff nehmen, vor allem freut sich nicht nur die Suchmaschine, sondern auch der echte Mensch.
  • Danke, ein wirklich guter und vor allem "in sich schlüssiger Bericht", gerne mehr davon, denn so langsam spricht es sich doch herum: der Page Speed ist eine viel zu oft unterschätzte Komponente in der SEO-Optimierung...

    ... meint Dr. Hans-Jürgen Karg
  • Ahoi!

    vielen Dank! Wohl wahr, wohl wahr!
  • Ein Hallo an alle,

    ein super Artikel geworden. Die Ladezeit ist wirklich ein sehr wichtiger Faktor. Ich selbst habe zu diesem Thema einen Artikel geschrieben. Anlass war der Rankingverlust einiger Keywords. Dabei habe ich auch festgestellt, dass meine Ladezeit viel zu hoch war.

    Mit der richtigen Optimierung habe ich es auf unter 2 sec geschafft. Seitdem haben sich viele Rankings verbessert. Es gibt viele Möglichkeiten dies zu beeinflussen. Einen großen Sprung habe ich durch den Umzug auf einen neuen Hoster gemacht.

    Einiges kann ich mit Sicherheit noch verbessern und werde mir daher eure Tipps nochmal genauer anschauen.

    Gruß Sven
  • Hi Sven,

    danke dir!

    Sehr gut! Ich muss auch noch einiges drehen, aber ich habe schon einen Plan, muss nur noch ein bisschen warten und dann das "Konzept" ausrollen...
  • Hi zusammen,

    zuerst noch mal Danke an Vladislav, dass wir den Gastbeitrag hier veröffentlichen durften. Haben uns sehr gefreut.

    Wie wichtig die Ladezeit ist, zeigt das Beispiel Amazon. Die haben errechnet, dass 100 Millisekunden weniger Ladezeit die ConversionRate um 2% steigern. Bei deren Bestellvolumen würde das hochgerechnet bedeuten, dass 1 Sek mehr Ladezeit etwa 1,6 Milliarden Dollar pro Jahr (!) an Umsatz kosten würde.
    (Punkt 1 bei

    @spenny: klar, die Verbindung des Nutzers hat einen Einfluss. Aber bei DSL 16.000 oder sogar 50.000 über Kabel ist die Zeit für den Download von ein paar Kilobyte nicht mehr das, was am längsten dauert. Zumindest nach meiner Erfahrung. Aber wenn man wieder ein bisschen an "unnötigem Ballast" sparen kann, z. B. durch optimierte Bilder, dann macht das die Seite natürlich ein paar Millisekunden schneller.

    @JonasB dein Hinweis mit dem asynchronen Nachladen (Ajax) ist ein guter Tipp. Soweit sind wir im Artikel nicht gegangen, wir wollen erst mal nur die Server-Konfiguration betrachten. Dazu muss man ja auch nicht wirklich programmieren können, aber man muss natürlich die Zusammenhänge kennen und ein technisches Verständnis haben. Das fällt einem Entwickler natürlich serh viel leichter ;-)
  • Hey Sebastian,

    keine Ursache! ;)

    Ha, tolles Beispiel! Davon habe ich auch schon gelesen. Ladezeit ist einfach wichtig. Punkt.
  • Gute Punkte, wobei man speziell die Datenbank-Tipps natürlich nur umsetzen kann, wenn man selbst programmieren kann. Bei Wordpress ist auch ein Caching Plugin sehr zu empfehlen, was sich um viele dieser Dinge kümmert, ohne dass man sich um die technischen Details kümmern muss. Meine Ladezeit hat sich dadurch locker halbiert.

    Social Plugins, speziell die von Facebook können so eine Seite echt ausbremsen. Ich finde es eine gute Lösung, diese nicht direkt beim Seitenaufbau zu laden, sondern asynchron nachzuladen, wenn der Rest der Seite schon daist.
  • Ahoi Jonas,

    danke für dein Kommentar!

    Ja, die Datenbank-Geschichte könnte ich auch nicht umsetzen, aber das könnte ich einem Datenbankler ja an die Hand geben. Benutze auch Cachify und bin wirklich zufrieden.
  • Jeder SEO weiß auch dass Usabilty und UX die Zukunft in den Ranking sein werden. Google hat ja gesagt, dass sie erreichen wollen, dass die Nutzer des Internets Hochwertige Website finden. Also ist, wie du schon sagst, Content King. Da aber eine schnelle Seite auch ein gutes Besuchererlebnis mit sich führt, ja.. genau... Speed ist Queen!

    Auf ein besseres Internet, wo SEO mehr machen müssen als Links setzten und wdf*idf Formeln berechnen.

    vg
    Stavros
  • Hi Stavros,

    genau, Usability wird immer wichtiger und auch immer gewichtiger im Hinblick auf SEO-Rankingfaktoren.

    Auf ein besseres Internet! ;)
  • Sehr guter Beitrag, darüber hab ich mir eigentlich nie gedanken gemacht. Meine Seite hat laut pingdom eine Ladezeit von 3,40 s. Aber die Ladezeit hängt doch von der Internetgeschwindigkeit des Besuchers ab?
  • Hey Spenny,

    danke für dein Kommentar!

    Ja, ich denke genau wie Sebastian das die Internetgeschwindigkeit des Besuchers zwar eine Rolle spielt, aber nicht so eine große. Viel gewichtiger ist der "Ballast" deiner Webseite.
  • Hey Sebastian, hey Oliver,

    danke für den Gastbeitrag! :)

    Ich denke, Page Speed ist eine oft unterschätzte Komponente. Egal ob aus User- oder SEO-Sicht.

    Das affenblog muss auch nochmal optimiert werden, aber ich warte im Moment noch auf Genesis 2.0 - danach geht's hier auch nen bisschen runder in Sachen Ladezeit!

    Gruß
    Vladislav

Was denkst du?