Die Sache mit den Ladezeiten einer Weblog-Seite

Verfasst am 11.06.2008 23:51:34 Uhr
Die Sache mit den Ladezeiten einer Weblog-Seite

Jetzt habe ich eine (beliebige leere) Vergleichsseite mit Hilfe eines Webseitenanalyse-Programms www.octagate.com/ service/ SiteTimer/ untersucht.
[Hardcopy]

Bilder von oben nach unten: drei zufällige Analysen von a4.log.ag
Anm.:

der gelbe Bereich ist die Wartezeit (im WWW-Netz) zwischen dem Aufruf der Webseite (links) und dem Warten auf die Verbindung mit dem Server (rechts)
der grüne Bereich stellt die Wartezeit (im Server) seit der Verbindungsaufnahme (connect) mit dem Server (links) bis zum Senden des 1.Bytes (rechts) der angeforderten Datei dar,
der blaue Bereich ist der eigentliche Downloadbereich zwischen dem 1.Byte (links) und dem letzten Byte (rechts).

Man sieht sehr gut, wie groß die zeitlichen Schwankungen sind, obwohl die OctaGate-Webseite in ihren Grafiken die (x-Koordinatenwerte /) Abszissenwerte wie ein Geheimnis hütet. Was ist 1.0? Ist dies 100%? Von was? Von einer geheimen Vergleichsseite?

Also wenn ich meine Seite hiermit vergleichen möchte, dann muss ich mich auf die wesentlichen Aussagen einer solchen Grafik beschränken und darf nicht in Kleinkrämerei verfallen.

Wesentlich sind drei Bereiche erkennbar:

1: die obersten beiden Balken werden vor dem HTML-Head geladen:
- a4.log.ag
- a4.log.ag/favicon.ico
2: die nächsten 7 Balken bilden einen Block. Die ersten beiden gehören noch zum Headbereich (CSS-Datei und JavaScript-Datei):
- a4.log.ag/global.css
- a4.log.ag/css/java.js
Es folgen zwei Dateien, die die Besucher zählen:
- freenet.ivwbox.de/cgi-bin/ivw/CP/32011180;nn
  abakus.freenet.de/cgi-bin/ivw/CP/freenet/applications/hom.../index.html?123123
Es folgen drei Bilddateien für den Weblog-Vorspann:
- a4.log.ag/sourcen/weblog/layout_3_rolle_bg.gif
- a4.log.ag/sourcen/weblog/layout_3_rolle_oben_1.gif
- www.freenet.de/sourcen/0.gif
3: jetzt kommt der eigentliche Tagesbereich des online-Tagebuches. Er wird eingeleitet durch die Frage: "Möchten Sie über neue Einträge in diesem Weblog informiert werden? Dann klicken Sie bitte hier »" mit nachfolgender Bilddatei. Dann folgt der Bereich rechts unten im Weblog mit den aktuellen Tagesnachrichten (InstantContent), ..., und zum Schluss noch ein "Blank"-Gif von 1Pixel, welches vermutlich zur statistischen Zeitzählung dient:
- weblog.freenet.de/sourcen/button_braun.gif
- instantcontent.freenet.de/docwrite.php?Produkt=9&Anzahl=5
- a4.log.ag/sourcen/weblog/layout_3_rolle_unten_1.gif
- freenet.ivwbox.de/blank.gif

Bei meinem Tagebuch drpagel.log.ag heissen manche Dateien zwar anders, weil sie in einer anderen Subdomain von *.log.ag liegen, aber im wesentlichen entsprechen sie diesem Diagramm-Muster.

An dem blauen Bereich kann der Webmaster herumdoktern, indem er den Code verbessert, so dass weniger Code gesendet wird. Obiges Bild ergibt z.B. im PNG-Format weniger Byte als im GIF-Format. Der Vorschlag von topsubmit, die Dateigröße, wo sowieso fast nur Bildcode und Code von freenet steht, weiter zu verkleinern, ist völlig irreal, weil man ja dann übernhaupt keinen Weblog-Eintrag schreiben dürfte.
Den grünen Bereich kann der Webmastere nur optimieren, wenn er feststellt, dass sein Lieblingsserver dauernd überlastet ist und er seine Webseite lieber auf einen weniger mit sich selbst beschäftigten oder schnelleren Server deponiert.
Der gelbe Bereich ist nur schwer zu optimieren, weil er von der Tagesauslastung und regionalen Eigenart des www-Netzes abhängt.

Nun sieht man aber auch, dass sogar der von der eigenen Codegröße (Bytezahl) abhängige blaue Bereich Schwankungen unterliegt, denn auch über das Netz muss das Senden der Datenflut in Abhängigkeit von der Nutzung durch andere Teilnehmer proportioniert werden. Daher gibt es theoretische (optimale) Downloadzeiten, die z.B. von topsubmit.de als Ladezeit-Check ausgegeben werden.

Topsubmit berechnet diese theoretischen Zeiten in Abhängigkeit von der eigenen Hardware, deren Spezifikationen (Eigenarten) natürlich von den vorgeschlagenen abweichen können. Wesentlich ist die dort angegebene Rate in kbs (kilo bit pro sekunde). Wenn eine Seitengröße mit 91648 Byte berechnet wurde, so sind dies 733184 bit. Bei einer Rate von 56kbs (vergl. s.Tab.) würde der Download 13,09 sekunden dauern (= 733184 bit / 56000 (bit/sek)).

Berater raten gerne vielseitig: da gibt es noch das Webangebot von

Letztere rät dem Betreiber, seine Anzahl von Bildern zu verkleinern, die Anzahl der Objekte zu reduzieren, die Bytegesamtzahl auf 30K zu verkleinern, die Anzahl der Skript-Dateien von 3 möglichst auf 1 zu verkleinern, die Gesamtgröße der externen Skripts möglichst unter 4080 bytes zu halten, die Gesamtgröße des externen CSS-Code von 5067 byte möglichst unter 1160Byte zu optimieren. Manches finde ich etwas weltfremd. Zynisch: wenn man nur lange genug die Luft anhält, dann sinkt nicht nur der CO₂-Verbrauch, nein auch die Übertragungsleitungen werden dann alle frei und die Server sind nicht mehr überlastet.

Gerät	Download-Rate	Upload-Rate
T-DSL16000	16 Mb/s	1 Mb/s
T-DSL6000	6656 kb/s	640 kb/s
T-DSL2000	2304 kb/s	224 kb/s
T-DSL1000	1152 kb/s	160 kb/s

Anm.: 1 Mb = 1024 kb; 1 kb = 1024 b;
Lit.: DSL-Forum.de; onlinekosten.de

Noch ein fröhliches Optimieren! (dp) (3,5h)
archiviert (tbid2258.437): (dp) 28.06.2009 (+0,1h (+flagcounter +emoticon +home.icon +w3c_LiCh))