Bei Websiten auf Enterprise-Niveau ist in letzter Zeit oft das Buzzword „high-performance sites“ zu hören. In meiner Rolle als technischer Web-Consultant natürlich ein Grund, mich damit näher auseinanderzusetzen. Zunächst muss man sich ja mal fragen, wie die Performance einer Website überhaupt zu definieren ist. Ist es nun die Zeit, die die Server benötigen, um das Markup und die Assets einer Seite – also Bilder, Stylesheets, Javaskripte, etc. – auszuliefern? Das ist natürlich das, was dem Techniker am naheliegendsten erscheint. Dem Internet-Nutzer in mir ist es allerdings zunächst wichtig, wie schnell eine Seite bedien- bzw. benutzbar ist.
Rufe ich also z.B. eine Seite der Wikipedia zu einem bestimmten Schlagwort auf, so ist es mir zunächst herzlich egal, ob alle Bilder zum Thema bereits geladen und sichtbar sind. Ich kann in dieser Zeit ja bereits den einleitenden Abstract zum Schlagwort lesen. In den meisten Fällen ist damit mein Wissensdurst befriedigt und ich habe das Ziel meiner Internet-Aktivität erreicht.
Wir sehen also auch hier, dass „high-performance“ als Attribut für eine Website nicht nur ein subjektives Maß ist, sondern auch bereits etwas mit Design und Konzeption der Website zu tun hat. Würde die Wikipedia nicht bereits am Anfang einer Seite eine kurze Zusammenfassung liefern, würde man vielleicht eher frustrierende Erfahrungen mit der Auslieferungszeit der einzelnen Seite machen.
Doch zurück zur Technik: Was kann ich denn nun als Webdesigner, -entwickler oder -projektleiter tun, um die Performance meiner Website zu erhöhen?
Ich möchte hier einmal die naheliegendsten und wichtigsten Techniken zur Beschleunigung einer Website vorstellen – eine vollständige und stets aktuelle Zusammenfassung würde den Rahmen dieses Artikels sprengen. Ich freue mich allerdings auf Anfragen und Diskussionen zu dem Thema!
Weniger HTTP-Requests
Natürlich freut sich jeder Webserver – ob Apache, IIS oder andere – wenn er weniger einzelne Requests abzuarbeiten hat. Ich gehe einmal davon aus, dass jedem, der diesen Artikel liest, die Trennung von Markup, Design und Verhalten einer Website in Fleisch und Blut übergegangen ist. Im Idealfall stelle ich nun nur eine Datei für das Design (*.css) und eine Datei für das Verhalten (*.js) zur Verfügung. Wenn ich diese Dateien dann noch serverseitig komprimiere (gzip, einfach den Admin fragen) und minifiziere, habe ich die Auslieferungszeit meiner Site schon deutlich erhöht.
CSS-Sprites
Meistens sind es aber die Bilddateien, die die vielen HTTP-Requests einer Seite auslösen. Wie kann man diesem Problem nun beikommen? Naja, was die redaktionellen Bilder betrifft kann man das natürlich nicht, was aber die Hintergrund- und Gestaltungselemente einer Website betrifft schon!
Der Trick besteht darin, statt vieler einzelner Bildteile ein einziges großes Bild zu verwenden. Dieses enthält alles, was die Site benötigt, also z.B. abgerundete Ecken, Hintergrundgrafiken, Pfeile für Bildergalerien und „mehr“-Links, etc. Über entsprechende CSS-Angaben (background-image, background-position, etc.) lässt sich dann das große Bild ausschnittweise in die Website einbinden.
Wer genau wissen will, wie das funktioniert, sollte sich diesen Artikel über CSS-Sprites von Chris Coyier durchlesen.
Ein weiterer Trick, um die Anzahl von HTTP-Requests bei Bildern zu reduzieren, ist die Verwendung von ImageMaps.
Content Delivery Networks
Für Websites, die international genutzt werden, ist ein Content Delivery Network (CDN) eine sehr gute und naheliegende Option. Vereinfacht gesagt, bringt ein CDN die Anfragen möglichst in die Nähe des Benutzers. Die Dateien der Website werden über den Globus verteilt und sind somit entsprechend aus der Nähe verfügbar.
Gutes Markup
Dass gutes Markup in der Entwicklung von Websites wichtig ist, sollte jedem Webdesigner und -entwickler ohnehin klar sein. Jedoch wird auch die Ladezeit einer Seite erheblich von der Anzahl der DOM-Elemente beeinflusst. So, wie früher verschachtelte Tabellen eigentlich nur eine Krücke waren, um ein umständliches Webdesign zu realisieren, können viele verschachtelte div-Elemente auch ein Anzeichen dafür sein, dass das Design oder das Markup einer Seite zu komplex ist und den Browser beim Rendern unnötig Zeit kostet. In jedem Fall sollte man sich bei jedem DOM-Element – insbesondere bei divs und spans – fragen, ob man das wirklich benötigt, oder ob es nicht noch einen eleganteren Weg zur Umsetzung gibt.
Aber warum jetzt das Ganze?
Es gibt noch eine ganze Menge wichtiger Faktoren, die die Ladezeit einer Seite verringern können. Ich hatte eingangs erwähnt, dass dieser Artikel nicht den Anspruch erhebt, eine vollständige Checkliste zu sein.
Er sollte vielmehr ein Bewusstsein dafür schaffen, dass das Thema „Ladezeiten“ immer noch ein sehr wichtiges ist. Gerade wir Web-Entwickler hatten oft geglaubt, durch die immer größere Verbreitung von Breitband-Verbindungen dieses lästige Kapitel abschliessen zu können.
Das Internet ist aber immer noch ein sehr schnellebiges Medium, in dem der Benutzer schnell auf die Shop-Seite der Konkurrenz wechselt, wenn ihm der Seiten-Aufbau zu lange dauert. Gerade SmartPhone-Benutzer wissen, wovon ich hier rede.
Untersuchungen großer Shops und Websites haben sogar Messungen durchgeführt, wie viel Umsatz sie verlieren, wenn sie die Auslieferungszeit ihrer Sites verringern. Die Zahlen sind beeindruckend.
Aber auch für kleine Sites kann es einen Wettbewerbsvorteil darstellen, agil und schnell daher zu kommen. Denn bei den meisten Websites gilt noch immer: Content is king!
