Điều gì được coi là thời gian đáp ứng tốt cho một ứng dụng web năng động, được cá nhân hóa? [đóng cửa]


152

Đối với một ứng dụng web phức tạp bao gồm nội dung động và cá nhân hóa, thời gian phản hồi tốt từ máy chủ (để loại trừ độ trễ mạng và thời gian kết xuất trình duyệt) là gì? Tôi đang suy nghĩ về các trang web như Facebook, Amazon, MyYahoo, v.v ... Một câu hỏi liên quan là thời gian phản hồi tốt cho dịch vụ phụ trợ là gì?


1
Đối với một trang web như Facebook, họ có thời gian 1,8-2 giây cho byte đầu tiên / bao gồm một đoạn nội dung tốt trên trang. Sau đó, họ khởi động phần còn lại của nội dung trong 1-2 giây tiếp theo.
Giải pháp web MKN

Câu trả lời:


161

Có rất nhiều nghiên cứu về điều này. Đây là một bản tóm tắt nhanh chóng .

Thời gian phản hồi: 3 giới hạn quan trọng

bởi Jakob Nielsen vào ngày 1 tháng 1 năm 1993

Tóm tắt: Có 3 giới hạn thời gian chính (được xác định bởi khả năng nhận thức của con người) cần ghi nhớ khi tối ưu hóa hiệu suất của web và ứng dụng.

Trích từ Chương 5 trong cuốn sách Kỹ thuật sử dụng của tôi , từ năm 1993:

Những lời khuyên cơ bản liên quan đến thời gian trả lời là giống nhau trong ba mươi năm [Miller 1968; Thẻ et al. 1991]:

  • 0,1 giây là giới hạn để người dùng cảm thấy rằng hệ thống đang phản ứng tức thời , nghĩa là không cần phản hồi đặc biệt nào ngoại trừ việc hiển thị kết quả.
  • 1,0 giây là khoảng giới hạn để dòng suy nghĩ của người dùng không bị gián đoạn, mặc dù người dùng sẽ nhận thấy sự chậm trễ. Thông thường, không có phản hồi đặc biệt là cần thiết trong thời gian trễ hơn 0,1 nhưng dưới 1,0 giây, nhưng người dùng sẽ mất cảm giác vận hành trực tiếp trên dữ liệu.
  • 10 giây là giới hạn để giữ sự chú ý của người dùng tập trung vào cuộc đối thoại. Đối với sự chậm trễ lâu hơn, người dùng sẽ muốn thực hiện các tác vụ khác trong khi chờ máy tính kết thúc, vì vậy họ sẽ được cung cấp phản hồi cho biết khi nào máy tính dự kiến ​​sẽ được thực hiện. Phản hồi trong thời gian trễ đặc biệt quan trọng nếu thời gian phản hồi có khả năng thay đổi cao, vì khi đó người dùng sẽ không biết phải mong đợi điều gì.

32
Điều này vẫn còn tốt trong năm 2017 ??
Karthik Cherukuri

27
@KarthikCherukuri - vâng, nó vẫn có liên quan. Câu trả lời là nói về nhận thức của con người, đó là một chức năng của sinh học. Khoảng thời gian giữa năm 1993 và ngày nay là khá nhỏ khi nói đến quy mô thời gian tiến hóa. Giải phẫu thần kinh của chúng ta bây giờ cũng giống như lúc đó.
rianjs

13

Chúng tôi cố gắng cho thời gian phản hồi là 20 mili giây, trong khi một số trang phức tạp mất tới 100 mili giây. Đối với các trang phức tạp nhất, chúng tôi chia trang thành các phần nhỏ hơn và sử dụng mẫu hiển thị lũy tiến để tải từng phần. Bằng cách này, một số phần tải nhanh, ngay cả khi trang mất 1 đến 2 giây để tải, giữ cho người dùng tham gia trong khi phần còn lại của trang đang tải.


Có lẽ 2000 mili giây và 10000 ms?
Bob

