Seo & Webseitengeschwindigkeit: Der größte Rankingfaktor

18. Mai 2011  |     |  34 Kommentare
Ein Beitrag von Julian Dziki

Der Titel dieses Artikels klingt vielleicht ein wenig reisserisch, aber in bestimmten Fällen stimmt er. Bei einer Webseite habe ich neulich gesehen, dass sie trotz ständig neuen und guten Links im Ranking immer weiter abrutschte. Der Grund war die Ladezeit, die aufgrund eines Relaunches weit höher war als bisher.

Der wichtigste Rankingfaktor

Die Ladezeit einer Seite ist sicher nicht der wichtigste Rankingfaktor. Aber es kann zum wichtigsten Faktor werden, wenn die Seite enorm langsam lädt. Kurz: Wenn meine Mitbewerber alle in einer halben Sekunde laden und ich selbst in 2 Sekunden, dann habe ich definitiv einen Nachteil, wenn auch einen kleinen. Kritisch wird es erst, wenn die Ladezeit so hoch ist, dass sie die User nervt: Dann greift Google mittlerweile recht hart durch und stellt die Webseite weiter nach hinten. Der Grund sind sicher auch die neuen Handys, mit denen eine solche Webseite nur schlecht oder gar nicht aufgerufen werden kann.

Aus Google-Sicht

Es ist auch völlig verständlich, warum Google lahme Seiten nach hinten versetzt: Ich selbst bin genervt, wenn eine Seite langsam lädt. Ganz besonders gilt das bei News! Wenn ich (oft unterwegs) nachsehen will, wer gerade beim Eurovision Songcontest vorne liegt, dann will ich mich nicht ewig mit Ladezeiten abplagen, sondern schnell das Ergebnis bekommen. Und wenn (wie so oft) 50 Seiten das Gleiche berichten, dann nimmt Google eben nur die 45 Schnellsten – reicht ja auch für ein gutes Suchergebnis.

Das Schlusslicht fliegt raus

Google weiß selbst, dass auch große Webseiten teilweise keine guten Ladezeiten haben. Nur anhand der Seitengeschwindigkeit kann man selbstverständlich kein gutes Ranking erstellen. Wen es meiner Erfahrung nach aber immer erwischt, ist das “Schlusslicht” in Sachen Geschwindigkeit. Google hat eine gewisse Toleranz und gibt den schnellsten Webseiten mit Sicherheit einen sehr kleinen Bonus. Die langsamsten Webseiten aber kann es sehr hart treffen und Google gibt ihnen starke Rankingnachteile.

Lange Rede, kurzer Sinn: Versucht eure Webseiten so schnell wie möglich zu machen. Ich gehe mal ein paar Punkte durch, wie ihr das bewerkstelligen könnt.

Server

Beobachtet eure Server-Antwortzeiten, gerade zu Trafficspitzen. Wenn ihr Shared Hosting (also den Wald-und-Wiesen-Hoster) habt, dann beobachtet, ob euch vielleicht andere Seiten auf dem Server nicht gelegentlich die Performance rauben. Google will vor allem eines: Zuverlässigkeit. Stellt euch einmal vor ihr wärt Google: Würdet ihr eine Webseite für ein trafficstarkes Keyword auf Platz 1 hieven, wenn ihr euch nicht sicher wärt ob das der Server der Webseite überhaupt aushält? Sicher nicht.

Die Seite selbst

Die Seite selbst ist auch sehr wichtig. Wichtigstes Kriterium ist hierbei die Webseitengröße. Es nützt der schnellste Server nichts, wenn die Seite gute 5 Megabyte groß ist. Die absolut beste Lösung ist hier das Firefox-Plugin Firebug. Man sollte dieses Plugin installieren und dann in Kombination mit einem anderen Plugin verwenden: Yslow von Yahoo. Dann braucht man nur noch seine Seite aufzurufen und das Plugin sagt einem, was man ändern muss. Die Änderungsvorschläge werden hierbei sogar priorisiert und in Kategorien eingeordnet – eigentlich idiotensicher.

