Komplette Seitengröße bewerten

Da fällt mir noch was ein:

So richtig amtlich wäre es, die zu testende Seite zweimal zu laden und beim ersten mal entsprechend eines Browsers normal zu cachen.

Der zweite Aufruf würde dann zeigen, ob die gleichen Elemente einer Seite ständig neu geladen werden (200er Returncode) oder nur eine 304 (not modified) zurückkommt und die Datei aus dem Browsercache angezeigt wird, was immens Ladezeit spart.

tschersich schrieb:

Leider hat das kaum Aussagekraft über die potentiellen Ladezeiten der Seite, denn die eigentlichen Ãœbeltäter sind die Grafiken und Bilder einer Seite und neuerdings auch der übermäßige Gebrauch von Ajax/Javascript, die als .js Dateien mitgeladen werden.

So ist es (daran sollte man auch denken wenn man ein komprimierte Ausgabe denkt) und es wird aktuelle auch immer unwichtiger.
Bei 20 Mbit Zugang ist mir das völlig wurscht und selbst Leute die mit 6 Mbit ran gehen können ist es völlig egal ob da ein paar Images etc. mehr oder weniger laufen.

Man muss einfach sehen (man schau sich mal die Top 20 an) das solche Einlagen heute einfach dazu gehören, ansonsten hat man keine Besucher.

Ich halte die Bewertung der Seitengröße in dem Zusammenhang für nett aber für praktisch ohne Bedeutung.

Da empfehle ich mal die Lektüre von "Speed matters", bei der u.a. Amazon herausgefunden hat, dass bei 100 Millisekunden langsamerer Ladezeit pro Seite der Umsatz um fast 1% gesunken ist.

Dabei waren es gerade die gut angebundenen "Power"-User, die die wenigste Geduld mit dem Seitenaufbau hatten. Den MoDem Usern war es egal, ob sie nun 20 oder 22 Sekunden warten mußten.

tschersich schrieb:

Da empfehle ich mal die Lektüre von "Speed matters", bei der u.a. Amazon herausgefunden hat, dass bei 100 Millisekunden langsamerer Ladezeit pro Seite der Umsatz um fast 1% gesunken ist.

Mag ja sein, aber man muss auch immer bedenken, das alle sonstigen Massnahmen wie gzip - Komprimierung ebenfalls Zeit kosten, die, wenn ich sie weg (den finalen dazu notwendigen Buffer) lasse bei einem System mit einer Templateengine erheblich mehr spare als die 100 ms.
Ausserdem bei 20 Mbit pfeifen da netto 2,5 MB durch da kommt es nicht auf ein paar KB dran an.

Und - als Anbieter mit sehr häufigen Inhaltswechseln (kann bis zig mal am Tag sein) kommt eine individuelle Aufbereitung unter Berücksichtigung der Seitengröße und Imagessizes viel zu teuer.

Na ja kann ja jeder machen was er will, aber in Zeiten wo ein Bild vorne schon nicht mehr aussreicht und dafür sogar Videos her halten halte ich eine Diskussion über Imagesizes für überflüssig.

Klar- je weniger desto schneller, aber das merkt irgendwann "kein Schwein" mehr.
Ich bin letztens in einem Innovationscenter mal mit 1,9 Gigabit rein gegangen - da ist dermassen schnell, das ich mir nicht vorstellen kann das man da nur noch bemerkt das der eigene Rechner zu langsam ist.

Auf der anderen Seite werden Zuleitung von 16 MB bestellt und der Rechner selbst nebst der darin installierten Software spielt da nicht mit.
Allein die Verzögerungen durch Virenscanner ist erheblich und da reden wir nicht über 100 ms Sekunden.

Und nicht selten ist ein nicht aktueller Rechner überhaupt nicht in Lage 16 Mbit oder mehr zu verkraften.

Also was soll man da an Kosten rein stecken, das mag sinnvoll sein bei statischen Webs nicht aber bei täglich mehrfach aktuellisierten Webs.

Und man darf auch daran denken das auch relativ normale Webs am Tag mehrfach per Vorprogrammierung praktisch aus der Konserve aktualisiert werden - da gibt keiner der kaufmännisch rechnen kann auch nur einen Cent dafür aus.