tas2580
Blog über Webentwicklung

Webseiten schneller machen

tas2580  

Es gibt mehrere Studien die zeigen das Besucher auf schnellen Webseiten länger bleiben und öfter wieder kommen, als Besucher gibt es auch nichts nervigeres wie das surfen auf langsamen Seiten. Laut einer Studie aus dem Jahre 2010 von Akamai und PhoCusWright verlassen 57 Prozent der Besucher von Onlineshops nach 3 Sekunden Wartezeit die Seite wieder, außerdem wirken Seiten die lange Ladezeiten haben auf viele Besucher unprofessionell. Aus SEO Sicht ist die Ladezeit auch nicht ganz uninteressant da Google seit April 2010 offiziell die Ladezeit als Rankingkriterium aufgenommen hat.

Es macht also durchaus Sinn dafür zu sorgen das man seine Seiten möglichst schnell in den Browser seiner Besucher bringt. Dabei gibt es mehrere Faktoren die den Seitenaufbau verlangsamen können. Bei vielen Internetseiten kann an dem ein oder andern Punkt einiges optimiert werden und so die Ladezeit in Einzelfällen um ein Drittel oder mehr gesenkt werden.

Requests reduzieren und optimieren

Eine Seite besteht in den wenigsten Fällen aus nur einer Datei, normalerweise gibt es eine HTML oder PHP Datei für den Inhalt der Seite, dazu kommen dann oft mehrere Grafiken CSS Dateien und ausgelagerte Javascripts. Für jede dieser Dateien ist ein extra DNS Request nötig, auch wenn durch Caching im DNS der Request nicht immer vollständig ausgeführt werden muss sollte man versuchen so wenige Dateien wie möglich zu verwenden. Manchmal können mehrere kleinere Grafiken für das Design zu einer großen Grafik zusammengefasst werden, bei CSS und JS Dateien sieht es oft ähnlich aus. Beim zusammenlegen von CSS oder JS sollte man allerdings auch immer an die Größe der Dateien denken, es macht keinen Sinn 20 KB CSS das nur auf speziellen Unterseiten benötigt wird auf allen Seiten zu laden nur um auf der entsprechenden Unterseite einen DNS Request zu sparen.

Ein weiterer Punkt an dem man allerdings bei bestehenden Seiten oft nicht viel machen kann ist die Anbindung der Seite ans Internet. Wenn man einen Server mietet wird oft angegeben das er mit 100 MBit/s an das Backbone angebunden ist. MBit ist aber nicht gleich MBit und Backbone ist auch nicht gleich Backbone. Bevor man einen Server mietet sollte man sich immer auch die Traceroute anschauen, unter Linux macht man das auf der Konsole mit

traceroute domain.tld

Hier sieht man wie viele Hops bis zum Ziel benötigt werden, wenn mehr als 10 Hops benötigt werden sollte man sich evtl. nach einem besseren Hoster umschauen. Wichtig ist auch das man sich die Traceroute von möglichst vielen verschiedenen Zugangsprovidern aus anschaut da Rechenzentren bzw. Hosting Firmen verschiedene Peeringabkommen mit den verschieden Zugangsprovidern haben. Es kann also gut sein das von einem Telekom Anschluss nur 8 Hops benötigt werden wo ein Arcor Anschluss 12 Hops benötigt da der Hostingprovider zwar mit der Telekom peert aber nicht mit Arcor. Am besten lässt man bevor man seinen Server mietet mal ein paar Freunde mit verschiedenen Internetanschlüssen eine Traceroute zu einem benachbarten Server durchführen.

Größe und Komplexität der Seite

Eigentlich ist dieser Punkt ganz einfach, um so größer eine Seite ist um so mehr Daten müssen übertragen werden und um so länger dauert es bis die Seite im Browser angezeigt werden kann. Man sollte also immer versuchen den Quelltext so klein wie möglich zu halten, wobei hier nur der HTML Code wichtig ist, ob der PHP Code der im Hintergrund auf dem Server läuft aus 3 Zeilen oder 3 Seiten besteht ist erst mal egal, Hauptsache der HTML Code der ausgegeben wird ist möglichst kurz. Optimieren kann man das indem man keine HTML Kommentare verwendet und sämtliches CSS und JavaScript das für mehrere Seiten benötigt wird in externe Dateien auslagert. Externe Dateien werden vom Browser gecached und in der Regel nur einmal beim ersten Besuch runter geladen. Außerdem kann man einiges einsparen indem man seine CSS Klassennamen möglichst kurz hält, hier muss man natürlich auch immer ein bisschen auf die Lesbarkeit des Codes achten, alle CSS Klassen einfach A-Z zu nennen hält die Sache zwar schön klein aber macht den Code nicht unbedingt wartungsfreundlich.