Zwar gibt es noch das gute Addon Pagespeed von Google direkt, aber es ist leider (noch) nicht kompatibel mit Firefox 4. Allerdings kann man auch online einen Schnelltest unter http://pagespeed.googlelabs.com/ machen. Achtet bei beiden Plugins darauf, dass ihr unterschiedliche Seiten eurer Domain untersucht: Die Startseite kann recht schnell sein, während die wichtigeren Artikelseiten super-langsam sind.

Beste Lösungen

Hier mal ein paar To-Do’s, wie man seine Geschwindigkeit gut verbessern kann:

  • Holt euch einen eigenen Server oder geht zu einem Hoster, der gute Performance hat
  • Komprimiert eure Bilder und skaliert sie nicht runter
  • Kombiniert Javascripte und CSS in einer externen Datei
  • Benutzt ein Content-Delivery Network: Das probiere ich gerade aus und verzweifle – meine Erfahrungen werde ich aber berichten. Ein Testergebnis gibt es beim Yoast.
  • Für WordPress: Benutzt WP-Super Cache oder W3 Total Cache
  • Schaut euch die Performance Reports in euren Webmastertools an (!) Sie sehen zum Beispiel so aus:

Was habt ihr für Erfahrungen mit der Seiten-/Servergeschwindigkeit gemacht?

Beitrag teilen:

Über den Autor

Julian Dziki ist SEO, Online Marketer und Affiliate seit 2007. Suchmaschinenoptimierung München

