Ladezeit einer Internetseite
- Ersteller Marcs
- Erstellt am
Webtrade and more
Legendäres Mitglied
Du kannst Dich ja nach den bekannten, hochfrequentierten Seiten orientieren, wie z. B. Ebay - die haben so 170 -180 kb soweit ich weiss. Ansonsten musst du wissen welche Zielgruppe Du erreichen willst - Business-Branchen oder -Leute haben fast durchweg Highspeedzugänge, so dass Du dann auch noch höher gehen kannst.
Du findest auch im Web immer aktuelle Statistiken über die prozentuale Aufteilung der jeweiligen Zugänge - In Frankreich z. B. haben mehr als 85% Highspeed, in vielen anderen Ländern auch schon, in Deutschland und der Schweiz sind wir auf dem Weg dahin.
Du findest auch im Web immer aktuelle Statistiken über die prozentuale Aufteilung der jeweiligen Zugänge - In Frankreich z. B. haben mehr als 85% Highspeed, in vielen anderen Ländern auch schon, in Deutschland und der Schweiz sind wir auf dem Weg dahin.
QUOTE Ebay - die haben so 170 -180 kb
Daran sollte man sich nun wirklich nicht orientieren eine Startseite sollte laut webdesign studien zwischen 15 und 35 kb haben
QUOTE Leute haben fast durchweg Highspeedzugänge
Davon kann man auch nicht ausgehen da die meisten user noch mit modem unterwegs sind
Daran sollte man sich nun wirklich nicht orientieren eine Startseite sollte laut webdesign studien zwischen 15 und 35 kb haben
QUOTE Leute haben fast durchweg Highspeedzugänge
Davon kann man auch nicht ausgehen da die meisten user noch mit modem unterwegs sind
Oder man macht einfach die Webpage kleiner durch "Content Compression".
Das heisst, die Site mit PHP bauen und "ob_gzhandler" einsetzen, noch besser "zlib.output_compression".
Das funktioniert gut, ich habe Sites die zu 74 Prozent komprimiert werden - sind also bei der Auslieferung nur noch ein Drittel so gross.
Das lässt sich dann mit diesem Tool testen.
Nachteile gibt es, wie bei allem: Auf extrem schwachen PCs oder Laptops wird der Prozessor stark belastet, manche Hoster ermöglichen keine Content Compression, und der IE Browser hat je nach Version ein kleineres Speicherproblem. Und je nach PHP Version muss man einen "Vary" Header mitsenden.
Dennoch: Ich habe damit sehr gute Erfahrungen gemacht. Eine 100 KB Startseite ist mit dieser Methode nur noch 30 KB gross - und wird dementsprechend schneller ausgeliefert
Edit: Das funktioniert natürlich nur für Seitencode (HTML, XHTML, sogar CSS) -- nicht für Bilder. Bei Bildern hilft es oft, wenn man PNG statt JPG verwendet (bessere Kompression).
Das heisst, die Site mit PHP bauen und "ob_gzhandler" einsetzen, noch besser "zlib.output_compression".
Das funktioniert gut, ich habe Sites die zu 74 Prozent komprimiert werden - sind also bei der Auslieferung nur noch ein Drittel so gross.
Das lässt sich dann mit diesem Tool testen.
Nachteile gibt es, wie bei allem: Auf extrem schwachen PCs oder Laptops wird der Prozessor stark belastet, manche Hoster ermöglichen keine Content Compression, und der IE Browser hat je nach Version ein kleineres Speicherproblem. Und je nach PHP Version muss man einen "Vary" Header mitsenden.
Dennoch: Ich habe damit sehr gute Erfahrungen gemacht. Eine 100 KB Startseite ist mit dieser Methode nur noch 30 KB gross - und wird dementsprechend schneller ausgeliefert
Edit: Das funktioniert natürlich nur für Seitencode (HTML, XHTML, sogar CSS) -- nicht für Bilder. Bei Bildern hilft es oft, wenn man PNG statt JPG verwendet (bessere Kompression).
1
1234567890
Guest
QUOTE (Lanza @ Sa 11.2.2006, 13:35)
QUOTE Ebay - die haben so 170 -180 kb
Daran sollte man sich nun wirklich nicht orientieren eine Startseite sollte laut webdesign studien zwischen 15 und 35 kb haben
QUOTE Leute haben fast durchweg Highspeedzugänge
Davon kann man auch nicht ausgehen da die meisten user noch mit modem unterwegs sind
Ich gebe dir vollkommen recht.
Die ebay-Startseite braucht bei mir mit DSL 1000 locker bis zu 10 Sekunden. Unterseiten brauchen auch teilweise ewig. Auf Seite auf die ich nicht wirklich will bin ich bei solchen extrem langen Ladezeiten schnell wieder weg.
Laut dem Webhits.de Webbarometer ist Modem noch sehr verbreitet:
xDSL / LAN 73.8%
ISDN / Modem 26.2%
Wenn Sie Herr Matthias Hofmann auf diesen Besucher verzichten könnten, dann können Sie gerne Ihre Seiten vollknallen. Ich halte meine lieber schlank und rank.
QUOTE Ebay - die haben so 170 -180 kb
Daran sollte man sich nun wirklich nicht orientieren eine Startseite sollte laut webdesign studien zwischen 15 und 35 kb haben
QUOTE Leute haben fast durchweg Highspeedzugänge
Davon kann man auch nicht ausgehen da die meisten user noch mit modem unterwegs sind
Ich gebe dir vollkommen recht.
Die ebay-Startseite braucht bei mir mit DSL 1000 locker bis zu 10 Sekunden. Unterseiten brauchen auch teilweise ewig. Auf Seite auf die ich nicht wirklich will bin ich bei solchen extrem langen Ladezeiten schnell wieder weg.
Laut dem Webhits.de Webbarometer ist Modem noch sehr verbreitet:
xDSL / LAN 73.8%
ISDN / Modem 26.2%
Wenn Sie Herr Matthias Hofmann auf diesen Besucher verzichten könnten, dann können Sie gerne Ihre Seiten vollknallen. Ich halte meine lieber schlank und rank.
Sascha Ahlers
Legendäres Mitglied
QUOTE (Greg Lemmenmeier @ Sa 11.2.2006, 13:47)[...]
Das heisst, die Site mit PHP bauen und "ob_gzhandler" einsetzen, noch besser "zlib.output_compression".
[...]
Leider unterstützen dies ältere Browser nicht, der mindestens noch der MSIE 5.5 SP2 spielt da nicht mit. Außerdem wird durch die Kompression der Server zusätzlich belastet, so dass man dabei abwägen sollte, wo dort der Engpass liegen könnte (Traffic oder Rechenleistung).
Aber auch der Apache bietet hierbei ein Modul, welche sich gzip nennt.
Die Startseite sollte etwa 40 KB groß sein mit allen Drum und Dran (10-Sekunden-Regel; 40 KB / 56 KBit/s = 5,71s (+ DNS-Abfrage)), alle anderen Seiten sollten sich nach Möglichkeit an eine Obergrenze von 80 KB (80 KB / 56 KBit/s = 11,43s (+ DNS-Abfrage)) halten, alles bis 120 KB kommt den Benutzer noch relative schnell vor, wenn er denn bereits einmal auf der Seite ist.
MfG Sascha Ahlers
Das heisst, die Site mit PHP bauen und "ob_gzhandler" einsetzen, noch besser "zlib.output_compression".
[...]
Leider unterstützen dies ältere Browser nicht, der mindestens noch der MSIE 5.5 SP2 spielt da nicht mit. Außerdem wird durch die Kompression der Server zusätzlich belastet, so dass man dabei abwägen sollte, wo dort der Engpass liegen könnte (Traffic oder Rechenleistung).
Aber auch der Apache bietet hierbei ein Modul, welche sich gzip nennt.
Die Startseite sollte etwa 40 KB groß sein mit allen Drum und Dran (10-Sekunden-Regel; 40 KB / 56 KBit/s = 5,71s (+ DNS-Abfrage)), alle anderen Seiten sollten sich nach Möglichkeit an eine Obergrenze von 80 KB (80 KB / 56 KBit/s = 11,43s (+ DNS-Abfrage)) halten, alles bis 120 KB kommt den Benutzer noch relative schnell vor, wenn er denn bereits einmal auf der Seite ist.
MfG Sascha Ahlers
1
1234567890
Guest
QUOTE alles bis 120 KB kommt den Benutzer noch relative schnell vor, wenn er denn bereits einmal auf der Seite ist.
Woher willst du das wissen? Mir kommen schon einige Sekunden wie eine Ewigkeit vor. Ich habe schon sehr viele Seiten vorher gekickt, bevor sie zu Ende geladen haben. Wenn man solche Theorien behauptet, dann sollte man auch eine Quellenangabe habe.
Woher willst du das wissen? Mir kommen schon einige Sekunden wie eine Ewigkeit vor. Ich habe schon sehr viele Seiten vorher gekickt, bevor sie zu Ende geladen haben. Wenn man solche Theorien behauptet, dann sollte man auch eine Quellenangabe habe.
Eine webseite sollte schon spätestens nach 3 Sekunden da sein ( mit DSL ) 10 Sekunden würde ich auch nicht warten .
Bei Seiten die lange Ladezeiten haben bedingt vielleicht wegen den Bildern
hat man erstmal die Möglichkeit die Bilder vorzuladen oder man schaltet eine Einstiegsseite davor die irgendwo im 10kb bereich liegt ( das sin 0,5 Sekunden ladezeit mit Modem )wo der user erkennen kann was ihn erwartet dan kann er immer noch entscheiden ob er sich das Elend antut und dan vielleicht 20 Sekunden wartet bis die seite da ist.
Bei Seiten die lange Ladezeiten haben bedingt vielleicht wegen den Bildern
hat man erstmal die Möglichkeit die Bilder vorzuladen oder man schaltet eine Einstiegsseite davor die irgendwo im 10kb bereich liegt ( das sin 0,5 Sekunden ladezeit mit Modem )wo der user erkennen kann was ihn erwartet dan kann er immer noch entscheiden ob er sich das Elend antut und dan vielleicht 20 Sekunden wartet bis die seite da ist.
Sascha Ahlers
Legendäres Mitglied
QUOTE (Rainer @ Sa 11.2.2006, 14:59)
QUOTE alles bis 120 KB kommt den Benutzer noch relative schnell vor, wenn er denn bereits einmal auf der Seite ist.
Woher willst du das wissen? [...]
Nennen wir es mal Erfahrung. ;-)
Wenn es um einen längeren Artikel geht und der Benutzer möchte den lesen, dann wird er auch die paar Sekunden noch warten, außerdem gibt es meisten auch noch sowas wie einen Cache, in welchen CSS-Dateien und bereits gelandene Bilder gespeichert werden. Darum habe ich auch den Zusatz angehängt: "..., wenn er bereits einmal auf der Seite ist".
MfG Sascha Ahlers
QUOTE alles bis 120 KB kommt den Benutzer noch relative schnell vor, wenn er denn bereits einmal auf der Seite ist.
Woher willst du das wissen? [...]
Nennen wir es mal Erfahrung. ;-)
Wenn es um einen längeren Artikel geht und der Benutzer möchte den lesen, dann wird er auch die paar Sekunden noch warten, außerdem gibt es meisten auch noch sowas wie einen Cache, in welchen CSS-Dateien und bereits gelandene Bilder gespeichert werden. Darum habe ich auch den Zusatz angehängt: "..., wenn er bereits einmal auf der Seite ist".
MfG Sascha Ahlers
Alain Aubert
Legendäres Mitglied
Die maximale Dateigrösse ist im Optimum wohl minmal
Im Ernst, es ist schon fast alles gesagt worden, ausser, was bei dieser Diskussion fast immer vergessen wird.
Du solltest die Seite im Optimalfall so gestalten, dass schon mit der Hälfte des Codes etwas angezeigt wird. (Ja ich weiss, verschiedene Browser rendern verschieden). Das hat den Vorteil, dass der User quasi sofort etwas sieht. Das verunmöglicht zwar gängige Kompression, kann aber u.U. die beste Methode sein. Im Moment ist die Methode meiner Wahl von Greg Eingebrachtes, da ich der festen Überzeugung bin, dass die Bandbreite und nicht die Rechenleistung - noch - der Flaschenhals ist.
Die 35Kb Zahl ist übrigens älter als meine ADSL Leitung und ich hab das, seit es von der Swisscom angeboten wird. Trotzdem ist es nicht das dümmste sich an dieser Zahl auch in Zukunft zu orientieren. Ich errinnere nochmal an meinen einleitenden Politikersatz
Im Ernst, es ist schon fast alles gesagt worden, ausser, was bei dieser Diskussion fast immer vergessen wird.
Du solltest die Seite im Optimalfall so gestalten, dass schon mit der Hälfte des Codes etwas angezeigt wird. (Ja ich weiss, verschiedene Browser rendern verschieden). Das hat den Vorteil, dass der User quasi sofort etwas sieht. Das verunmöglicht zwar gängige Kompression, kann aber u.U. die beste Methode sein. Im Moment ist die Methode meiner Wahl von Greg Eingebrachtes, da ich der festen Überzeugung bin, dass die Bandbreite und nicht die Rechenleistung - noch - der Flaschenhals ist.
Die 35Kb Zahl ist übrigens älter als meine ADSL Leitung und ich hab das, seit es von der Swisscom angeboten wird. Trotzdem ist es nicht das dümmste sich an dieser Zahl auch in Zukunft zu orientieren. Ich errinnere nochmal an meinen einleitenden Politikersatz
Ja, 35k ist ein guter Richtwert. Darum ist zB meine HP genau 36,2k gross (gemäss Size Checker auf searchengineworld.com), also komplett mit Bildern.
Huch, das ist ja 1,2 KB zuviel... Scherz.
Kommt immer drauf an, was der Besucher haben will. Wenn ihm das wichtig genug ist, wartet der auch auf 200KB.
Noch extremer, weil Realität:
Ich biete zum Beispiel Sites an (zum Anschauen), bei denen die User erst *nach fünf Minuten Ladezeit* langsam zu motzen beginnen, es dauere zu lange. Richtig geraten, Flash - das natürlich absolut nicht mehr im Trend liegt und immer öfter geskippt wird (weil alles was sich bewegt nach Werbung aussieht), aber es gibt immer noch Leute die das sehen wollen. Egal obs minutenlang dauert.
Jetzt bin ich abgeschweift, aber für mich ist klar: Kommt immer auf die User an, die Zielgruppe, die Wichtigkeit oder eben auch Attraktivität einer Site.
Pauschalisierende Sprüche wie "darf maximal X gross und Z lange sein" sind bekannt aber realitätsfremd, im Web gibt es ganz verschiedene User.
Klar ist, dass bei Non-Flash (und im gleichen Atemzug: "Non-Ajax"
Sites die Gesamtgrösse möglichst unter 100k bleiben soll.
- Die eigentliche Antwort liegt für mich in den Server-Statistiken:
Da sehe ich doch, wie lange die Besucher durchschnittlich auf einer bestimmten Seite bleiben. Wenn jetzt gemäss den Stats alle Leute nach 5 Sekunden aus der Index wegklicken, dann "funktioniert" die Seite nicht und man muss was ändern.
Die gewünschte "Landing-Page" ist selten die Index. Es ist eher die Bestellseite, das Anmeldeformular, das Kontaktformular. Die Landing-Page und der "Trampelpfad" dahin sind ebenso wichtig wie die Index: Falls die definierte Landing-Page gemäss den Stats eine typische "Exit-Page" geworden ist, dann muss halt so lange verändert werden, bis die Leute dort landen wo man sie haben will.
Je nach jeweiliger Strategie für das Projekt. Richtwerte sind nur Theorie und was Nielsen im 2001 sagte, gilt noch immer.
Denn Theorien gehen im Web meistens nicht auf. Die Server-Statistiken sind der Schlüssel zur Praxis, das Tweaking ist der Weg. Es gibt superschlanke Websites die gut bei den Besuchern ankommen, genauso gibt es total überladene Websites die noch viel mehr Erfolg erzeugen. Und nun?
Nur die Server-Statistiken zeigen, ob das "Timing" einer Website für die Leute funktioniert oder nicht. Weit hergeholt, aber ists nicht ähnlich wie bei Restaurants: Die einen Gäste warten geduldig eine halbe Stunde lang auf einen freien Tisch, die anderen latschen nach zehn Sekunden hinaus weil ihnen das zuviel ist. Welche Gäste will man nun haben? Darum bin ich für Logfile-Analyse, Clickpath-Analyse (so was gibt es auch in cool), für flexible Anpassungen an das beobachtete Besucherverhalten statt Pauschalisierung.
Die Anschlussfrage wäre jetzt: Warum sollen neue Websites im Jahre 2006 entsprechend den "W3C Web Standards" erstellt werden, was bringt XHTML wenn es doch meistens als HTML ausgeliefert wird, und werden "standards-compliant" Sites tatsächlich kleiner / schneller, und vielleicht sogar besser durch die Sumas indexiert? Ein Thema, das auch was mit "Ladezeit einer Internetseite" zu tun hat.
Huch, das ist ja 1,2 KB zuviel... Scherz.
Kommt immer drauf an, was der Besucher haben will. Wenn ihm das wichtig genug ist, wartet der auch auf 200KB.
Noch extremer, weil Realität:
Ich biete zum Beispiel Sites an (zum Anschauen), bei denen die User erst *nach fünf Minuten Ladezeit* langsam zu motzen beginnen, es dauere zu lange. Richtig geraten, Flash - das natürlich absolut nicht mehr im Trend liegt und immer öfter geskippt wird (weil alles was sich bewegt nach Werbung aussieht), aber es gibt immer noch Leute die das sehen wollen. Egal obs minutenlang dauert.
Jetzt bin ich abgeschweift, aber für mich ist klar: Kommt immer auf die User an, die Zielgruppe, die Wichtigkeit oder eben auch Attraktivität einer Site.
Pauschalisierende Sprüche wie "darf maximal X gross und Z lange sein" sind bekannt aber realitätsfremd, im Web gibt es ganz verschiedene User.
Klar ist, dass bei Non-Flash (und im gleichen Atemzug: "Non-Ajax"
Sites die Gesamtgrösse möglichst unter 100k bleiben soll.- Die eigentliche Antwort liegt für mich in den Server-Statistiken:
Da sehe ich doch, wie lange die Besucher durchschnittlich auf einer bestimmten Seite bleiben. Wenn jetzt gemäss den Stats alle Leute nach 5 Sekunden aus der Index wegklicken, dann "funktioniert" die Seite nicht und man muss was ändern.
Die gewünschte "Landing-Page" ist selten die Index. Es ist eher die Bestellseite, das Anmeldeformular, das Kontaktformular. Die Landing-Page und der "Trampelpfad" dahin sind ebenso wichtig wie die Index: Falls die definierte Landing-Page gemäss den Stats eine typische "Exit-Page" geworden ist, dann muss halt so lange verändert werden, bis die Leute dort landen wo man sie haben will.
Je nach jeweiliger Strategie für das Projekt. Richtwerte sind nur Theorie und was Nielsen im 2001 sagte, gilt noch immer.
Denn Theorien gehen im Web meistens nicht auf. Die Server-Statistiken sind der Schlüssel zur Praxis, das Tweaking ist der Weg. Es gibt superschlanke Websites die gut bei den Besuchern ankommen, genauso gibt es total überladene Websites die noch viel mehr Erfolg erzeugen. Und nun?
Nur die Server-Statistiken zeigen, ob das "Timing" einer Website für die Leute funktioniert oder nicht. Weit hergeholt, aber ists nicht ähnlich wie bei Restaurants: Die einen Gäste warten geduldig eine halbe Stunde lang auf einen freien Tisch, die anderen latschen nach zehn Sekunden hinaus weil ihnen das zuviel ist. Welche Gäste will man nun haben? Darum bin ich für Logfile-Analyse, Clickpath-Analyse (so was gibt es auch in cool), für flexible Anpassungen an das beobachtete Besucherverhalten statt Pauschalisierung.
Die Anschlussfrage wäre jetzt: Warum sollen neue Websites im Jahre 2006 entsprechend den "W3C Web Standards" erstellt werden, was bringt XHTML wenn es doch meistens als HTML ausgeliefert wird, und werden "standards-compliant" Sites tatsächlich kleiner / schneller, und vielleicht sogar besser durch die Sumas indexiert? Ein Thema, das auch was mit "Ladezeit einer Internetseite" zu tun hat.