Wie errechne ich die Ladezeiten einer Seite?

[Britt]

Wie errechne ich die Ladezeiten, einmal mit normalem Modemanschluß, einmal mit DSL, einer Seite?

[meik]

geh mal auf www.topsubmit.de - dort kannste unter analyse deine seite checken.

Meik

[Christoph]

Hi

Wie errechne ich die Ladezeiten, einmal mit normalem Modemanschluß, einmal mit DSL, einer Seite?

du kannst Sie Dir selber errechnen mit dem Tool hier: http://scripts.java24.net/tools/downloadrechner.html ;)

Gruß Christoph

[Sven Rautenberg]

Moin!

Wie errechne ich die Ladezeiten, einmal mit normalem Modemanschluß, einmal mit DSL, einer Seite?

Summiere alle zu ladenden Datenmengen, addiere pro Datei nochmal ca. 500 Byte HTTP-Overhead hinzu, und teile durch die Bandbreite der Leitung (in Kilobyte pro Sekunde). Multipliziere mit zwei. Dann kriegst du einen Anhaltspunkt.

Typische Bandbreiten: Modem 4 KB/s, DSL zwischen 40 und 400 KB/s, je nach Anbieter und Internetauslastung.

Du kannst aber auch Faustregeln nehmen: Eine Seite sollte eher unter 100 KB an Daten haben (inkl. allem), eine Startseite eher unter 150 KB. Liegst du wesentlich drunter (z.B. 50 KB pro Seite), dann freu dich - deine Besucher werden es auch tun. Und unterschätze nicht die Vorteile von gecachtem Content. Der muß schließlich nur einmal geladen werden, und kann immer wieder verwendet werden.

- Sven Rautenberg

[Alexander Foken]

Moin Moin !

GAR NICHT!

Die "Ladezeiten" sind bestenfalls eine optimistische Schätzung, die meistens von folgenden Voraussetzungen ausgeht:

(1) Keine anderen Downloads parallel zum Laden der Seite
(2) Konstante Übertragungsrate vom Server zum Browser
(3) Schnelle Reaktion des Servers
(4) "normale" Anbindung über PPP-Dialup bzw. DSL-ATM-PPPoE

(1) trifft bei mir selten zu, da ich sehr gerne im Hintergrund andere Seiten (aus SelfForum oder Google-Ergebnis) lade. Andere Leute haben File Sharing Tools laufen, wieder andere betreiben einen Server, oder ziehen per FTP ISO-Images.
(2) trifft fast nie zu, denn TCP/IP garantiert keine Übertragungsraten.
(3) Wenn der Server unter Last läuft, können die Reaktionszeiten i.d.R. nicht garantiert werden (denn kaum ein HTTP-Server läuft mit einem Echtzeit-OS)
(4) Man kommt auch anders ins Internet, z.B. mit einer Standleitung oder mit einem Handy, um zwei Extreme zu nennen. Gerade beim Handy können die Übertragungsraten stark schwanken. Und nicht jedes Modem läuft mit V.90 (=56Kbit/s).

Du siehst, das Download-Zeiten großenteils einfach Unsinn sind.

Grober Daumenfaktor: Datenrate in kBit/s durch 10 bis 12 teilen ergibt Nutzdatenrate in kBit/s. Datenmenge (Seite + alle Images) durch die Nutzdatenrate teilen ergibt ungefähre Ladezeit, unter den o.g. Annahmen.

Handy: 9,6 kBit/s
Modem: 14,4/28,8/33,6/56 kBit/s
ISDN: 64/128 kBit/s
T-DSL: downstream 768 kBit/s (upstream 128 kBit/s)
Bei Standleitungen kann man auch mal 622 MBit/s bekommen - für entsprechend viel Geld. Da sind Ladezeiten dann fast völlig irrelevant.

Alexander

[Michael Schröpl]

Hi Britt,

Wie errechne ich die Ladezeiten, einmal mit normalem Modemanschluß, einmal mit DSL, einer Seite?

ich nehme Dein Wort "errechnen" mal sehr ernst (Du hättest ja auch "schätzen" schreiben können) und erlaube mir einen kleinen Exkurs zum Thema.

Was immer Dir auch an Tools genannt wird - das konkrete Download-Volumen (und damit die Download-Zeit, welche sich aus dem Verhältnis zwischen Volumen und Übertragungsgeschwindigkeit ergibt) ist immer _auch_ abhängig vom verwendeten Browser und dessen Konfiguration.
Einen 'absolut wahren' Meßwert unabhängig voneiner konkreten Anforderung durch einen konkreten Browser einer konkreten Konfiguration kann es also gar nicht geben.

Das Abholen einer "Seite" (inklusive der dabei wahrscheinlich subsummierten Ressourcen wie Bilder, CSS- und JavaScript-Dateien) besteht aus meist mehreren einzelnen HTTP-Requests (gesendet vom Browser) und HTTP-Responses (gesendet vom Server). Jedes dieser Pakete umfaßt eine Menge von HTTP-Header-Zeilen, welche die Anforderung bzw. die Antwort beschreiben.
Die HTTP-Header der Antworten werden _meistens_ unabhängig vom Browser immer gleich aussehen (beim Self-Portal hier ist das beispielsweise aber nicht so - Stichwort "Komprimierung"); die HTTP-Header der Anforderungen jedoch hängen davon ab, wie umfangreich der Browser seine Anfrage beschreibt (was wiederum teilweise in der Browser-Konfiguration einstellbar ist, in manchen Bereichen sogar nur in gewissen Konfigurationsdateien oder gar der Windows-Registry).

Du mußt also zu jeder einzelnen Ressource, die via HTTP angefordert wurde, ein Paar solcher HTTP-Header dazu zählen. Und das trifft auch dann zu, wenn der Browser 0 Bytes Nutzdaten übertragen hat, weil er beim Server erfolgreich nachgefragt hat, daß er den Inhalt seines Cache für eine bestimmte Ressource weiterhin verwenden darf! Die Frage selbst kostet eben auch etwas.

Schätzwerte für die Größe dieser Header: Beim Server sind es oftmals 200-300 Bytes; bei Browsern habe ich schon Werte über 700 Bytes erlebt, was sich durch gute Konfiguration (Referrer abschalten,  User-Agent ändern, "Accept:"- und "Accept-Encoding:"-Header auf das Minimum beschränken) auf Werte um die 200-250 Bytes reduzieren läßt.
Jede HTTP-Roundtrip kostet also zwischen 500 und 1000 Bytes zusätzlich - das kann ggf. deutlich mehr sein als die 200 Bytes eines kleinen GIF-Icons.

Diesen HTTP-Header-Traffic mußt Du zu den Netto-Nutzdaten der Seite addieren. Je kleiner die von Deiner Seite ausgelieferten Ressourcen sind, um so größer wird der Rechenfehler, wenn Du das vernachlässigst.
Allfällige Meßprogramme könnten diese HTTP-Header natürlich mitzählen, wenn sie wollten - das Problem dabei ist, daß sie selbst durch willkürliche Entscheidung ihrer Arbeitsmethodik (nämlich der Art und Weise, wie _sie_ ihre HTTP-Anforderungen an die zu messende Seite stellen!) das Meßergebnis selbst beeinflussen.

Viele Grüße
      Michael