Webprogrammierung - Ergonomie und kurze Ladezeiten
Das sorgfältige Optimieren aller Webseiten hinsichtlich ihrer Ladezeit ist ein äußerst wichtiges Qualitätsmerkmal einer guten, ergonomischen Website. Denn...Niemand wartet gerne! Das weiß eigentlich jeder, der schon mal im Kaufhaus am Ende einer riesigen Schlange gestanden hat. Und genauso schlecht fühlt sich das an, wenn man mit einer mittelprächtig-schmalbrüstig ausgelegten Anbindung an das "Netz" auf ein (hoffentlich) interessantes Angebot klickt und dann minutenlang nichts weiter als einen leeren Bildschirm zu sehen bekommt.
- Die Fakten
- Der geringste Anteil einer einzelnen Webseite besteht aus reinem Text. Denn um diesen stilsicher zu Bildschirm zu bringen, bedarf es vieler sogenannter Tags, die, für den Betrachter unsichtbar, das Aussehen dieser Seite regeln. Bilder, Multimedia-Elemente (die niemand wirklich braucht), unsichtbare Kommentare und unsinnige Leerzeichen können so eine Seite ganz schön aufblähen. Entscheidend für den so wichtigen schnellen Seitenaufbau sind im wesentlichen vier Dinge:
- Die Anbindung des Webservers an das "Netz", seine Schnelligkeit und Auslastung.
- Die Menge der zu übertragenen Daten insgesamt.
- Die Anbindung des Besuchers an das "Netz".
- Die Arbeit, die der Browser mit dem "Verdauen" der Webseite hat.
- 1. Der Webserver
- Die Einrichtung eines Webservers ist wieder ein ganz anderes Thema, das in diesem Abschnitt nicht behandelt werden kann. In der Regel bekommt dieser Server sehr viele Anfragen gleichzeitig - jede Datei, jedes noch so kleine Bild muß er einzeln verschicken. Nebenbei "übersetzt" er aktive Webseiten, wühlt in diversen Datenbanken herum und muß sich schließlich auch selbst verwalten. Keine Frage, daß er für solche Aufgaben auch ausgelegt sein muß. Und eine besonders schnelle Anbindung an das "Netz" benötigt.
- 2. Die Datenübertragung
- So eine mittelgroße Webseite bringt es alleine schon locker auf 16 KBytes. Und ich rede hier von einer optimierten Webseite! Bilder, Piktogramme, Hintergrundgrafiken "kosten" nochmal extra, also so um die zehn sind beileibe noch nicht viel. Im günstigsten Fall hat der Webprogrammierer auch hier optimiert, so daß hier vielleicht noch mal so 8 KBytes anfallen. Die alles entscheidene Frage: Wie schnell hat der Besucher diese Seite auf seinem Bildschirm?
Mal rechnen: 24 KByte lassen sich mit ISDN theoretisch in 3 Sekunden übertragen. Vielleicht noch 2 Sekunden Gesamt-Reaktionszeit für DNS, Verbindungsaufnahme etc. dann müssen wir also mit mindestens 5 Sekunden rechnen. Glücklicherweise läßt sich da noch einiges mit dem Browser-Cache trixen, so daß wir vielleicht auch mit 3-4 Sekunden hinkommen. Da sind wir viel schlimmeres gewohnt - oder? - 3. Die Anbindung des Besuchers
- Ein nicht gern aber dafür umso öfter gehörter Einwand, der da lautet "Ach so ein Schmarrn - die meisten surfen doch im Firmennetz mit einer 100 MBit - Anbindung, da spielen doch ein paar 100 KByte mehr oder weniger keine Rolle".
Arrrrrgh!!!!- Fahren wir im Netz immer noch TCP/IP. Das heißt, es wird nur paketweise übertragen. Ist wie auf der Landstraße, das langsamste Paketchen bestimmt die effektive Geschwindigkeit des Verkehrs. Nur wenn alle schnell fahren, geht es auch zügig weiter!
- Teilen sich die 10.000 Mitarbeiter einer großen Firma einen meist schlecht gewarteten und chronisch überlasteten Proxy.
- Und jeder freut sich auf den Feierabend, weil das Surfen mit dem 56K-Modem ja auch viel schneller geht...
- 4. Die Arbeit des Browsers
- Wenig bekannt: Auch der Browser selber verzögert den Seitenaufbau!!! Das können ein paar unerhebliche Millisekunden sein. Aber auch mehrere Sekunden, je nach dem, was sich der Webprogrammierer da so zusammenprogrammiert hat. Oder hat er möglicherweise einen billigen WYSIWYG-Editor benutzt, der nur für einen ganz bestimmten Browser optimiert? Flache Table-Hierarchien, korrektes W3C-konformes HTML und eine möglichst einfache Strukturierung stellen für jeden Browser eine "leicht verdauliche" Kost dar.