Schnelle Ladezeiten einer Website sind mittlerweile weit mehr als Nice-to-have. Für Google ist die Ladegeschwindigkeit einer Website seit gewisser Zeit sogar ein Rankingfaktor. Bereits mit einfachen Eingriffen an der Website kann man einiges an Bandbreite einsparen und so die Ladegeschwindigkeit verbessern. Im folgenden Artikel werden mögliche Mittel und Wege vorgestellt, wie man erkennen kann, ob eine Website zu langsam ist, und wie man dieses Problem löst.
Im April 2010 wurde von Google offiziell bekannt gegeben, dass die Ladegeschwindigkeit einer Website bei der Bewertung der Suchmaschinenrankings eine Rolle spielt. Google gab zwar damals an, dass weniger als 1 % der Suchanfragen betroffen seien, jedoch ist dies schon über ein Jahr her. In der seitdem vergangenen Zeit wird Google diesen Rankingfaktor sicherlich weiter verfeinert haben und man kann davon ausgehen, dass die Ladegeschwindigkeit mittlerweile eine etwas größere Rolle für gute Rankings spielt. Im Verhältnis zu anderen Rankingfaktoren wie z. B. Backlinks wird diese Rolle jedoch weiterhin sehr gering sein. Vor allem bei stark umkämpften Keywords wird die Ladegeschwindigkeit einer Website bei der Rankingbewertung berücksichtigt. Bei suchvolumenstarken Keywords wie z. B. „Private Krankenversicherung“ entscheiden oft nur Nuancen, auf welcher Position eine Website bei Google gefunden wird. Genau für solche Fälle hat Google mit dem Website-Speed eine weitere Bewertungsmöglichkeit.
Kurz nach der Veröffentlichung des neuen Rankingfaktors nahm damals sogar der oberste Google-Geheimniswächter Matt Cutts zu dem Thema Website-Speed Stellung. In einem Blogartikel ging er verstärkt darauf ein, dass dieses neue Rankingkriterium erst einmal nichts Weltbewegendes sein werde. Vielmehr versuchte er zu erklären, dass Website-Speed im Interesse aller sei und Google deshalb hier als Vorreiter agiere. Wie wichtig das Thema Ladegeschwindigkeit bei Google wirklich ist, sieht man nicht zuletzt daran, dass immer neue Tools und Features von Google zur Verfügung gestellt werden, die beim Speedboosten einer Website helfen. Hierzu zählt unter anderem auch der im August vorgestellte Page-Speed-Service von Google, der Websites bis zu 60 % schneller machen soll.
Eine schnelle Website allein ist jedoch weiterhin bei Weitem nicht der heilige Gral für Top-Rankings. Der Hauptgrund, warum man seine Website überhaupt beschleunigen sollte, ist nämlich nicht unbedingt der zu erwartende Vorteil im Ranking. Vielmehr sollten die Ladezeiten für die eigenen Website-Besucher geboostet werden. Eine langsame Website macht niemandem Spaß und führt zwangsläufig dazu, dass die Besucher unzufrieden werden und eventuell die Website oder den Onlineshop in Zukunft meiden. Bei Onlineshops haben verschiedene Tests auch schon gezeigt, dass die Konversionsraten bei schneller ladenden Seiten tendenziell sogar höher sind. Auch dieser Grund spricht für eine geschwindigkeitsoptimierte Website und sollte deshalb nicht außer Acht gelassen werden.
Google spricht bezüglich der allgemeinen Zufriedenheit der User auch immer wieder von der sogenannten User Experience. Zu diesem Nutzererlebnis gehören das Look & Feel einer Website und vor allem die Usability, also die Benutzerfreundlichkeit.
Diesen Leitsatz verfolgt Google selbst, indem die am besten passenden Suchergebnisse zu einem Begriff möglichst schnell und einfach angezeigt werden sollen. Um also den Usern das bestmögliche Nutzungserlebnis zu bieten, muss eine Website unter anderem auch eine angemessene, schnelle Ladezeit besitzen.
Einen weiteren Grund, warum man seine Website beschleunigen sollte, zeigt Deutschlands größte Studie zur Internetnutzung, der sog. (N)Onliner Atlas 2011. Diese jährliche Studie wurde von der Initiative D21 unter anderem mit dem Bundesministerium für Wirtschaft und Technologie durchgeführt. Laut dieser Untersuchung sind in Deutschland aktuell 52,7 Millionen Menschen über 14 Jahren online. Ganze 15,9 % sind jedoch auch heute noch mit Schmalband, also ISDN oder Modem, unterwegs. Dies bedeutet, dass momentan noch über acht Millionen potenzielle Kunden mit einer sehr langsamen Leitung im Netz surfen. Nicht zu vergessen ist auch die stetig steigende Anzahl an Nutzern des mobilen Internets. Bekannterweise lässt auch hier häufig die Geschwindigkeit zu wünschen übrig. Mit der Geschwindigkeits-Optimierung der Website kann man auch für diese Nutzer ein angenehmes Nutzungserlebnis schaffen und eventuell dadurch sogar Neukunden gewinnen.
Über acht Millionen Deutsche surfen aktuell noch mit einer Schmalband-Internetverbindung!
Im Mai dieses Jahres hat Google eine sehr nützliche Funktion für Google Analytics veröffentlicht, mit deren Hilfe man die Website-Geschwindigkeit der eigenen Site messen kann. Um dieses neue Feature nutzen zu können, muss man lediglich den Google Analytics Code um eine Zeile erweitern und die Funktion „trackPageLoadTime“ einfügen.
Bei richtiger Implementierung des Codes erscheint nach spätestens 24 Stunden im Analytics-Account die Funktion Website-Geschwindigkeit. Der Google Analytics-Account muss jedoch vorher auf die neue Benutzeroberfläche umgestellt werden. Wenn dies noch nicht geschehen ist, findet man im rechten oberen Bereich den Hinweis „Neue Version“. Sobald die Benutzeroberfläche umgestellt ist, erscheint unter dem Punkt „Content“ der Menüpunkt „Website-Geschwindigkeit“.
Diese Trackinglösung hat den Vorteil, dass die Geschwindigkeit direkt beim Nutzer gemessen wird. Somit werden alle Verbindungsgeschwindigkeiten bei der Messung berücksichtigt, mit denen die User auf der Website unterwegs sind. Als Ladezeit zählt dabei der komplette Aufbau der Seite. Es müssen also alle Elemente der Seite vollständig geladen werden, erst dann wird die Ladezeit gestoppt. Google misst jedoch nicht bei jedem Aufruf die Geschwindigkeit. Es werden nach dem Stichproben-Prinzip ungefähr 2 % der gesamten Seitenaufrufe von Google gemessen.
Wie auf Abbildung 5 zu sehen, werden die Ladezeiten für jede URL einzeln angezeigt. Dies ist sehr praktisch, da so die Diagnose vereinfacht wird. Man hat somit die Möglichkeit, Unterseiten zu identifizieren, welche Performance-Probleme haben, und diese gezielt zu optimieren. Weiterhin werden auch noch die Absprungraten und die prozentualen Ausstiege jeder URL angezeigt. Dadurch hat man einen Überblick und kann einschätzen, ob eine hohe Absprungrate eventuell direkt mit einer zu langsam ladenden Seite zusammenhängt. Für die grafische Darstellung wird täglich ein Mittelwert gebildet und im Verlauf angezeigt. Was leider fehlt, ist die Betrachtung eines einzelnen Tages mit Uhrzeiten. Mit solch einer Darstellung könnte man analysieren, ob der Server bei hohen Zugriffszahlen Probleme mit der Performance bekommt. Wer solch detaillierte Auswertungen benötigt, muss auf externe Performance-Monitoring-Tools wie z. B. Gomez (www.gomez.com) zurückgreifen.
Mit den Webmaster-Tools stellt Google ein weiteres Tool zur Verfügung, mit dem man die Ladezeit seiner Website herausfinden kann. Die Webmaster-Tools können jedoch noch viel mehr und aus diesem Grund sollte sie eigentlich jeder Website-Betreiber „installiert“ haben. Mit den Tools kann man sehr viele nützliche Informationen wie z. B. Crawling-Statistiken über seine Website herausfinden und Anweisungen an Google übergeben. Hierzu gehört z. B. das Einstellen der Google Sitelinks oder das Einreichen von XML-Sitemaps.
Um die Google Webmaster-Tools nutzen zu können, muss man sich auf www.google.de/webmasters/tools einen Account einrichten. Bevor die Webmaster-Tools jedoch genutzt werden können, muss die Website authentifiziert werden. Dies geschieht z. B. über den Upload einer von Google bereitgestellten HTML-Datei auf den Webspace. Die zweite Möglichkeit ist das Einbinden eines speziellen Codeschnipsels namens „google-site-verfication“ in den Meta-Angaben der Website. Somit weiß Google, dass man Zugriff auf die Website hat, und nach erfolgreicher Überprüfung, wird der Zugriff auf die Webmaster-Tools gewährt.
Unter dem Punkt Google Labs befindet sich die Funktion Website-Leistung. Nach dem Aufruf der Funktion findet man eine grafische Darstellung, die im zeitlichen Verlauf die Ladegeschwindigkeit der Website aufzeigt.
Die im Beispiel gezeigte Website lädt im Schnitt 2,0 Sekunden. Nach Angaben von Google lädt diese Seite also schneller als 69 % aller Websites im Netz. Obwohl dies eigentlich nicht einmal so schlecht ist, wird diese Seite trotzdem noch als „langsam“ eingestuft. Für Google ist eine Seite nämlich erst schnell genug, wenn diese sich unter 1,5 Sekunden aufbaut. Dies erreichen laut Aussagen von Google gerade einmal 20 %. Auch daran erkennt man, wie ernst es Google mit dem Thema Site-Speed nimmt.
Die Daten für diese Auswertung erhebt Google über die hauseigene Toolbar und genau hier liegt auch schon das Problem. Google hat bei dieser Messung nur Daten von Usern, welche die Google Toolbar installiert haben. Und wer hat das schon? Hauptsächlich wohl internetaffine Nutzer. Somit ist die Stichprobe wahrscheinlich nicht besonders repräsentativ.
Aus diesem Grund weichen auch die gemessenen Zeiten von Analytics und die aus Webmaster-Tools zum Teil massiv voneinander ab. Google gibt jedoch auch in den Webmaster-Tools an, wie genau die vorliegenden Daten sind. In dem Beispiel liegen Google mehr als 1.000 Datenpunkte vor. Deshalb haben die Schätzungen eine hohe Genauigkeit. Bei kleineren Websites, welche nicht so viel Traffic bekommen, können die Daten unter Umständen nicht so genau bestimmt werden.
Weiterhin werden unter der Grafik Beispiel-Ladezeiten einzelner URLs angezeigt, wie bei Google Analytics. Es werden hier jedoch nur ein paar Beispiele aufgelistet, einen kompletten Überblick aller URLs bekommt man über die Google Webmaster-Tools nicht. Für einen schnellen und groben Überblick reicht die Funktion Website-Leistung der Google Webmaster-Tools auf alle Fälle aus. Wenn man jedoch genauere und umfassendere Daten benötigt, sollte man die Google Analytics-Methode nutzen.
Eine weitere Möglichkeit, die Geschwindigkeit einer Webseite zu überprüfen bzw. einzustufen, ist das von Google zur Verfügung gestellte Page Speed. Was vor zwei Jahren als Browser-Extension für Firefox bzw. Firebug begann, hat seitdem eine gehörige Weiterentwicklung erfahren. So wurde wenig später sogar das Apache-Modul mod_pagespeed entwickelt, welches als Apache-Erweiterung eingesetzt werden kann. Mithilfe dieser Erweiterung sollen Seiten schon optimiert ausgegeben werden. Mittlerweile kann man Google Page Speed auch direkt online unter pagespeed.googlelabs.com nutzen und als Entwickler sogar die API dazu verwenden, um die Ausgaben des Tools weiterzuverarbeiten. Was aber macht Page Speed genau?
Kurz gesagt überprüft das Tool die Webseite hinsichtlich einiger vorher definierter Regeln, die Google als wichtig erachtet. Darunter fallen Klassiker wie:
Das ist jedoch lediglich eine kleine Auswahl an Faktoren, welche von Page Speed überprüft werden. Bewertet wird auf einer Skala von 0–100 Punkten, wobei 100 Punkte erwartungsgemäß den Idealwert darstellen.
Um einen Test zu starten, benötigt man im Firefox lediglich die Firebug-Extension und eben die Erweiterung Page Speed (code.google.com/intl/de-DE/speed/page-speed/download.html). Man besucht die Website, welche man analysieren möchte, und startet das Tool.
Bereits wenige Sekunden nach dem Start des Tools erhält man eine Liste mit möglichen Verbesserungsvorschlägen. Jedes dieser Elemente ist auch der Priorität nach geordnet. Man weiß sofort, welche Möglichkeiten priorisiert angegangen werden sollten. Dies sind allerdings auch nur Vorschläge von Google. Wie viel schneller die Webseite am Ende wirklich ist, kann vorher natürlich nicht festgestellt werden. Möchte man diese Werte noch einmal vergleichen, kann man alternativ auch das von Yahoo! zur Verfügung gestellte Firebug-AddOn YSlow nutzen. Wie der Name schon verrät (Why slow? – Warum langsam?) zeigt dieses Tool ebenfalls Gründe für langsame Ladezeiten, ähnlich wie Googles Page Speed.
Die eben genannten Browser-AddOns und Analyse-Werkzeuge helfen dabei, langsame Ladezeiten überhaupt zu erkennen. Nachfolgend werden nun Optimierungsmöglichkeiten für den Site-Speed vorgestellt. Um hier einen guten Einstieg in die Ladezeiten-Optimierung zu haben, darf es an etwas grundlegender Theorie nicht fehlen.
Mit jedem Element, das eine Webseite lädt bzw. laden muss, wird ein sogenannter HTTP-Request gestartet. Nach den Spezifikationen des HTTP-Protokolls können zwar mehrere Dateien parallel von einem Hostnamen geladen werden, allerdings liegt die Anzahl der parallelen HTTP-Requests zwischen vier und sechs (siehe Quelle: www.browserscope.org/?category=network&v=top). Ein Flaschenhals ist quasi vorprogrammiert. Sobald vier bzw. sechs Elemente geladen werden, müssen nachfolgende Elemente warten. Ein weiterer Faktor, der sich auf die Geschwindigkeit der Webseite auswirkt, ist die zu übertragende Datenmenge. Gerne werden hochaufgelöste Bilder genutzt oder mehrere JavaScripts oder Cascading Stylesheets (CSS) in den Browser geladen, welche zusätzliche Datenmengen darstellen. Benutzer von Content-Management- bzw. Blog-Systemen wie z. B. Wordpress oder Typo3 haben aufgrund deren Komplexität zudem einen erhöhten Zugriff auf die Datenbank. Jeder Aufruf an die Datenbank kostet zusätzlich Zeit. Die hauptsächlichen Ziele der Optimierung kann man daher ganz klar definieren:
Die Dimensionen der Bilder einer Website sollten nicht nur durch die Width- und Height-Angaben im HTML-Quelltext skaliert werden. Sie sollten auch direkt in der Größe auf dem Server abgespeichert sein, die in diesen Attributen angegeben ist, denn wenn man die Größenangabe der Bilder per Hand – also mit den Width- und Height-Attributen – ändert, wird das Bild erst im Browser gerendert. Speichert man das Bild direkt im passenden Format, kann es von den Browsern direkt ausgegeben werden. Dies spart mitunter nicht nur Zeit für das Rendern, sondern in den meisten Fällen auch Speicherplatz. Damit das Rendern des Browsers schneller vonstatten geht, sollte man generell die Größenattribute mit in die Bildangaben (img-Tag) setzen. So wird der Platz für das Bild quasi schon vorab „reserviert“ und muss nicht erst gesondert berechnet bzw. gerendert werden. Dies sieht man z. B., wenn man auf News-Seiten auf Bilder wartet, das Layout aber schon vorher fertig steht. Sind diese Attribute nicht gesetzt, sieht man hin und wieder, dass sich der Content entsprechend verschiebt bzw. positioniert.
Vor allem die Größe der Bilder spielt bei der Optimierung eine große Rolle. Die meisten Bildbearbeitungsprogramme wie z. B. Adobe Photoshop oder die Open-Source-Software Gimp speichern neben dem eigentlichen Bild noch jede Menge Meta-Daten mit ab. Die Bilder werden dadurch unnötig aufgeblasen. Hier kann man nur durch Entfernen dieser Meta-Daten noch einmal einiges an Bandbreite sparen. Für diese Aufgabe hat sich vor allem der Dienst smushit.com von Yahoo! etabliert. Dieser Dienst entfernt nicht benötigte Daten aus den Bildern. Dabei muss man beachten, dass das Bild an sich nicht verändert wird. Bei der Bildqualität müssen somit keine Abstriche gemacht werden, da lediglich sogenannte Header-Informationen aus den Bildern entfernt werden. Für einige Content-Management-Systeme wie etwa Wordpress gibt es bereits Plugins, die beim Hochladen von Bildern diese automatisch mithilfe von Smush.it optimieren. Aktuell gibt es aber noch keine offizielle API (Stand August 2011), daher ist man gezwungen, den Uploader der Webseite zu nutzen. Alternativ kann man auch ein URL-Set übergeben, um Zeit beim Hochladen zu sparen. Die von Shmush.it optimierten Bilder können dann anstelle der Originale verwendet werden und schon hat man wieder ein paar Sekundenbruchteile an Ladezeit eingespart. In dem in Abbildung 11 gezeigten Beispiel konnten bei einem Bild sogar fast 99 % an Speicherplatz eingespart werden. Dieses Bild ist eine Länderflagge für die Sprachumschaltung und ist so aktuell auf einer Website online. Von solch einem großen Einsparungspotenzial darf man jedoch nicht zwangsläufig ausgehen. Wenn allerdings über die Masse an Bildern pro Bild ca. 1–5 % eingespart werden können, ist das schon ein guter Wert. Vor allem für Onlineshops, die viele Produkte und somit Bilder haben, ergibt sich hier ein enormes Einsparungspotenzial. Generell kann man behaupten, dass Bilder häufig das größte Potenzial bieten, um Bandbreite und damit wichtige Zeit beim Laden einer Seite zu sparen.
Was auf den ersten Blick schwierig und nach viel Arbeit klingt, lässt sich je nach Projekt und genutztem Content-Management-System recht schnell und zum Teil ohne großen Aufwand umsetzen. Um sich noch einmal mehr zu verdeutlichen, wie viele Daten eigentlich bei einem einzigen Aufruf vom Server geladen werden, kann man Tools wie das schon vorgestellte Google Page Speed oder Yahoo! YSlow nutzen.
In dem gezeigten Beispiel werden aktuell sieben Stylesheets geladen. Damit diese sieben CSS-Dateien vom Server geladen werden können, sind insgesamt zwei HTTP-Requests nötig (ausgehend von sechs gleichzeitigen Requests von einem Host). Das Optimierungspotenzial besteht also darin, die Dateien zum einen in der Datengröße zu verkleinern und zum anderen in so wenig Dateien wie möglich zusammenzufassen.
Je moderner und technisch anspruchsvoller eine Webseite ist, desto mehr CSS-Anweisungen werden in der Regel benötigt. So hat man dann z. B. eigene Anweisungen für den Bild-Slider und noch mal eine eigene CSS-Klasse für die Lightbox, um die Bilder möglichst schön darzustellen. In den meisten Fällen haben sich die Programmierer einen einheitlichen Schreibstil für CSS angewöhnt, den man leicht lesen, erfassen und pflegen kann. Eine Klasse ist demnach meist nach folgendem Schema aufgebaut:
#id-name {
Anweisung 1: Werte für Anweisung 1;
Anweisung 2: Werte für Anweisung 2;
}In dem Code einer CSS-Datei würden hier z. B. Ausrichtungs-Anweisungen wie border-left stehen. Egal, wie einfach die Anweisungen sind, gibt es auch hier schon Potenzial, um die Datenmenge insgesamt zu verringern. So kann man die kompletten Anweisungen in einer einzigen Zeile schreiben. Im oberen Beispiel könnten dadurch bereits drei Zeichen eingespart werden. Bei einer CSS-Datei mit mehreren Tausend Zeilen an Code kann man hier nur durch Entfernen unnötiger Leerzeilen und das Zusammenfassen der Anweisungen in einer einzelnen Zeile eine nicht unerhebliche Reduzierung der Datenmenge herausholen.
Um noch zusätzlichen Speicherplatz und damit entsprechend Bandbreite zu sparen, sollten die unnötigen und doppelt deklarierten Anweisungen im Code entfernt werden. Oft werden CSS-Anweisungen beibehalten, die es so auf der Webseite nicht mehr gibt. Dies kommt oft in Content-Management- oder auch Shop-Systemen vor, in denen es meist schon eine CSS-Datei gibt. Diese findet man z. B. in Wordpress in Form der stylesheet.css. Hier lohnt es sich wirklich nachzuforschen, ob evtl. ganze Blöcke erst gar nicht geladen werden. Diese kann man dann guten Gewissens aus dem Stylesheet entfernen. Nicht selten spart man sich hier mehrere Kilobyte an Speicher, die am Ende nicht übertragen werden müssen. Dabei muss man nicht mal mehr CSS-Dateien doppelt speichern, um diese später einfacher zu pflegen. Viele Entwicklungsumgebungen, wie etwa Coda auf Mac-Systemen, bieten nämlich bereits solch eine Funktion out-of-the-box an.
Zusätzlich zu der Datenmenge kann man bei den CSS-Dateien auch noch HTTP-Requests einsparen. Der Trick ist, die Dateien so weit zusammenzufassen, wie es nur geht, beispielsweise aus vier CSS-Dateien eine zu machen. In den meisten Fällen kann man den gesamten CSS-Code in eine einzelne Datei packen. So werden vier HTTP-Requests auf einen reduziert und die Seite lädt schneller.
Wer sich tiefer mit CSS auseinandersetzt, wird früher oder später auf den Begriff Shorthand-Anweisungen treffen. Dies ist nichts anderes als eine verkürzte Schreibweise für CSS-Anweisungen. Anwendungsmöglichkeiten dafür gibt es viele. So können beispielsweise komplexe Angaben zu Abständen und Positionierungen extrem verkürzt werden. Statt einzeln margin-left, margin-right etc. aufzurufen, schreibt man alles in eine Zeile. Dies kann dann wie folgt aussehen.
margin: 0px 0px 2px 3px;
Die Anweisung würde bewirken, dass oben wie rechts keinerlei Abstand zum nächsten Element besteht. Unterhalb wären jedoch zwei und links drei Pixel Abstand zum nächsten Element vorhanden. Ohne diese Kurzanweisung hätte man vier Codezeilen gebraucht. Je nachdem, wie viele Pixel eine Anweisung hat, kann man die Anweisung gegebenenfalls noch weiter verkürzen. Ein brauchbares Cheatsheet für Shorthand-Anweisungen findet man auf www.leigeber.com/2008/04/css-shorthand-cheat-sheet/.
Um das Ganze noch auf die Spitze zu treiben, beherrschen mittlerweile viele Entwicklungsumgebungen das Minimieren von Stylesheets. Hier werden am Ende alle Möglichkeiten ausgeschöpft, um noch einzelne Kilobytes einzusparen. Darunter fallen Optimierungen wie z. B. das Entfernen aller Leerzeichen, sofern man dies bei den händischen Optimierungen nicht sowieso schon gemacht hat.
Ein weiteres sehr interessantes Thema im Bereich CSS und Minimierung der HTTP-Requests ist das Zurückgreifen auf sogenannte CSS-Sprites. Die Theorie ist denkbar einfach. Alle grafischen Elemente, die sich ohnehin wiederholen, werden in einer gesammelten Bilddatei gespeichert. Somit muss für das Laden der grafischen Elemente einer Website nur noch ein HTTP-Request gemacht werden und nicht mehr für jedes Bildchen ein eigener.
Der anzuzeigende Ausschnitt wird mittels CSS-Anweisung im Browser ausgegeben. Somit kann die Anzahl der Requests sehr schnell reduziert werden, indem man effektiv nur ein einziges Bild, beispielsweise für die Navigation, lädt. Große Onlineshops wie Amazon gehen hier mit gutem Beispiel voran (siehe Abbildung 9). Die Erstellung von CSS-Sprites ist mittlerweile recht einfach geworden, da es auch schon Automatisierungs-Tools im Web gibt. Hierzu zählt unter anderem der CSS-Sprites-Generator von csssprites.com. Dieser Generator macht im Prinzip nichts anderes, als die hochgeladenen Bilder in einer Datei zusammenzufassen. Die Bilder müssen anschließend über Background-Anweisung im CSS definiert werden. So kann der Browser interpretieren, an welcher Stelle der Website welche Position des Bildes angezeigt wird. Man gibt somit lediglich die Position des Ausschnitts an, welcher angezeigt werden soll. Eine gute Einleitung in das Thema CSS-Sprites in deutscher Sprache findet man auf www.webanhalter.de/1368-css-sprites.html.
Wer seine Seite noch weiter optimieren möchte, kann auch auf Content-Delivery- bzw. Content-Distribution-Netzwerke (CDN) zurückgreifen. Ein CDN stellt Daten je nach Ort des Users bereit. Sitzt man beispielsweise in Frankfurt, wird man von einem Server aus Frankfurt oder Umgebung „beliefert“, wogegen User aus den Staaten von einem Server aus den USA den Content erhalten. Der bekannteste Vertreter ist das Amazon S3 CDN. Moderne Content-Management-Systeme können standardmäßig mit CDNs umgehen. Bilduploads erfolgen dann auch automatisch auf das vorher eingestellte CDN.
Auch Google bietet seit Kurzem mit dem Google Page-Speed-Service ein eigenes CDN an. Hier wird versprochen, dass Inhalte bis zu 60 % schneller ausgeliefert werden als auf normalen Webservern. Auf den Servern von Google werden alle wichtigen Schritte durchgegangen, die zum Beschleunigen der Seite wichtig sind. Die Google-Server kümmern sich also darum, dass CSS-Dateien sowie Javascript-Dateien bereits zusammengefasst werden. Auch Bilder werden direkt in das passende Format optimiert. Um die Geschwindigkeit noch weiter zu erhöhen, verteilt Google die Daten auf verschiedene Server im eigenen CDN, sodass mehrere Dateien parallel geladen werden können.
Die Abbildung 12 stellt grafisch die Arbeitsweise eines Content Delivery Networks dar. Ziel eines CDN ist es, Daten auf kürzestem Weg im Browser des Besuchers anzuzeigen. Dazu werden die CDN-Server weltweit regelmäßig synchronisiert, sodass am Ende von jedem Server dieselben Daten ausgeliefert werden können.
Die meisten Optimierungsmöglichkeiten, um HTTP-Requests zu minimieren, bieten vor allem Templates von Content-Management-Systemen. Vor allem das CMS Wordpress kann hier großes Potenzial vorweisen. In vielen Template-Systemen verwendet man dynamische Anweisungen wie z. B. bloginfo(‘blogname‘), um lediglich den Titel bzw. den Namen des erstellten Blogs auszugeben. Wenn sich der Blog-Name ändert, würde die dynamische Anweisung diesen automatisch ändern. Aber mal ehrlich, wie oft ändert sich ein Blog-Name? Um zu verstehen, dass es hier Einsparpotenzial gibt, muss man über ein wenig Hintergrundwissen verfügen. Wird ein dynamischer Befehl aufgerufen, wird erst eine Verbindung zur Datenbank aufgebaut (Schritt 1). Anschließend wird eine Abfrage an die Datenbank gestellt (Schritt 2) und auf das Ergebnis gewartet. Dieses Ergebnis wird wiederum an das Template-System zurückgegeben (Schritt 3) und erst dann ausgegeben (Schritt 4). Effektiv ergeben sich daraus vier Teilschritte. Um sich diese zu sparen, kann man auch lediglich direkt den Namen als HTML-Code eingeben, anstatt auf dynamische Funktionen zurückzugreifen. Das Ergebnis wird also unmittelbar ausgegeben, ohne dass erst Verbindungen unnötig aufgebaut werden müssen. Diese Vorgehensweise lässt sich auf fast alle verfügbaren Systeme übertragen, da jedes CMS mit dynamischen Anfragen arbeitet.
HTTP-Requests lassen sich allerdings auch schon beim Erstellen von CSS- und Javascript-Dateien reduzieren. Auch wenn es wegen der Übersicht einfacher ist, Navigation und Content-Anweisungen in zwei separate Dateien zu packen, sind es dann immer noch zwei Requests. Packt man diese stattdessen in eine einzelne Datei, hat man lediglich noch einen einzigen Request. Es spricht absolut nichts dagegen, eine einzelne .js-Datei mit einer Funktionsbibliothek einzubinden, welche dann mittels Skript-Aufruf im Quellcode geladen wird. Wo allerdings sollten die Sachen im Quellcode stehen, um den besten Effekt zu erhalten?
Grundsätzlich stehen CSS-Anweisungen im Header und Javascript-Anweisungen kurz vor dem schließenden Body-Tag. Zwar kann man diese komplett in den Header setzen, allerdings birgt das einen entscheidenden Nachteil. Javascript-Dateien werden erst fertig geladen, bevor die Seite weiter gerendert wird. Bei fünf zu ladenden Javascripts, was in Zeiten von jQuery, mootools und Prototype Standard ist, muss der Browser demnach fünfmal das Laden des HTML-Quelltextes abbrechen, um die Dateien einzulesen. Beim Rendern der Seite wird man auch noch keine Web-2.0-Features benötigen, von daher können diese problemlos erst am Ende der Seite platziert werden. Damit geht nicht nur das Laden schneller, der vermeintliche Besucher sieht auch sofort den Text und weiß, ob er das findet, was er gesucht hat.
Der eine oder andere wird das Wort „minify“ bestimmt schon einmal gehört haben. Minify ist ein Tool, mit dem CSS-und Javascript-Dateien auf recht einfache Weise kombiniert und optimiert werden können. Hier werden beispielsweise Javascript-Dateien kombiniert und auf eine einzelne Datei reduziert.
Ebenso werden Leerzeichen und Leerzeilen entfernt. Genauso wird mit CSS-Dateien verfahren. Dieses Skript lässt sich problemlos überall einbauen. Für die meisten Content-Management-Systeme gibt es bereits fertige Plugins und Addons. Sogar für das Shop-Ungeheuer Magento gibt es ein Minify-Skript namens „Foomans Speedster“. Ein weiterer Vorteil des minify-Pakets ist das Cachen der Dateien. So können diese noch wesentlich schneller geladen und ausgeliefert werden. Für weitere Informationen sollte man code.google.com/p/minify/ einen Besuch abstatten.
Auch wenn die Website-Geschwindigkeit weiterhin nicht das Allheilmittel für gute Rankings darstellt, sollte man sich diesem Thema ausführlich widmen. Wenn auch zwangsläufig nicht sofort Rankingverbesserungen eintreten, werden es einem die Website-Besucher sicher danken. Da Google in letzter Zeit viele neue Features zum Thema Page Speed veröffentlicht hat, ist auch davon auszugehen, dass der Faktor Ladegeschwindigkeit in Zukunft noch stärker bei der Rankingbewertung gewichtet wird. Wer noch tiefer in die Materie einsteigen möchte, sollte sich mit Themen wieOpcache, Datenbanktuning oder gzip beschäftigen.