Co jest uważane za dobry czas odpowiedzi w przypadku dynamicznej, spersonalizowanej aplikacji internetowej? [Zamknięte]


152

Jaki jest dobry czas odpowiedzi serwera (z wyłączeniem opóźnienia sieci i czasu renderowania przeglądarki) w przypadku złożonej aplikacji internetowej zawierającej dynamiczną zawartość i personalizację? Myślę o witrynach takich jak Facebook, Amazon, MyYahoo itp. Powiązane pytanie brzmi: jaki jest dobry czas odpowiedzi dla usługi backendu?


1
W przypadku witryn takich jak Facebook mają one czas 1,8-2 sekundy do pierwszego bajtu / który zawiera sporą część treści na stronie. Następnie AJAX resztę treści w ciągu następnych 1-2 sekund.
MKN Web Solutions,

Odpowiedzi:


161

Jest wiele badań na ten temat. Oto krótkie podsumowanie .

Czas reakcji: 3 ważne ograniczenia

przez Jakoba Nielsena w dniu 1 stycznia 1993 roku

Podsumowanie: Istnieją 3 główne ograniczenia czasowe (które są określane przez ludzkie zdolności percepcyjne), o których należy pamiętać podczas optymalizacji wydajności sieci i aplikacji.

Fragment z rozdziału 5 mojej książki Inżynieria użyteczności z 1993 roku:

Podstawowe rady dotyczące czasów odpowiedzi były mniej więcej takie same od trzydziestu lat [Miller 1968; Card i in. 1991]:

  • 0,1 sekundy to granica pozwalająca użytkownikowi poczuć, że system reaguje natychmiastowo , co oznacza, że ​​nie jest potrzebna żadna specjalna informacja zwrotna poza wyświetleniem wyniku.
  • 1,0 sekunda to limit dla przepływu myśli użytkownika, który pozostaje nieprzerwany, nawet jeśli użytkownik zauważy opóźnienie. Zwykle nie jest wymagana żadna specjalna informacja zwrotna w przypadku opóźnień większych niż 0,1, ale krótszych niż 1,0 sekundy, ale użytkownik traci poczucie, że operuje bezpośrednio na danych.
  • 10 sekund to limit skupienia uwagi użytkownika na dialogu. W przypadku dłuższych opóźnień użytkownicy będą chcieli wykonywać inne zadania, czekając na zakończenie pracy komputera, dlatego powinni otrzymać informację zwrotną wskazującą, kiedy komputer oczekuje na wykonanie. Informacje zwrotne w czasie opóźnienia są szczególnie ważne, jeśli czas odpowiedzi może być bardzo zmienny, ponieważ użytkownicy nie będą wtedy wiedzieć, czego się spodziewać.

32
Czy to nadal jest dobre w 2017 roku?
Karthik Cherukuri

27
@KarthikCherukuri - tak, to nadal aktualne. Odpowiedź mówi o ludzkiej percepcji, która jest funkcją biologii. Okres między 1993 r. A dniem dzisiejszym jest dość krótki, jeśli chodzi o ewolucyjne skale czasu. Nasza neuroanatomia jest teraz taka sama jak wtedy.
rianjs

13

Staramy się, aby czas odpowiedzi wynosił 20 milisekund, podczas gdy niektóre złożone strony zajmują do 100 milisekund. W przypadku najbardziej złożonych stron dzielimy stronę na mniejsze części i używamy schematu wyświetlania progresywnego, aby załadować każdą sekcję. W ten sposób niektóre fragmenty ładują się szybko, nawet jeśli strona ładuje się od 1 do 2 sekund, co powoduje, że użytkownik jest zajęty, podczas gdy reszta strony się ładuje.


Może 2000 milisekund i 10000 ms?
Bob

9
Może naprawdę miał na myśli 20 milisekund. Aplikacja, nad którą obecnie pracuję, ma typowe czasy odpowiedzi wynoszące średnio około 15 ms (podczas testowania lokalnie na moim laptopie). Niestety, nie to widzi większość użytkowników, ponieważ znajdują się daleko od serwera, a ponadto jest czas na renderowanie, który musisz uwzględnić. Ale z perspektywy samej aplikacji 15, a nawet nieco poniżej 10 lat jest bardzo możliwe, nawet w przypadku złożonej aplikacji e-commerce.
Aquarelle

6

Dążę do <3 sekund dla moich aplikacji, ale jestem trochę wybredny, jeśli chodzi o wydajność.

Jeśli zapytasz wokół, powiedzą, że ludzie zaczynają tracić zainteresowanie w zakresie> = 7 sekund, o 10-15 sekund zazwyczaj tracisz ich, chyba że NAPRAWDĘ masz coś, czego chcą lub potrzebują.


2
3 sekundy na serwer aplikacji lub renderowanie w przeglądarce? Dążę do 100mSec dla serwera aplikacji. ale 4 sekundy w przeglądarce.
drhenner

2
<3 brzmi bardziej tak, jakbyś mówił o czasie ładowania strony, który nie jest tym samym, co czas odpowiedzi.
markus

5

To zależy od tego, co uszczęśliwia użytkowników. Na przykład Gmail zajmuje na początku trochę czasu, ale użytkownicy czekają, ponieważ warto na to czekać.


To uczciwe. Moje pytanie jest trochę ogólne. Myślę, że szukam rzeczywistych liczb tego, do czego dążą ludzie. Wiem, wiele zależy od sytuacji. Dzięki!
Michael Bobick

1
Im szybciej, tym lepiej.
Tomkay,

5

Oczywiście leży to w naturze twojego pytania, więc odpowiedzi są wysoce subiektywne.

Pierwsza odpowiedź strony internetowej to również tylko niewielka część czasu, zanim strona stanie się czytelna / użyteczna.

Denerwują mnie odpowiedzi większe niż 10 sekund. Myślę, że strona powinna zostać wyrenderowana po 5-7 sekundach.

Btw: stackoverflow.com ma doskonały czas odpowiedzi!


3

Nasza firma ma standardowy czas reakcji wynoszący 5 sekund, a naszym celem jest generalnie 2-3 sekundy. Odpowiada to za 98% wczytywania stron. Kilka określonych zadań może trwać do 15 sekund, ale następnie zmniejszamy ten czas, umieszczając stronę i odświeżając ją co 5 sekund, informując użytkownika, że ​​nadal próbujemy przetworzyć żądanie. W ten sposób użytkownik widzi, że coś się dzieje i nie odchodzi. Chociaż, biorąc pod uwagę, że pracuję na stronie, z której użytkownicy są zmuszeni korzystać ze względów biznesowych, nie zamierzają odchodzić, ale potrafią narzekać dość głośno.

Ogólnie rzecz biorąc, jeśli przetwarzanie ma zająć więcej niż 5 sekund, umieść tymczasową stronę, aby użytkownik nie stracił zainteresowania.


2

Myślę, że przekonasz się, że jeśli Twoja aplikacja internetowa wykonuje złożoną operację, a użytkownik otrzyma informację zwrotną, nie będzie miał nic przeciwko (zbytnio).

Na przykład: Ładowanie poczty Google.


1

Zależy to nie tylko od tego, co uszczęśliwia Twoich użytkowników, ale także od tego, ile masz czasu na rozwój? Jakie zasoby możesz rzucić na problem (oprogramowanie, sprzęt i ludzie)?

Nie przeszkadza mi kilkusekundowe opóźnienie aplikacji hostowanych, jeśli robią coś „złożonego”. Jeśli to naprawdę proste, przeszkadzają mi opóźnienia.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.