Nina: Akzeptable Ladezeiten

Hallo an alle,

kann mir jemand sagen was man unter akzeptable Ladezeiten einer Seite versteht?
Wie lange kann man einem User zumuten zu warten bis die Seite geladen ist (unabhängig von der Bandbreite)?

Ich weiss, das hängt u.a. auch davon ab wie wichtig die von ihm erwarteten Infos sind.

Kann man da pauschal von 10-15 Sekunden ausgehen oder ist das schon zu viel?

Gruss
Nina

  1. Hi Nina,
    also für meinen Geschmack sind 15 Sekunden Ladezeit bei der Startseite zulange.
    Bei unterseiten ist das okeay es sollte aber versucht werden die Ladezeiten zu gering wie möglich zuhalten.
    MFG
    Otto

    1. Hallo Otto,

      also für meinen Geschmack sind 15 Sekunden Ladezeit bei der Startseite zulange.

      Ich meine bei Seiten allgemein, nicht unbedingt bei der Startseite.

  2. Hallo,

    kann mir jemand sagen was man unter akzeptable Ladezeiten einer Seite versteht?
    Wie lange kann man einem User zumuten zu warten bis die Seite geladen ist (unabhängig von der Bandbreite)?

    Für die Homepage halte ich ein Datenvolumen von insgesamt 100 KB für
    durchaus akzeptabel. Nach Möglichkeit natürlich weniger - google.com
    hat z.Bsp. ca. 13 KB - und in Sonderfällen - die Homepage dieses
    Forums z.Bsp. - darf es auch mal mehr sein.

    Viele Grüße,
    Stefan

    PS: Ich weiß, dass die Forumsstartseite je nach Browser unterschied-
        liche Ladezeiten hat ...

    1. Für die Homepage halte ich ein Datenvolumen von insgesamt 100 KB für
      durchaus akzeptabel. Nach Möglichkeit natürlich weniger -

      meinst Du damit 100KB pro einzelne Seite incl. der darin verwendeten Ressourcen(images, flash...)?

      1. Moin!

        meinst Du damit 100KB pro einzelne Seite incl. der darin verwendeten Ressourcen(images, flash...)?

        Das kommt auf die Seite an. Hier rechnet jeder damit und es besteht ein gewisser Antrieb, die Seite zu laden. Darüberhinaus sind ja schon Informationen lesbar, während die Seite lädt.

        100 KB = 800 Kbit /56 =~ 15 Sekunden. Dazu kommt noch die Zeit für die DNS- Auflösung und bis der Server überhaupt reagiert.

        Setz Dich einfach mal hin und warte 15 Sekunden. Dann überlege, was Deine Benutzer davon halten könnten.

        Eine Startseite sollte jedenfalls _deutlich_  kleiner sein. Bei weiteren Informationen, die der Nutzer über einen Link aufruft und wo er eine gewisse Erwartungshaltung mitbringt, da wartet der auch gerne mal.

        15KB Gesamtdatenmenge sind das gar nicht so schwer zu erreichende Optimum (~2s für Modembenutzer). Zur Not verzichte auf Werbebanner und Flash.

        MFFG (Mit freundlich- friedfertigem Grinsen)

        fastix®

        --
        Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch  für seriöse Agenturen.
        1. Hello,

          100 KB = 800 Kbit /56 =~ 15 Sekunden. Dazu kommt noch die Zeit für die DNS- Auflösung und bis der Server überhaupt reagiert.

          Müsste man für Modemverbindungen nicht sogar mit 900kBit rechnen? I.d.R wird doch 8N1 benutzt. Und die 56k beziehen sich doch auf die echte Übertragungsrate und nicht auf die Netto-Daten-Nutzrate. Oder liege ich falsch?

          Liebe Grüße aus http://www.braunschweig.de

          Tom

          --
          Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
          1. Moin!

            Müsste man für Modemverbindungen nicht sogar mit 900kBit rechnen? I.d.R wird doch 8N1 benutzt. Und die 56k beziehen sich doch auf die echte Übertragungsrate und nicht auf die Netto-Daten-Nutzrate. Oder liege ich falsch?

            Nö. Die Byte-Bit Umrechnung ist 1 zu 8. Am ehesten müsste dann beim Modem (also bei den 56kb/s) was für die Übertragungszeit abgezogen werden. Aber in der Materie stecke ich momentan nicht so tief drin.

            MFFG (Mit freundlich- friedfertigem Grinsen)

            fastix®

            --
            Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch  für seriöse Agenturen.
            1. Moin!

              Müsste man für Modemverbindungen nicht sogar mit 900kBit rechnen? I.d.R wird doch 8N1 benutzt. Und die 56k beziehen sich doch auf die echte Übertragungsrate und nicht auf die Netto-Daten-Nutzrate. Oder liege ich falsch?

              Nö. Die Byte-Bit Umrechnung ist 1 zu 8. Am ehesten müsste dann beim Modem (also bei den 56kb/s) was für die Übertragungszeit abgezogen werden. Aber in der Materie stecke ich momentan nicht so tief drin.

              56 KBit/s ist die Baud-Rate der Leitung. Bei 8N1 werden 10 Bit übertragen, wenn 8 Bit Nutzdaten gesendet werden.

              Daraus folgt: Es werden durchschnittlich 5,6 KByte je Sekunde Nutzdaten auf einer 56KBit-Leitung übertragen.

              Das Teilen einer Modem-Datenrate durch 10 entspricht der empirisch ermittelbaren Praxis. Und ist außerdem leichter. :) Und obendrein kommt noch weiterer Overhead hinzu, der auch berücksichtigt werden will, TCP/IP beispielsweise.

              - Sven Rautenberg

              --
              Die SelfHTML-Developer sagen Dankeschön für aktuell 12726,12 Euro Spendengelder!
          2. Moin!

            Müsste man für Modemverbindungen nicht sogar mit 900kBit rechnen? I.d.R wird doch 8N1 benutzt. Und die 56k beziehen sich doch auf die echte Übertragungsrate und nicht auf die Netto-Daten-Nutzrate. Oder liege ich falsch?

            Zu 8N1: Das sind je Nutzbyte (zu 8 Bit) genau 10 Bit Datenmenge. Ein Startbit wird nämlich auch noch übertragen.

            Zu 56K brutto/netto: So genau ist das nicht unbedingt geklärt, aber meine empirischen Erfassungen deuten darauf hin, dass es sich um die tatsächliche Baud-Rate handelt, nicht um die Geschwindigkeit des errichteten Kanals.

            - Sven Rautenberg

            --
            Die SelfHTML-Developer sagen Dankeschön für aktuell 12726,12 Euro Spendengelder!
            1. Hello,

              Zu 8N1: Das sind je Nutzbyte (zu 8 Bit) genau 10 Bit Datenmenge. Ein Startbit wird nämlich auch noch übertragen.

              Hier motzt der alte Assembler-Knochen aber gewaltig!

              8 Datenbit, Null parity, 1 Stoppbit.

              Die Übetragungsraten ergeben sich aus der Teilereinstellung der Schnittstelle. 115.200 Takte/Sec ist das Maximum. Wenn man die so teilt, dass ganze Zahlen dabei herauskommen, hat man die möglichen Übertragungsraten. Und dabei handelt es sich tatsächlich um die am Port der seriellen Schnittstelle ankommenden Bits.

              Teiler  Bitrate
                1     115.200
                2      57.600    das ist das sogenannte 56k-Modem
                3      38.400
                4      28.800
                5      23.040    wird aber selten unterstützt, theoretisch aber möglich
                6      19.200
                7                geht nicht
                8      14.400
                9      12.800
               10      11.520    sehr selten
               11                geht nicht
               12       9.600    Heute noch für Fax
               13                geht nicht
               14                geht nicht
               15       7.680
               16       7.200
               17                geht nicht
               18       6.400
               19
               20       5.760
               21
               22
               23       4.800
               25       4.608
               26
               ..
               32       3.600
               na und so weiter bis runter zu
              384         300    so fing das mal an mit Akutik-Koppler

              Und das ist auch lesenswert:
              http://netzmafia.de/skripten/modem/dfue1.html#1.2.2

              Wenn es die Pioniere nicht gegeben hätte, müssten wir unser HTML&Co-Forum heute per Trommel organisieren. Wäre dch auch ganz nett *grins*

              Liebe Grüße aus http://www.braunschweig.de

              Tom

              --
              Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
              1. Hi,

                Wenn es die Pioniere nicht gegeben hätte, müssten wir unser HTML&Co-Forum heute per Trommel organisieren. Wäre dch auch ganz nett *grins*

                ... und nicht zu vergessen die "Mutigen", die trotz Warnung und Verbot seitens der damaligen Post nichtzugelassene Importmodems verwendet und mit Baudraten von 2400 oder gar 9600 "Leitungsschäden" riskiert hatten..;-)

                freundliche Grüße
                Ingo

                1. Hello,

                  ... und nicht zu vergessen die "Mutigen", die trotz Warnung und Verbot seitens der damaligen Post nichtzugelassene Importmodems verwendet und mit Baudraten von 2400 oder gar 9600 "Leitungsschäden" riskiert hatten..;-)

                  Ja, das waren Verbrecher[tm]. Die haben einfach nicht glauben wollen, dass Kupferleitungen sich bei statischer Beschaltung bei Frequenzen über 4kHz anfangen aufzulösen. Aber vielleicht ging es da ja auch nur um den 16kHz Impuls für die Gebührenzähler oder die guten alten Brückenverstärker in Röhrentechnik. Vielleicht hätte man ja eine RSM (Rufsignalmaschine) auch rückwärts einspeisen können und sie als Motor benutzen können.

                  Das war noch robuste Technik. Da konnte man noch sehen, wo es klemmt. Nicht so wie heute bei MSIE & Co. mit Hintertüren und Tricks....

                  Liebe Grüße aus http://www.braunschweig.de

                  Tom

                  --
                  Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
              2. Moin!

                Zu 8N1: Das sind je Nutzbyte (zu 8 Bit) genau 10 Bit Datenmenge. Ein Startbit wird nämlich auch noch übertragen.

                Hier motzt der alte Assembler-Knochen aber gewaltig!

                8 Datenbit, Null parity, 1 Stoppbit.

                Die Übetragungsraten ergeben sich aus der Teilereinstellung der Schnittstelle. 115.200 Takte/Sec ist das Maximum. Wenn man die so teilt, dass ganze Zahlen dabei herauskommen, hat man die möglichen Übertragungsraten. Und dabei handelt es sich tatsächlich um die am Port der seriellen Schnittstelle ankommenden Bits.

                Ja. Ich stimme absolut überein mit dir. Kein Widerspruch.

                Bei "Teiler 1" kommen 115200 Bits pro Sekunde an der Schnittstelle an. Die hereinkommenden Bits sind (in der Reihenfolge ihres Auftretens):

                1 Startbit, 8 Datenbits, kein Paritätsbit, 1 Stoppbit.
                Summe: 10 Bit.
                Übertragene Datenmenge netto: 8 Bit (= 1 Byte).

                Mit anderen Worten: Die 115200 Bits pro Sekunde auf der Leitung entsprechen 11520 Byte erhaltene Bytes bei der Applikation. Bitrate geteilt durch 10 ergibt Byterate.

                Und das ist auch lesenswert:
                http://netzmafia.de/skripten/modem/dfue1.html#1.2.2

                Genau diese Quelle beweist die Korrektheit meiner obigen Ausführungen. Sieh' dir einfach nur mal die Grafik an. :)

                Wenn es die Pioniere nicht gegeben hätte, müssten wir unser HTML&Co-Forum heute per Trommel organisieren. Wäre dch auch ganz nett *grins*

                Du meinst TCP/IP over Bongo? http://eagle.auc.ca/~dreid/index.html

                Oder TCP/IP over avian carriers (RFC 1149)? ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt

                - Sven Rautenberg

                --
                Die SelfHTML-Developer sagen Dankeschön für aktuell 15671,45 Euro Spendengelder!
                1. Hello,

                  Moin!

                  Zu 8N1: Das sind je Nutzbyte (zu 8 Bit) genau 10 Bit Datenmenge. Ein Startbit wird nämlich auch noch übertragen.

                  Hier motzt der alte Assembler-Knochen aber gewaltig!

                  8 Datenbit, Null parity, 1 Stoppbit.

                  Die Übetragungsraten ergeben sich aus der Teilereinstellung der Schnittstelle. 115.200 Takte/Sec ist das Maximum. Wenn man die so teilt, dass ganze Zahlen dabei herauskommen, hat man die möglichen Übertragungsraten. Und dabei handelt es sich tatsächlich um die am Port der seriellen Schnittstelle ankommenden Bits.

                  Ja. Ich stimme absolut überein mit dir. Kein Widerspruch.

                  Bei "Teiler 1" kommen 115200 Bits pro Sekunde an der Schnittstelle an. Die hereinkommenden Bits sind (in der Reihenfolge ihres Auftretens):

                  1 Startbit, 8 Datenbits, kein Paritätsbit, 1 Stoppbit.

                  oder
                    1 Startbit, 7 Datenbits, 1 Paritätsbit, 1 Stoppbit.
                  oder
                    1 Startbit, 8 Datenbits, kein Paritätsbit, 2 Stoppbit.

                  Summe: 10 Bit.

                  oder 11

                  Übertragene Datenmenge netto: 8 Bit (= 1 Byte).

                  kommt darauf an

                  Nee, eben nicht!
                  <img src="http://netzmafia.de/skripten/modem/modem-121.gif" border="0" alt="">

                  Der Stream besteht aus:
                   1  Startbit      (immer)
                   7  Datenbit      (immer)
                   1  Stoppbit      (falls vereinbart)
                   1  Datenbit      (falls kein Stoppbit vereinbart ist)
                   1  Parity     |  je nach Vereinbarung
                   1  Parity     |

                  Mit anderen Worten: Die 115200 Bits pro Sekunde auf der Leitung entsprechen 11520 Byte erhaltene Bytes bei der Applikation. Bitrate geteilt durch 10 ergibt Byterate.

                  Das sehe ich ein und gebe ich zu.

                  Und das ist auch lesenswert:
                  http://netzmafia.de/skripten/modem/dfue1.html#1.2.2

                  Genau diese Quelle beweist die Korrektheit meiner obigen Ausführungen. Sieh' dir einfach nur mal die Grafik an. :)

                  Wenn es die Pioniere nicht gegeben hätte, müssten wir unser HTML&Co-Forum heute per Trommel organisieren. Wäre dch auch ganz nett *grins*

                  Du meinst TCP/IP over Bongo? http://eagle.auc.ca/~dreid/index.html

                  Oder TCP/IP over avian carriers (RFC 1149)? ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt

                  Nun gut, teile ich demnächst also immer durch 10 un dnicht mehr durch 9,5. Da gabs ja auch mal halbe Stoppbits...

                  Und die automatisch Fehlerkorrektur findet dann ja erst in einer höheren Schicht statt. Allerdings dürfte in der analogen Schicht unter der Bitschicht nochmals eine Korrektur sitzen.

                  Kommt ja auch heutzutage kaum noch Müll an.

                  Liebe Grüße aus http://www.braunschweig.de

                  Tom

                  --
                  Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                  1. Moin!

                    1 Startbit, 8 Datenbits, kein Paritätsbit, 1 Stoppbit.
                    oder
                      1 Startbit, 7 Datenbits, 1 Paritätsbit, 1 Stoppbit.
                    oder
                      1 Startbit, 8 Datenbits, kein Paritätsbit, 2 Stoppbit.

                    Es gibt auch noch ganz andere Konfigurationen: 5E2 beispielsweise. Ungebräuchlich, aber möglich. 5 Datenbits erlauben 63 verschiedene Zeichen - für Fernschreiber absolut ausreichend.

                    1+5+1+2 = 9 Bits.

                    Summe: 10 Bit.
                    oder 11

                    Übertragene Datenmenge netto: 8 Bit (= 1 Byte).
                    kommt darauf an

                    Bei 8N1 nicht, da sind es genau 10 Bit je Nettobyte.

                    Der Stream besteht aus:
                     1  Startbit      (immer)

                    Ja.

                    7  Datenbit      (immer)

                    Datenbits: ja. 7 Stück: nein. Soviele, wie vereinbart (also 5, 6, 7, 8): Ja.

                    1  Stoppbit      (falls vereinbart)
                     1  Datenbit      (falls kein Stoppbit vereinbart ist)

                    Ein Stopbits ist immer dabei. Wahlweise zwei.

                    1  Parity     |  je nach Vereinbarung
                     1  Parity     |

                    Parität ist entweder dabei oder nicht.

                    Und die automatisch Fehlerkorrektur findet dann ja erst in einer höheren Schicht statt. Allerdings dürfte in der analogen Schicht unter der Bitschicht nochmals eine Korrektur sitzen.

                    Wie soll denn da in der analogen Schicht eine Fehlerkorrektur für digitale Daten eingebaut werden? Dem ist nicht so.

                    Kommt ja auch heutzutage kaum noch Müll an.

                    Weil einerseits die Leitungen recht gut geworden sind (das Telefonnetz ist, bis auf die letzte Meile, volldigital), andererseits auf digitaler Ebene Fehlerkorrekturen eingreifen.

                    Zwei Punkte will ich hierzu noch einmal ins Bewußtsein rücken:

                    Erstens sind 56K-Modems, auch wenn sie so heißen, keine Garantie für diese Geschwindigkeit. Wahrscheinlicher ist, dass bei der Synchronisation mit der Gegenstelle eine geringere Geschwindigkeit ausgehandelt wird. 56K-Modems basieren übrigens auf der Tatsache, dass das Telefonnetz volldigital ausgebaut ist, mit einem rein analogen Netz und der darin begrenzten Bandbreite für Sprachübertragung lassen sich nur 33,6K-Modems realisieren (und das ist ja auch die maximale Sendegeschwindigkeit).

                    Zweitens der "Modem-Init-String". Das ist etwas, was heute absolut aus dem Bewußtsein der Benutzer verschwunden ist. Ein Modem wird angeschlossen (seriell oder USB - vollkommen egal) und vom Windows automatisch erkannt. Fertig. Plug'n'play. Dabei werden Default-Werte für den Verbindungsaufbau genutzt und außerdem automatisch ausgehandelt, über die man sich früher langwierig den Kopf zerbrochen hat. Die "8N1"-Geschichte ist nur ein Aspekt. MNP5 oder V.42  (Datenkompression und Fehlerkorrektur) sind andere Aspekte. Wer die längst vergangene Zeit der Mailboxen mitgemacht hat (ich nicht) oder einmal die typische Frage des Compuserve-Supports nach eben jenem "Modem-Init-String" erlebte (ich schon), der wird wissen, was ich meine.

                    Auf analoger Ebene wird der Datenübertragung also nicht geholfen. Aber die Übertragungsverfahren sind beständig besser geworden, korrigieren Fehler nach Möglichkeit selbständig (auch ein Grund, warum das Paritätsbit überflüssig wurde, weil es lediglich Fehlererkennung erlaubt, aber keine Fehlerkorrektur).

                    - Sven Rautenberg

                    --
                    Die SelfHTML-Developer sagen Dankeschön für aktuell 17573,88 Euro Spendengelder!
        2. Hallo fastix®,

          15KB Gesamtdatenmenge sind das gar nicht so schwer zu erreichende Optimum (~2s für Modembenutzer). Zur Not verzichte auf Werbebanner und Flash.

          Juche, 8KB für eine Index/News-Seite :-)

          Gruß,
          small-step

      2. Hallo,

        Für die Homepage halte ich ein Datenvolumen von insgesamt 100 KB für
        durchaus akzeptabel. Nach Möglichkeit natürlich weniger -

        meinst Du damit 100KB pro einzelne Seite incl. der darin verwendeten Ressourcen(images, flash...)?

        zum ersten Teil Deiner Frage: Nein, ich meinte die Homepage, die kann
        m.E. durchaus bis zu 100KB "schwer" sein. Wieviel Datenvolumen Unter-
        seiten haben dürfen, kann man wohl kaum festlegen, da es sehr stark
        von der Art der Website abhängt. Wenn irgendwo steht "Für Bilder von
        unserem letzten Urlaub hier klicken", dann erwarte ich sicher nicht
        eine ausgesprochen schlanke Seite dahinter.

        Und zum zweiten Teil: Mit "insgesamt 100 KB" meinte ich eben die Seite
        incl. der darauf enthaltenen Bilder, CSS- und JS-Dateien etc. Flash
        auf der Homepage einzuzichten, halte ich für verzichtbar, zumindest
        fällt mir kein Beispiel ein, wo es wirklich sinnvoll wäre.

        Viele Grüße,
        Stefan

  3. Hallo,

    kann mir jemand sagen was man unter akzeptable Ladezeiten einer Seite versteht?

    http://www.netmechanic.com/toolbox/html-code.htm sagt Dir, was es von der Ladezeit Deiner (oder einer beliebigen Seite) hält, und gibt auch konkrete Tipps zur Verbesserung.
    Gruß Fritz

    --
    ss:( zu:| ls:# fo:| de:/ va:) ch:? sh:( n4:? rl:? br:$ js:| ie:| fl:| mo:)
  4. Hallo Nina,

    für mich ist nichtdie gesamte  Ladezeit einer Seite entscheidend, sondern, wie lange ich warten muss, bis ich etwas zu sehen oder zu lesen bekomme.
    Wenn also wenige Sekunden nach dem Aufruf einer Seite der Text angezeigt wird, so dass ich sehe, dass die Seite die Informationen enthält, die ich suche, stört es mich nicht weiter, wenn dann Bilder, Layoutgrafiken, Hintergundfarben usw. noch etwas auf sich warten lassen. (natürlich nur, wenn dabei der Text lesbar ist und nicht umher springt)
    Wenn ich bei einer mir unbekannten Seite 10 Sekunden oder länger warte, ohne dass ich etwas (für mich) sinnvolles sehe, drücke ich den Zurück-Button und werde diese Seite vermutlich nie wieder besuchen.

    Unabhängig davon sollte jede Seite (inklusive Grafiken, CSS, Javascript) so klein wie möglich und so groß wie nötig gehalten werden.

    Wenn ich z.B. eine Seite mit Bildern erstelle, und diese unter Rücksicht auf die notwendigen Downloadzeiten sehr klein gehalten sind, biete ich einen Link auf eine identische Seite mit größeren Bilder an, mit dem Hinweis auf die entsprechende Downlaodgröße.
    z.B. in der Art: "Seite mit größeren Bildern (150 kB)"
    Dann kann jeder selbst entscheiden. Wenn er dies will, wird er dann auch warten, bis die Seite komplett geladen ist.

    MFG
    Detlef

    --
    - Wissen ist gut
    - Können ist besser
    - aber das Beste und Interessanteste ist Weg dahin!
  5. kann mir jemand sagen was man unter akzeptable Ladezeiten einer Seite versteht?

    Jakob Nielsen meint:

    • nach 2 s sollte dem Benutzer klar sein, warum er warten will
    • nach 10 s sollte dem Benutzer klar sein, warum er bleiben will
    • optimale Ladezeit: 1 s

    aus: Manhartsberger, Martina & Musil, Sabine: Web-Usability: Das Prinzip des Vertrauens. Bonn: Galileo Design, 2002

    Gunnar

    --
    Good results come from experience; and experience comes from bad results.