Schnelle Seiten
Flott durchs Netz
Otto Normalsurfer wartet nicht gerne. Wenn der Seitenaufbau sich zu lange hinzieht, bricht er
ab und sucht sich eine andere Site - es gibt ja genug davon. Für den Webdesigner heißt das,
möglichst schnelle Seiten zu entwerfen.
Die Geschwindigkeit einer Internetseite hat zwei Aspekte: Die objektive Ladegeschwindigkeit, also
die Zeit zwischen dem Anklicken des Links (z.B.) bis zum Ende des Ladens, andererseits eine
subjektive Geschwindigkeit, die die Zeit bis zur Verwendbarkeit und Lesbarkeit der Seite zeigt.
Kleine Datenmengen
Eine Seite ist schnell, wenn sie einen kleinen Datenumfang hat. Das Maximum sollte normalerweise
bei etwa 50kB liegen, bei der Hompage noch deutlich darunter.
Wie bekomme ich das hin? Zunächst sollte man allzu große Seiten in mehrere kleinere aufteilen.
Der Surfer braucht dann auch nur das zu laden, was ihn interessiert. Dann werfe man einen Blick
auf die Grafiken. Sie allein haben oft schon einen enormen Umfang. Durch Reduzierung der Farbtiefe,
ein geeignetes Dateiformat, eine Reduzierung des Bildausschnittes auf wichtige Teile und Speicherung
in der tatsächlich benötigten Bildgröße wird viel gewonnen. Weitere Möglichkeiten
sind die Wiederverwendung identischer Bilder auf verschiedenen Seiten, so dass der Browsercache
die Grafiken liefern kann.
Eine Anmerkung zum Dateiformat: Browser zeigen standardmäßig GIF- und JPG-Bilder an. GIFs haben bis
zu 256 Farben, JPGs 16,7 Millionen. Durch die Art der Komprimierung eigenen sich GIFs besonders für
Bilder mit einheitlichen Farbflächen, also z.B. die meisten Zeichnungen. JPGs sind besser geeignet für
Grafiken mit Farbverläufen wie etwa Fotos. Bei JPGs lässt sich der Grad der Komprimierung
einstellen, wobei eine sehr hohe Komprimierung zu sichtbaren Fehlern im Bild führt.
Noch ein Punkt: Der Quellcode. Viele Editoren fügen großzügig Umbrüche und Leerzeichen,
Kommentare und vor allem überflüssige Tags und Parameter ein. Gerade bei Tabellen findet
man oft z.B. Breitenangaben für jede einzelne Zelle, was unnötig ist: alle Zellen einer Spalte
sind gleich breit. Auch das font-Tag und nbsp's sind oft zuviel.
Durch eine Quellcodebereinigung lässt sich bis zur Hälfte der Daten einsparen!
Sauberer Code
Helfen Sie dem Browser! Durch sauberen HTML-Code kann er Seiten schneller darstellen.
Viele Tags benötigen eigentlich nicht zwingend ein abschließendes Tag, z.B.
<P>, <LI>, <HTML>, <BODY>,
andere verzeihen es in den meisten Browsern, wenn es fehlt, z.B. <TD>.
Der Browser aber muss jedesmal nachrechnen, wo das Abschlusstag hätte stehen
sollen, das kostet Zeit.
Hier sind auch die width- und
height-Angaben bei Grafiken zu nennen, die man immer verwenden
sollte. Durch diese Angaben wird der Bildschirmaufbau beschleunigt,
außerdem entsteht eine schnellere subjektive Lesbarkeit der
Seite. Ältere Browser haben ohne diese Angaben zudem
Schwierigkeiten mit JavaScripts, die diese Grafiken
betreffen.
Auch die alt-Angabe bei Grafiken sollte nicht fehlen.
Durch sie wird schon während des Ladens der Seite erkennbar,
was sich hinter den Platzhaltern für die Bilder verbirgt.
Tabellen
Tabellen werden erst angezeigt, wenn ihr
Inhalt vollständig geladen ist. Das liegt daran, dass der
Browser vorher noch nicht weiß, was undwo er es anzeigen soll,
da die Tabelle möglichst optimal ausgerichtet wird. Bei
verschachtelten Tabellen erhöht sich die Rechenzeit ungemein,
da jede Zelle erst nach der Berechnung ihres Inhaltes berechnet
werden kann, der dann aber wieder erst dargestellt werden kann -
kurz: eine rekursive Rechnung.
Der Rat kann also nur lauten,
(mehrfach) verschachtelte Tabellen möglichst zu vermeiden und
Tabellen überhaupt recht kurz zu halten. Statt dessen nutzt man
besser mehrere Tabellen neben- oder untereinander. So werden bereits
Inhalte sichtbar, wenn noch nicht alle Tabellen berechnet sind.
Frames
Bei der Verwendung von Frames im Zusammenhang
mit der Frage der Geschwindigkeit gibt es zwei Aspekte zu beachten:
Einerseits besteht eine Page mit Frames aus mindestens 3 Dateien
(dem Frameset und den mindestens 2 Dateien, die in den Frames
erscheinen), die alle einzeln vom Server angefordert werden
müssen. Andererseits geschieht dies nur beim ersten Mal, danach
wird nur noch ein Teil der Dateien nachgeladen. Der Gewinn liegt
dann nicht so sehr bei Grafik-Buttons u.ä., die auch bei
anderen Verfahren aus dem Cache geladen würden, als vielmehr
bei Text (und z.B. Scripten im Quellcode) und vor allem beim Rendern
der Seite, die dann halt z.T. schon fertig ist.
Scripte
Auch im Bereich der Scripte lässt sich
einiges an Datenumfang einsparen. Durch die Verwendung von externen
Scriptdateien, die ihre Funktionen allen Seiten der Site zur
Verfügung stellen, brauchen diese nur einmal geschrieben - und
geladen - zu werden. Eine solche Datei wird folgendermaßen
definiert:
<script type="text/javascript" src="scripts.js"
language="JavaScript"></script>. Sie enthält den Quelltext (ohne script-tags!) mit den
Funktionen, die man benötigt. Überhaupt sparen Funktionen, zumal wenn
sie möglichst allgemein formuliert sind, einiges an
Speicherplatz.
Links
Dass alle Links einer Seite auch
funktionieren sollten, ist klar. Aber auch eigentlich korrekte Links
lassen sich noch optimieren. Zunächst sollten alle Links auf
das tatsächlich Verzeichnis weisen, nicht auf den schönen,
kurzen Domainnamen, der aber nur eine Umleitung darstellt.
Dann
sollte man beachten, das Protokoll mit anzugeben, meist also http:.
Als drittes empfiehlt es sich, ggf. einen abschließenden
Slash oder den Standard-Dateinamen mit anzugeben, z.B. /index.html.
Der Server muss sonst erst einmal feststellen, dass es
sich um ein Verzeichnis handelt und nicht um eine Datei.
Eine
weitere Beschleunigung ergibt sich, wenn die Daten einer Seite nur
von einem oder möglichst wenigen Servern stammen, da sonst zu
jedem einzelnen erst einmal eine Verbindung aufgebaut werden
muss.
Zuletzt noch muss man wissen, das der Browser nur
identisch angegebene URLs auch als identisch erkennt. Also: Wenn ich
mehrere Links in meiner Site auf die gleiche URL habe und einmal
einen abschließenden Slash setze, dann immer! Sonst lädt
der Browser auch beim zweiten Mal nicht aus dem Cache, sondern aus dem Netz.
|