Ein recht einfacher Weg der den Code der übertragen werden muss verringert ist Komprimierung. Alle gängigen Browser unterstützen GZip, so wird der zu übertragende Code auf dem Server gepackt und erst im Browser wieder entpackt. Das benötigt zwar auf beiden Seiten ein wenig Rechenzeit, rechnet sich aber da man heutzutage meisten eh schnelle CPUs aber relativ langsame Netzwerke verwendet trotzdem. Damit der Webserver GZip verwenden kann muss ein entsprechendes Modul installiert werden, beim Apache ist das mod_deflate, für Lighttpd ist das ModCompress.

Ein weiterer Punkt der oft wenig beachtet wird ist die komplexität der Seite. Wenn der HTML Code zum Browser übertragen wurde muss ihn der Browser interpretieren und daraus die Seite darstellen. Wenn auf der Seite viele verschachtelte Tabellen oder Container verwendet werden kann es sein das der Browser einige Zeit braucht bis er die Seite vollständig anzeigt. Das gleiche gilt für JavaScripts die automatisch beim aufrufen der Seite ausgeführt werden. Grundsätzlich empfiehlt es sich immer JavaScripte die nicht schon während dem Seitenaufbau benötigt werden am Ende der Seite aufzurufen. Wenn ein Script dann mal etwas länger braucht hat der Besucher wenigstens schonmal was zu sehen, wenn ein Script am Anfang der Seite aufgerufen wird kann es passieren das der Browser hängt und der Besucher nur den Header der Seite sieht bis das Script fertig ist. Wer möchte kann das mit der ganzen Seite so machen, man kann den eigentlichen Content im HTML Code an den Anfang setzen und erst danach weniger wichtige Teile der Seite wie Menu, Header und Footer. Per CSS kann man das ganze dann so Designen das der Content zwar im HTML an erster Stelle steht aber trotzdem erst unter dem Header angezeigt wird.

Page Generation

Wenn man mit PHP o.Ä. dynamisch erstellte Seiten verwendet muss die Seite bevor der Server sie zum Browser schicken kann erst mal erstellt werden. Jeh nach dem was da im Hintergrund alles passieren soll kann das recht lange dauern. Auch wenn es nicht immer ganz einfach ist kann man hier aber oft einiges raus holen. Wer Content von fremden Seiten (z.B. Feeds) auf seiner Seite ausgibt sollte auf jeden Fall Cachen da man auf die Geschicklichkeit des Servers von dem man seine Daten holt keinen Einfluss hat. Datenbank Querys die Daten holen die nicht unbedingt immer live sein müssen können genau so gecached werden. Außerdem sollte man versuchen beim Code der die Seite erstellt möglichst immer den schnellsten Weg zu wählen, zu einigen Funktionen die PHP bereitstellt gibt es alternative Funktionen die schneller sind. Außerdem sollten nach Möglichkeit keine Schleifen verschachtelt oder Datenbankquerys in Schleifen ausgeführt werden da so was sehr schnell zu einer Belastung für den Server werden kann die sich nicht mehr überblicken lässt.

Auch hier gibt es wieder Module für den Webserver die PHP Code cachen so das er nicht bei jedem Seitenaufruf in vollem Umfang ausgeführt werden muss sondern der kompilte Code aus dem RAM geladen werden kann was bis zu 200% mehr Geschwindigkeit bringt. Welches der Module das beste ist hängt stark vom verwendeten Webserver ab, der Einsatz mehrerer solcher Module bringt meistens nichts und ist nicht zu empfehlen.

Hier mal eine Liste mit verschiedenen Caching Modulen.


Kommentare


Bitte warten ...

Kommentar schreiben

URLs werden automatisch umgewandelt.
[b]DEIN TEXT[/b] für Fett gedruckt
[quote]DEIN ZITAT[/quote] für Zitate
[code]DEIN CODE[/code] für Code
captcha