9
Có lẽ anh ta thực sự có nghĩa là 20 mili giây. Ứng dụng tôi hiện đang làm việc có thời gian phản hồi thông thường trung bình khoảng 15 ms (khi thử nghiệm cục bộ trên máy tính xách tay của tôi). Thật không phải là những gì hầu hết người dùng thực sự nhìn thấy, thật không may, vì họ ở rất xa máy chủ, cộng với đó cũng là thời gian kết xuất mà bạn phải đưa vào. Nhưng từ góc độ ứng dụng thuần túy, 15, hoặc thậm chí là dưới 10 tuổi, là rất có thể, ngay cả đối với một ứng dụng thương mại điện tử phức tạp.
Aquarelle

6

Tôi đã phấn đấu <3 giây cho các ứng dụng của mình, nhưng tôi hơi kén chọn khi nói đến hiệu suất.

Nếu bạn hỏi xung quanh, họ nói rằng mọi người bắt đầu mất hứng thú trong phạm vi> = 7 giây, trong vòng 10 - 15 giây bạn thường mất họ, trừ khi bạn THỰC SỰ có thứ họ muốn hoặc cần.


2
3 giây cho máy chủ ứng dụng hoặc kết xuất trên trình duyệt? Tôi nhắm đến 100mSec cho máy chủ ứng dụng. nhưng 4 giây trên trình duyệt.
drhenner

2
<3 âm thanh giống như bạn đang nói về thời gian tải trang không giống với thời gian phản hồi.
markus

5

Nó phụ thuộc vào những gì giữ cho người dùng của bạn hạnh phúc. Ví dụ: Gmail mất khá nhiều thời gian để mở lúc đầu, nhưng người dùng chờ đợi vì nó đáng để chờ đợi.


Điều đó công bằng. Câu hỏi của tôi là một chút chung chung. Tôi đoán tôi đang tìm kiếm những con số trong thế giới thực về những gì mọi người đang phấn đấu. Một biết rất nhiều của nó phụ thuộc vào tình hình. Cảm ơn!
Michael Bobick

1
Càng nhanh càng tốt.
Tomkay

5

Tất nhiên, nó nằm trong bản chất của câu hỏi của bạn, vì vậy câu trả lời rất chủ quan.

Phản hồi đầu tiên của một trang web cũng chỉ là một phần nhỏ của thời gian cho đến khi một trang có thể đọc / sử dụng được.

Tôi khó chịu bởi mọi thứ lớn hơn 10 giây. Tôi nghĩ rằng một trang web nên được hiển thị sau 5-7 giây.

Btw: stackoverflow.com có ​​thời gian phản hồi tuyệt vời!


3

Công ty chúng tôi có giới hạn tiêu chuẩn thời gian phản hồi 5 giây và chúng tôi nhắm đến 2-3 giây nói chung. Điều này chiếm 98% tải trang. Một vài tác vụ cụ thể được phép kéo dài tối đa 15 giây, nhưng sau đó chúng tôi giảm thiểu thời gian đó bằng cách đưa lên một trang và làm mới cứ sau 5 giây nói với người dùng rằng chúng tôi vẫn đang cố xử lý yêu cầu. Bằng cách đó, người dùng thấy rằng một cái gì đó đang xảy ra và không chỉ để lại. Mặc dù, xem xét rằng tôi làm việc trên một trang web mà người dùng buộc phải sử dụng vì lý do kinh doanh, họ sẽ không rời đi, nhưng họ có khả năng phàn nàn khá lớn.

Nói chung, nếu quá trình xử lý sẽ mất hơn 5 giây, hãy tạo một trang tạm thời để người dùng không mất hứng thú.


2

Tôi nghĩ bạn sẽ thấy rằng nếu ứng dụng web của bạn đang thực hiện một thao tác phức tạp thì cung cấp phản hồi được cung cấp cho người dùng, họ sẽ không bận tâm (quá nhiều).

Ví dụ: Đang tải Google Mail.


1

Nó không chỉ phụ thuộc vào những gì giữ cho người dùng của bạn hạnh phúc, mà bạn còn có bao nhiêu thời gian phát triển? Loại tài nguyên nào bạn có thể ném vào vấn đề (phần mềm, phần cứng và con người)?

Tôi không ngại một vài giây chậm trễ cho các ứng dụng được lưu trữ nếu chúng đang làm một cái gì đó "phức tạp". Nếu nó thực sự đơn giản, sự chậm trễ làm phiền tôi.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.