Seit einigen Wochen wird unter Experten eifrig diskutiert, ob und inwieweit ein schneller Webserver Einfluss auf das Ranking bei Google hat. Der Anstoß dazu kam diesmal direkt vom Suchmaschinengiganten. Soll man nun mit der eigenen Website schnellstmöglich umziehen? Wer ist betroffen und was kann man selber tun?
Wie immer lässt sich eine solche Frage nicht mit einem einfachen Ja oder Nein beantworten. Techniker führen oft an, dass ein Webserver nie schnell genug sein könne – und ganz Unrecht haben sie wohl damit nicht. Die Kaufleute sehen natürlich eher auf die Kosten und fragen, ob es denn wirklich so schnell gehen muss. Da die Wahrheit wohl vermutlich in der Mitte liegt, gilt es für einen profitablen Betrieb beide Anforderungen eben auch unter ökonomischen Gesichtspunkten auszubalancieren. Um dazu ein wenig mehr Transparenz zu schaffen, hilft es, die wichtigsten Fakten und Argumente zusammenzutragen. Google hat sich offiziell im eigenen Webmaster Central Blog am 09. April zum Thema Geschwindigkeit geäußert. Dort heißt es unmissverständlich, dass dies als ein (neuer) Rankingfaktor angesehen wird. Allerdings sind nach Angaben von Google bisher nur wenige englischsprachige Seiten betroffen, die über Google.com gesucht bzw. dort als Ergebnis gelistet werden. Entwarnung? Sicher nicht, denn die Ausweitung auf andere Sprachen und Länder wird wahrscheinlich nicht lange auf sich warten lassen. Sich rechtzeitig um dieses Thema zu kümmern, mag daher eine gute und vorausschauende Idee sein. Yahoo! gibt den Webmastern auch bereits länger viele Tipps, wie die ihre Websites schneller machen können. Ob Yahoo! oder Bing den Faktor Ladezeit mit einbeziehen, ist allerdings noch nicht bekannt.
Auch einen weiteren wichtigen Aspekt für die Servergeschwindigkeit sollte man nicht außer Acht lassen. Johannes Müller von Google hat auf der SEMSEO 2010 in Hannover darauf hingewiesen, dass ein langsamer Webserver auch die Anzahl der indizierten Dokumente einer Domain herabsetzen kann. Jede Domain hat nämlich aufgrund einiger Faktoren eine Obergrenze für diese Anzahl an Seiten, die in den Index aufgenommen wird. Stellt der Googlebot fest, dass seine eigenen Abfragen die Geschwindigkeit eines Webservers negativ beeinflussen, crawled er langsamer. Seine Besuchsfrequenz und die Anzahl der abgerufenen und indizierten Dokumente sinken also.
Schalten Sie in nennenswertem Umfang Pay-per-Click-Werbung bei Suchmaschinen? Zumindest bei Google Adwords geht die Geschwindigkeit des Webservers in die Berechnung des sogenannten Quality-Scores ein, der für jedes Keyword mit einem Wert von 1–10 angezeigt wird. Das von Ihnen abgegebene maximale Klickgebot und der erzielte Quality-Score gehen gemeinsam gleichwertig in die Berechnung des tatsächlich zu zahlenden Klickpreises ein. Ein hoher Quality-Score bedeutet also bei sonst gleichbleibenden Umständen einen niedrigeren Klickpreis. Damit sinken die Kosten für solche Online-Werbekampagnen. Je nach Budgetumfang rechnet sich der Aufwand für Optimierungsmaßnahmen oder für einen schnelleren Webserver oft schon nach Wochen oder wenigen Monaten.
All dies zusammen ist sicher Grund genug, das zu tun, was gute Suchmaschinenoptimierer schon seit Längerem machen – sich mit der Geschwindigkeit der eigenen Webseiten ernsthaft zu beschäftigen.
Zunächst stellt sich natürlich die Frage, ob der Webserver, auf dem die eigenen Seiten oder der eigene Shop liegen, tatsächlich ein Geschwindigkeitsproblem hat. Wer reine HTML-Seiten direkt auf dem Webserver abgelegt hat, ist meist fein raus, Denn diese Art des Webhostings hat gegenüber datenbankgestützten Arten wie bei den meisten Content-Management-Systemen (CMS), Shops, Blogs oder Flashseiten einen extremen Geschwindigkeitsvorteil: Die Seite liegt bereits fertig vor und muss nur noch an den anfragenden Surfer ausgeliefert werden. Muss eine Seite erst beim Abruf erzeugt bzw. von einem Programm zusammengebaut werden, ist die Serverbelastung ungleich höher. Zu den vielen Datei- und Datenbankabfragen der einzelnen Informationsstückchen muss eben auch noch ein mehr oder weniger umfangreicher Code interpretiert und abgearbeitet werden. Aus einem scheinbar einfachen Seitenabruf können so schnell zwanzig bis dreißig Datenbankabrufe werden. Wenn die Serverbelastung hier pro Seite aber zum Beispiel zwanzigmal so hoch ist, kann man sich schnell ausrechnen, dass man zu Spitzenzeiten hier Probleme bekommen kann. Wie gut die Antwortzeiten dann wirklich sein sollten, wird wohl niemand so genau sagen können. Experten gehen aber davon aus, dass man bis zu einer Sekunde gut im grünen Bereich liegt.
Um Geschwindigkeit im Web zu messen, gibt es bereits seit Längerem diverse Online-Tools wie zum Beispiel unter www.sitealert.de/ladezeit-check.html. Wer auf Besucherzufriedenheit achtet, hat wahrscheinlich aus guten Gründen schon immer ein Auge auf den schnellen Seitenaufbau geworfen. Hier geht es aber nun darum, wie Suchmaschinen die Geschwindigkeit einschätzen.
YSlow (http://developer.yahoo.com/yslow) ist als Plug-in für den Firefox-Browser erhältlich und läuft (nur) zusammen mit einer zusätzlichen Erweiterung namens Firebug (http://getfirebug.com).
Nach der Installation ruft man über „Extras/Firebug/Firebug öffnen“ die Konsole von Firebug auf, die den Browserbildschirm teilt, wie in Abbildung 1 zu sehen ist. Mit dem Tab „YSlow“ lassen sich die einzelnen Funktionen dieses Plug-ins anzeigen und steuern. Nachdem man den Test mit „Run Test“ gestartet hat, wird die oben im Browserfenster stehende Seite analysiert und man erhält eine Einschätzung und viele nützliche Tipps zur Behebung von Flaschenhälsen.
Abbildung 2 zeigt die Filterung der Ergebnisse nach dem Klick auf „Content“ und den zweiten Menüpunkt „Reduce DNS lookups“ auf der rechten Seite. Dort erkennt man, dass die analysierte Seite Inhalte von sieben unterschiedlichen Domains einbindet. Dazu muss bei jedem Seitenaufruf siebenmal ein Domain Name Server (DNS) aufgerufen werden, der die eigentlichen Zieladressen (IP-Adressen) auflöst und zurückliefert. Ein Klick auf „Make fewer http requests“ (der erste Menüpunkt) zeigt dann zum Beispiel an, dass die deutsche Yahoo!-Startseite 19 externe Hintergrundbilder hat und empfiehlt, diese ggf. mit CSS-Sprites zu kombinieren. Alles in allem lohnt sich die Beschäftigung mit YSlow für Webmaster. Man erfährt viel und in komprimierter Form, was alles an der eigenen Website im Hinblick auf die Ladegeschwindigkeit optimierbar ist.
Bei den Google Webmaster Tools (www.google.com/webmasters/tools?hl=de) muss man sich zunächst als Webmaster gegenüber Google authentifizieren – falls man nicht schon einen Account angelegt hat. Die Neuanlage geht recht einfach, indem man eine vorgegebene Datei auf den eigenen Webserver hochlädt oder ein vorgegebenes Codeteil in den Head der Startseite einsetzt. Das wird auf den Seiten der Webmaster Tools ausführlich erklärt. Hat die Authentifizierung geklappt, bekommt man wertvolle Informationen, wie Google die eigenen Domains „sieht“. Seit Ende letzten Jahres hat Google unter dem letzten Menüpunkt „Google Labs“ den neuen Unterpunkt „Website-Leistung“ eingefügt. Dort wird eine Leistungsübersicht gezeigt, die in zwei Felder (oben: langsam; unten: schnell) geteilt ist. Bewegt sich der Graph wie in Abbildung 4, müssen Sie sich sicherlich keine Gedanken machen. Der Site-Betreiber aus Abbildung 3 sollte sich allerdings durchaus mittelfristig Gedanken zur Optimierung der Geschwindigkeit machen, denn einige Spitzen zeigen, dass der Server ab und zu überlastet ist.
Die Aufzeichnung und Darstellung über einen längeren Zeitraum ist sicher recht nützlich, weil man sowohl positive als auch negative Veränderungen gut und rechtzeitig erkennen kann. Zahlenangeben wie „Dies ist schneller als 88 % der Websites“ helfen bei einer vernünftigen Einschätzung auch Laien, die eigene Seite im Vergleich mit allen anderen Seiten zu bewerten.
Auch Google Webmaster Tools geben auf Einzelseitenbasis Hinweise, wie man diese Seiten schneller machen kann. Wie in der Abbildung 5 zu sehen ist, weist Google für die Seite „kontakt.html“ ein Potenzial zur Reduzierung der Dateigröße (und damit der Übertragungszeit) von 25,8 KB über das automatische Kompressionsformat Gzip aus. Weiterhin wird empfohlen, die Anzahl der DNS-Abfragen zu reduzieren und einige CSS-Dateien zusammenzufassen.
Auch Google bietet ein Browser-Plug-in namens „Page Speed“ an. Dieses ist ebenso wie das von Yahoo! über das Plug-in „Firebug“ wie oben bereits beschrieben aufruf- und steuerbar. Die Darstellung der Ergebnisse erscheint etwas übersichtlicher, bringt aber im Prinzip die gleichen Informationen wie YSlow.
Sowohl beide beschriebene Tools als auch die zugehörigen Webseiten (bei Yahoo! und den Google Webmaster Tools) bringen bereits viele nützliche Hinweise und Erklärungen, wie man die angezeigten Optimierungen durchführen kann. Den größten Effekt bringen in der Regel die folgenden Maßnahmen:
Gzip
Gzip funktioniert prinzipiell genauso wie die bekannteren Komprimierungsformate zip oder rar. Mit Gzip gelingt in der Regel eine Komprimierung einer zu übertragenden Webseite und zugehöriger Skripte um etwa 30 % bis 70 %. Eine Komprimierung von Bildern bringt nur sehr wenig Geschwindigkeitsvorteile, weil sie im üblichen Gif- oder Jpg-Format ja bereits komprimiert sind. Hier ließen sich aber Bilder in etwas höherer Qualität mit gleichem Volumen wie vorher übertragen. Da alle neueren und auch die älteren Browser Gzip unterstützen, gibt es damit keine Anzeigeprobleme – und an wirklich sehr alte Browser werden die Dateien automatisch unkomprimiert übertragen. Für eine Implementierung der Gzip-Komprimierung gibt es verschiedene Möglichkeiten. Die Einrichtung ist nicht sonderlich aufwendig, aber man benötigt dazu schon tiefer gehende Kenntnisse, sodass diese ein Experte vornehmen sollte.
Ob die Komprimierung funktioniert hat, können Sie direkt im Browser überprüfen. Laden Sie die entsprechende Webseite in den Firefox-Browser und rufen Sie den Menüpunkt „Extras/Seiteninformationen“ auf. Dort sehen Sie die Dateigröße. Sie sollte nun deutlich geringer sein als vor dem Einrichten der Komprimierung.
Lohnt sich der Aufwand tatsächlich? Diese Frage kann eine kleine Beispielrechnung verdeutlichen: Stellen Sie sich vor, Sie komprimieren nur die Startseite index.html und sparen damit 30 KB ein. Bei 5.000 Aufrufen dieser einzelnen Seite pro Tag macht das im Jahr über 50 GB Einsparung! Nimmt man alle Seiten einer mittelgroßen Webpräsenz mit nennenswertem Traffic dazu, summieren sich die Einsparungen schnell auf einige Terrabyte. Unabhängig vom nun schnelleren Aufbau der Webseiten durch das reduzierte Übertragungsvolumen, fällt die Abrechnung des Hostingproviders bei Volumentarifen damit deutlich geringer aus. Hier spart mal also je nach Vertrag auch noch ordentlich Geld.
Reduzierung der Bildergröße
Dass viele Bilder auf Webseiten noch viel zu opulent hochgeladen werden, dürfte hinlänglich unbestritten sein. Viele Webseiten zeigen bei Analysen, dass hier noch Potenzial schlummert. Dabei bieten fast alle gängigen Bildbearbeitungsprogramme gute Komprimierungstools an. Selbst das kostenlose Programm IrfanView (www.irfanview.net) wartet bei der Option „Speichern fürs Web“ mit beeindruckenden Einsparungen auf.
Wie die Speichergrößen des Originalbildes links (83,96 KB) im Vergleich mit der komprimierten Variante rechts (9,67 KB) zeigen (Abbildung 6), sind hier oft noch wirklich enorme Einsparungen erzielbar, ohne dass das menschliche Auge einen sichtbaren Qualitätsunterschied wahrnehmen könnte. Wer kein Tool auf den Rechner laden kann oder möchte, kann Bilder auch auf diversen Online-Plattformen einschrumpfen lassen. Schnell und zuverlässig funktioniert hier zum Beispiel Smush.it (www.smush.it), das bei Yahoo! auf den Developer-Networkseiten läuft. Dort gibt man die Webadresse (URL) eines Bildes ein und man erhält eine komprimierte Datei zum Download zurück. An die URL eines Bildes im Web kommt man am einfachsten, wenn man mit dem Mauszeiger im Firefox-Browser auf das entsprechende Bild geht und über die rechte Maustaste mit „Grafikadresse kopieren“ diese in den Zwischenspeicher nimmt.
Es bringt tatsächlich oft schon eine spürbare Entlastung des Webservers, wenn man nur die am häufigsten aufgerufenen Bilder (zum Beispiel von der Startseite oder Bilder, die auf jeder Seite angezeigt werden, wie das Logo) oder besonders große Bilder manuell nachkomprimiert. Probieren Sie das mal mit einigen Bildern Ihrer Website beispielhaft aus und rechnen Sie grob die oft erstaunlichen Einsparungseffekte hoch.
Auslagerung und Bereinigung von Skriptdateien
Kurze Programmierteile, die noch dazu für eine Webseite individuell sind und nur auf dieser Seite benötigt werden, gehören vernünftigerweise auch direkt in die HTML-Seite eingebunden. Umfangreichere Skriptanteile, die in der Regel auch auf anderen Seiten benötigt werden, sollte man unbedingt in eigene Dateien auslagern. Von dort werden sie beim ersten Aufruf vom Besucherbrowser geladen und verbleiben dann im Cache des Browsers. Damit müssen sie nur ein einziges Mal bei einem Besuch einer Website übertragen werden. Ist der Code jedoch standardmäßig zum Beispiel von einem Content-Management- oder Shop-System auf jeder einzelnen Seite im Code integriert, muss dieser Codebestanteil bei jedem Seitenaufruf jeweils neu mit übertragen werden! Eine größere Verschwendung von Zeit und Ressourcen ist wohl unschwer vorstellbar. Unabhängig davon wird das Code-Content-Verhältnis (also wie viel echter, vom Menschen lesbarer Content im Vergleich zur restlichen Programmierung der Seite) von Experten auch als Rankingfaktor angesehen. Je weniger Programmierung und je mehr lesbaren Text eine Seite hat, desto besser rankt sie unter Umständen. Und wenn hier auch vielleicht schon länger nur ein indirekter Zusammenhang besteht: Es ist nur ein weiterer Grund, Skriptcode und vor allem auch Formatierungsanweisungen (per CSS) auszulagern.
Einen kostenlosen Java-Script-Kompressor finden Sie unter http://javascriptcompressor.com und CSS-Dateien kann man ebenfalls kostenlos auf der Seite www.csscompressor.com einschrumpfen. Die oben beschriebene Firefox-Erweiterung Page Speed von Google findet übrigens auch ungenutzte – weil möglicherweise alte – Formatierungsdefinitionen in CSS-Dateien und gibt hierzu Hinweise: „38.8 % of CSS (estimated 105.3 kB of 271.4 kB) is not used by the current page“, auch beim Aufklappen die exakten Positionen. Auf den Codeseiten von Google findet man ein weiteres Tool namens „minify“, das für umfangreiche PHP-Seiten CSS, Java-Skript-Code und Caching optimiert und gleich gzip-codiert zur Verfügung stellt (http://code.google.com/p/minify).
Je mehr Links zu anderen Domains in einer Webseite integriert sind, desto mehr Anfragen muss ein Browser beim DNS (Domain Name Server) machen, um die dahinterliegenden IP-Adresse zu „erfragen“. Auch dies kostet wertvolle Zeit. Damit sind ausdrücklich nicht Links zu anderen Domains gemeint, sondern Objekte, die von anderen Servern geladen werden. Dies wird sich allerdings nicht immer vermeiden lassen. Wer allerdings mehrere Domains betreibt (zum Beispiel unterschiedliche Länderdomains) und Objekte wie Bilder aber von nur von einer („Mutter-“)Domain lädt, hat mit diesem Phänomen zu tun. Hier muss allerdings abgewogen werden. Die Vorteile, die das Kopieren aller gemeinsam benötigten Objekte auf die einzelnen Domains bringt, können sich schnell zum Nachteil auswirken, nämlich dann, wenn die Objekte einer häufigen Änderungsnotwendigkeit unterworfen sind. Dann müssen sie nämlich jeweils eben nicht mehr nur an einer zentralen Stelle geändert werden, sondern Kopien auf alle anderen Domains ausgerollt werden. Geschieht dies nicht automatisch und schleichen sich beim manuellen Handling Fehler ein, wird der Einsparungseffekt durch zum Beispiel fehlende oder falsche Bilder wohl mehr als überkompensiert.
Alles in allem gibt es noch eine Menge weiterer möglicher Maßnahmen zur Optimierung, wie die Nutzung von CSS-Sprites, Bildern und Videos auf schnelle Netzwerke auszulagern, das Browser-Caching zu optimieren oder die 404-Seitenfehler zu vermeiden. Weitere Hinweise für Profis finden Sie wie oben erwähnt auf den Seiten von Yahoo! und Google.
Wenn diese Optimierungsmaßnahmen nichts nützen und die Seiten danach in den Google Webmaster Tools noch immer als „langsam“ klassifiziert werden, bleibt in der Regel nur der Wechsel zu einem anderen, schnelleren Webserver. Unternehmen mittlerer Größe hosten ihre Webseiten häufig auf sogenannten virtuellen Servern. Das sind keine eigenen Server im physikalischen Sinn. Hier simuliert eine Software eine eigene Hardwareumgebung. In Wirklichkeit läuft diese virtuelle Umgebung oft mit Hunderten oder gar Tausenden anderen virtuellen Servern auf einem größeren System. Daran ist aus ökonomischer Sicht gar nichts auszusetzen. Befinden sich allerdings noch andere, fremde Webauftritte auf den gleichen System, die zufällig zu den gleichen Zeiten Spitzenlasten erzeugen, dann kann das temporär zu Flaschenhälsen bei der Auslieferung von Webseiten führen. Die Provider müssen natürlich ein wirtschaftliches Eigeninteresse haben, so viele Webpräsenzen wie möglich auf solche virtuellen Server zu legen. Der Reaktionsgeschwindigkeit ist das natürlich nicht gerade zuträglich. Solche Zielkonflikte lassen sich mit einem eigenen, gemieteten Server schnell auflösen. Hier befindet sich dann nur der eigene Webauftritt oder Shop auf dem System und man muss die verfügbaren Ressourcen nicht mit anderen – oft unkontrolliert – teilen.
Möglicherweise senden Sie mit einem eigenen Server und eigener IP-Adresse auch ein deutliches Signal für einen ernsthaft betriebenen Webauftritt an die Suchmaschinen? Die können nämlich problemlos auswerten, wie viele Domainadressen auf einer einzigen IP-Adresse gehostet werden. Und so wundert es auch nicht, wenn wissenschaftliche Analysen über Spam-Erkennung herausgefunden haben, dass gerade Spam-Seiten auf möglichst billigen Webspaces zu finden sind. Der Spitzenreiter ist dabei eine IP-Adresse, auf der sage und schreibe über neun Millionen Domains zu finden sind. Das kann man sich als Mega-Hochhaus vorstellen, in dem man Räume angemietet hat. Der eigene Server mit eigener Adresse ist daher vergleichbar mit einem Einfamilienhaus. Bei sogenannten Scoringanbietern, die für Webshops die Bonität potenzieller Kunden unter anderem aufgrund statistischer Daten prüfen, ist dies schon lange kein Geheimnis mehr: Bei realen Hausnummern, unter denen besonders viele Namen registriert sind, handelt es sich in der Regel um dicht besiedelte Hochhaus-Gegenden. Dort ist die Bonität bzw. die Anzahl der Zahlungsausfälle meist recht hoch. Selbstverständlich wird man ohne eigene IP-Adresse von Suchmaschinen nicht gleich in die Ecke zu Spammern gestellt, aber sie nehmen nach eigenen Angaben sehr viele Signale auf und verrechnen diese miteinander. Und es könnte durchaus sein, dass hier ein deutliches positives Signal in Richtung „Seriösität“ bzw. „Ernsthaftigkeit“ gesendet wird.
Übertriebene Hektik für den neuen Rankingfaktor „Geschwindigkeit“ ist sicher nicht notwendig. Vielmehr lohnen wohl eine besonnene Analyse der eigenen Seiten und das Ergreifen der am einfachsten umsetzbaren Gegenmaßnahmen. Die Suchmaschinen werden Websites nicht gleich aus dem Index werfen, nur weil sie zu lange laden – und wenn, dann wäre das sicherlich bereits passiert. Wer trotzdem keine Ergebnisposition nach unten wegen der eigentlich einfach zu optimierenden Geschwindigkeit verlieren möchte, dem sei zumindest mittelfristig das Handeln empfohlen. Und wer zusätzlich noch Adwords schaltet, bekommt wie eingangs beschrieben den Aufwand für Optimierungen der Geschwindigkeit oft recht schnell amortisiert.
Eine wichtige Gruppe wird einen schnelleren Seitenaufbau aber in jedem Fall positiv empfinden: die Besucher. Wenn man davon ausgeht, dass jeder Besucher nur eine begrenzte Zeit auf einer Website oder einem Shop verbringt, erhöht sich zumindest statistisch die Wahrscheinlichkeit, dass in dieser gleichen Zeitspanne mehr Seiten aufgerufen werden können. Und damit erhöht sich auch die Wahrscheinlichkeit, dass Suchende das finden, weswegen sie auf die Site bzw. in den Shop gekommen sind. Mittelbar trägt eine höhere Geschwindigkeit also auch hier zu positiven Effekten beim Umsatz bei. Wer sich als Experte diesem Thema professioneller und ausgiebiger widmen möchte, der findet in dem englischen Fachbuch „High Performance Web Sites“ von Steve Sounders weitere wertvolle Hinweise.