34 Kommentare

  • Hallo Julian !

    Ist schon irre, wie jetzt auch im Bereich SEO alles zusammenhängt. Aber auch in Sachen Speed ist SEO nur ein Ansatz. Die Welt ist deutlich breiter geworden und die Zusammenhänge auch. Aber das weisst du selber ja. Wenn da nicht gefühlte 90 % andere wären ;-)

  • Danke für die Tipps mit den Plugins! Werde ich mal testen.

  • Das ist mal eine schöne Zusammenfassung. Danke dafür! Allein über Twitter läuft ja permanent die Meldung “Google wants faster Websites”. Wir haben auch die Erfahrung gemacht, dass schnelle Websites besser dastehen im Ranking. Baustellen gibt es viele. Angefangen bei der einzelnen Seite (Schlanker Code, ausgelagertes CSS, etc) bis zum Hosting-Paket, Server und und und.

    Hier noch ein Tipp: Für wirklich weboptimierte Bilder solltet ihr Adobe Fireworks einsetzen, und nicht Photoshop!

  • Jede Seite lädt nur so schnell, wie es seine Internetverbindung zulässt… Von der Verlägerung der Ladezeiten durch die üblichen URL-Shortener, miesen mobilen Netzwerken, etc müssen wir erst gar nicht reden. Selbstverständlich macht es Sinn sich um die Ladezeiten seiner Seiten zu kümmern, jedoch bin ich nicht der Meinung das das Web so weit ist, die Geschwindigkeit eines ihm zugeteilten Mediums als objektives und gerechtes Mittel des Rankings zu nutzen… In Extremfällen vielleicht, aber bestimmt nicht in der breiten Masse, dazu felht einfach ein gewisser Standard in der Technik…

  • Die Webseitengeschwindigkeit wird ja schon seit einiger Zeit als wichtiges Kriterium geführt. Dennoch wird es mMn immer schwieriger, hier auf optimale Werte zu kommen. Die Funktionalitäten und auch die Optik benötigen immer mehr Einsatz an CSS-Klassen, Java-Code und weiteren Bausteinen. Das alles zu optimieren (und dennoch nichts an Funktionalität einzuschränken) stellt sich bis jetzt für mich als äußerst schwierig, wenn nicht unmöglich, heraus!
    Spezielle Bremsen sind aus meiner Erfahrung Google Analytics-Codes, Facebook-Like und auch Facebook-Share Plugins und auch optische Highlights wie Lightbox. Die zu optimieren wird eher unmöglich :D !
    CSS-Sprites sind eine Möglichkeit, die Bilder und HTTP-Requests zu optimieren, nur leider sind sie bei meinen Designs nur allzu selten anzuwenden :( ! Also ich finde, dass die Möglichkeiten der Geschwindigkeitsoptimierung noch nicht ausgereift genug sind, daher ist es umso krasser, das die Geschwindigkeit ein Kriterium ist!

  • Schöner Artikel und ein wirklich wichtiges Thema. Wie der Seonaut sagt, nicht nur für SEO, sondern auch für viele andere Bereiche – insbesondere für die Usability, die sich dann auch direkt in der Conversion Rate wieder bemerkbar macht.

    Ich finde es aber schade, dass in der Diskussion Page Speed bisher nur sehr undifferenziert gesehen wird. Es gibt schließlich viele Faktoren, die dazu beitragen: die reine Ladezeit der HTML-Seite, die Ladezeit der Skripte, CSS und Bilder, dann die Zeit für das Parsen des DOM und anschließend für das Rendering.

    Speziell für SEO wäre es interessant zu sehen, welche Faktoren da den größten Einfluss haben. Ist es vor allem die Größe der HTML-Seite und die Geschwindigkeit des Servers, also die reine Ladezeit, oder wird auch die Zeit zum Rendering mit einbezogen? Würde es also eher lohnen, in schnellere Server und einen besseren Cache zu investieren, oder hätte ein Refactoring der Templates Priorität?

  • Hi Julian!

    Der Titel hat ja schon fast Bild-Niveau ;-)

    Inhaltlich ein sehr guter Artikel! Website-Geschwindigkeit ist benutzerfreundlich und Google will seine User nicht an “benutzerunfreundliche Seiten” weiterleiten.

    Gefällt die Website dem User u.a., weil er nicht auf sie „warten” muss, dann gefällt die Website über kurz oder lang auch Google.

  • Hi Julian,

    wenn du am CDN verzweifelst, dann teste doch mal Amazon-Cloudfront mit “Origin-Pull”. Ausser ein bißchen Rewriting und eintragen von Subdomains in die NS-Daten musst du da ja nichts machen.

  • Danke für die Zusammenfassung, Julian.
    CDN ist eine feine Sache. Yoast empfiehlt und berichtet VPS, weil er dafür Geld bekommt. Aber es gibt im Web zahlreiche Tutorials, Erfahrungen und Messwerte, die darüber schreiben und Anbieter neutral gesehen empfehlen.

  • Du hast in meinen Augen mit deiner Aussage vollkommen recht, nur anders als Du denkst. Die Ladezeit der Webseite spielt nur indirekt eine wichtige Rolle. Bei allen häufig besuchten Seiten hat Google immens viele User-Daten (Toolbar, SERP-Klicks,…) und in diesen Daten manifestiert sich die Ladezeit. Wenn die Seite langsam lädt, dann ist die Absprungrate signifikant höher, was google beim Ranking der Webseite stark gewichtet.
    Somit ist die Ladezeit extrem wichtig, aber nur indirekt.

    Ein Beispiel für den Unterschied: Eine Webseite, mit 500 KB, kann trotzdem eine tolle Usererfahrung sein, mit einer sehr geringen Absprungrate. Nämlich, dann, wenn html und css komprimiert und schnell übertragen werden, aber im unteren Abschnitt noch Bilder und Flash-Filme geladen werden. Der User sieht alles sofort, kann anfangen zu lesen und dass im Hintergrund noch andere Sachen geladen werden, stört ihn nicht.
    Wenn google jetzt so vorgehen würde, wie du es beschreibst, dann würde die Seite wegen ihrer langen Ladezeit runtergestuft, wenn google sich aber nach den User-Daten richtet, dann wird sie hochgestuft.
    Ich denke, dass die mitteilung, google würde jetzt auch die Ladezeit einberechnen nur ein Weckruf war, der auch gewirkt hat, und sie als solche nur bei sehr selten besuchten Seiten Verwendung findet.

  • Spezielle Bremsen sind aus meiner Erfahrung Google Analytics-Codes

    Dann aber mal schnell den Asynchronen Analytics Code einbinden! Gibts seit ein paar Monaten und ist mittlerweile sogar Standard.

  • also ich hab aufgrund des Artikels mal eine Seite optimiert. Statische Subdomain, wo viele Images, CSS und JS geladen wird! Performance-Steigerung deutlich merkbar (die sichtbaren Inhalte sind trotz aufwändiger Background-Images nach ca. 1,5s fertig geladen). JEDOCH bremst vor allem das Google Analytics JS und auch die Facebook-Like Integration die Ladezeit derart aus, dass die effektive Gesamtzeit auf knappe 4 Sekunden ansteigt! Die Frage ist, bemerkt und vor allem BEWERTET Google das, dass sein eigenes Skript die Seite bremst?!?!?

  • Hallo precom Rainer,
    zumindest bei Google Analytics müsste sich durch die Verwendung des asynchronen Tracking Codes im Head der Webseite zeitlich was verbessern. Aber der lInke-Button ist tatsächlich eine Bremse…

  • Die Beta von Pagespeed Google ist kompatibel mit dem FF4.

  • ich empfehle weg mit dem Apache + mod_php oder mog_cgi, stattdessen nginx(oder ähnliches leichtes)+ Fastcgi.
    Seiten ohne Dynamik soll man als “static” speichern, viele CMS’s haben solche plugings/components.

  • Wg. den Caching Systemen:

    Habe in den letzten Tagen mal einen ausgiebigen Vergleichstest zwischen WP Super Cache und W3 Total Cache gemacht und eindeutiger Gewinner ist hier W3 Total Cache!

    Warum?

    – WP Super Cache führt zu massiven Problemen bei Plugins wie ShareThis und GD Star Rating, W3 läuft hier einwandfrei
    – Komprimierung von CSS/Javascript ist bei W3 sehr gut gelöst
    – Meine Erfahrungswerte: W3 ist ca 15-20% schneller als WP Super Cache
    – And last, but not least, W3 ist nicht so speicherhungrig wie Super Cache (welches schon mal ganz gern das Backend zum erliegen bringt #**!?#)

  • Ich hab auch gute Erfahrungen mit Amazon CloudFront/S3 als CDN. V. A. alles bereits geeignet konfiguriert (Cookieless, CNAME etc.) und sehr kostengünstig.

    Zusätzlich teste ich im Moment noch eine Art Reverse-Proxy-Dienst namens CloudFlare. Der schaltet sich bereits auf Nameserver-Ebene ein und liefert hier bereits vorhandene Cache-Daten aus. Zusätzlich noch ein paar Sicherheitsfeatures gegen böse Jungs und nette Features. Die Basisvariante ist kostenlos, deckt aber bereits alles wichtige ab. Die Kostenvariante ist trotzdem supergünstig, gerade im Vergleich zu anderen professionellen Angeboten in dem Bereich.
    Auf Nachfrage soll wohl auch bald ein Data Center in Frankfurt kommen, manchmal sind die Response-Zeiten nämlich noch nicht optimal.

  • Mit der CloudFront das ist echt ne feine Sache.. werde mal sehen, ob ich das in den nächsten Wochen irgendwie auf WordPress geeicht kriege =)
    Bezüglich caching kann ich das Cachify plugin von Sergej Müller (wpSEO) sehr empfehlen!!

  • An dieser Stelle kann ich nur das Tool GTmetrix (http://www.gtmetrix.com) empfehlen. Derzeit noch kostenlos mit Performance-Report zu YSlow und PageSpeed sowie etlichen Tipps & Details… (u.a. Monitoring)

  • Das Thema Seitengeschwindigkeit wird mich wohl noch länger begleiten – werde auf jeden Fall mal das von dir genannte Tool ausprobieren.

    Da ich auch schon nach Tools/Plugins gesucht habe, habe ich bisher immer GTmetrix verwendet, welches ich eigentlich auch ziemlich gut finde. Es gibt ebenfalls Handlungsanweisungen und wenn man einen Account hat (der kostenlos ist), dann kann man sich die Reports auch sichern lassen und später mal wieder vergleichen.

  • Frank

    Mit den richtigen Tipps und einer einfachen Seite lässt sich ein Score von 97 durchaus erreichen. Wenn die Seite jedoch optisch ansprechender ist, mit Web 2.0 Features aufwartet, dann wird es schon schwerer.
    Als Tipp könnte ich noch http://page-speed.net/ zu der Diskussion beitragen. Da gibt es einige Tipps und Hinweise zu diesem Thema.

Hinterlasse eine Antwort

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

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>