（軟）實時延遲是否有普遍接受的定義？

Question

我試圖找到用戶願意等待遠程服務響應多長時間的基準。在我的情況下，迴應是非常有用的，但不是數據輸入的業務關鍵驗證。我猜想在HCI領域肯定有一些工作要做。

如果您知道soft的普遍接受的定義，那麼實時響應很棒，但我也很感謝您的理由。

Chris

Answer 1

美國國防部MIL-STD 1472-F人體工程學標準有（以秒從表二十二，第196頁，次）的最大允許響應時間最廣爲接受的要求：

密鑰響應（按下按鍵，直到正響應，例如「點擊」）：0。1

密鑰打印（鍵按壓直到字符的外觀）：0.2

頁轉到（請求結束直到前幾行是可見的）：1.0

尋呼掃描（的請求結束直到文本開始滾動）：0.5

XY項（From字段的選擇，直到視覺驗證）：0.2

功能（從命令選擇直到響應）：2.0

指點（從點的輸入，以顯示點）：0.2

草圖（從點的輸入，顯示線路的）：0.2

本地更新（使用本地數據的基礎上切換到圖像，例如，新的菜單列表）：0.5

主機更新（從顯示緩衝器）：2.0

文件更新（改變，其中數據是在宿主中容易地訪問的形式）：10.0

詢問 - 簡單（例如，尺度變化的現有的圖像）：2.0

詢問 - 絡合物（圖像更新需要接入到主機文件）：直到一個常用的消息的顯示10.0

誤差反饋（從命令）：2.0

正如你可以看到，可接受的響應時間取決於用戶等待的響應。對於類似下拉菜單的內容，最多爲0.5秒。對於瀏覽器中的整頁加載，您希望某些內容在1.0秒到2.0秒之間出現，並且整個頁面在10.0秒內加載。在上述所有情況中，響應時間越短越好。只有在奇怪的情況下，用戶纔會反應0.001秒的響應時間。

在任何情況下，如果響應時間大於0.5 s，則需要提供諸如跳動或沙漏精靈等反饋。如果響應時間至少爲5-15秒（取決於您使用的標準），請提供進度條。使用進度條，只要您將用戶設置爲「批處理」進程而非交互式程序，就可以接受非常長的響應時間（按訂單或甚至幾小時的分鐘數）。用戶輸入所有內容並等待一個小時比輸入四次更好，每次輸入後等待15分鐘。

以上列表具有可接受的標準。 願意等待的時間（例如，在放棄之前）基本歸結爲進行成本收益分析的用戶。我將會值得等待嗎？我的沉沒成本是多少？是否有替代方案（例如另一個網站）可以做得更好？我可以在等待充分利用時間的同時做其他事情嗎？然而，無論用戶願意做什麼，你都可以打賭他們會拖延超過上述標準。

Answer 2

不幸的是，這個問題的答案通常不是一個明確定義的數字。用戶的期望差異很大，可以根據你在說什麼改變。隨着計算機越來越普及，我們（消費者）對速度的期望越來越高，遠程服務，網站甚至應用程序都需要繼續更快速地響應。一般來說，你希望一切都儘可能快。

這樣說，我會看看你的遠程服務是什麼。既然你說過，「迴應對我來說非常有用......」，這意味着它可能會經常使用。人們傾向於使用有用的東西。如果是這樣的話，我會尋找讓遠程服務迅速響應的方法。

當然，在服務寫入之前，您也不希望開始優化。目前的響應時間是多少？這將被用於什麼背景？這些因素將對確定最長的用戶願意等待該服務有很大的幫助。

Answer 3

人類反應時間似乎在200 ms左右 - 任何附近的東西都會被視爲瞬時。這種數字很難實現，特別是在從遠程服務獲取信息的應用程序中。

如果你看一下Google的搜索建議框，那麼滯後很小 - 不到一秒鐘。它的速度非常快，對於一個Web應用程序來說真的很棒。這對Google用戶來說真的很不錯，但這對你來說是個壞消息。現在，用戶希望大多數應用程序能夠以相同的速度和效率進行反應;任何慢的都被認爲是相當滯後的。但值得注意的是，人們的耐心往往隨着手頭任務的複雜程度而變化。簡單的表單提交應該不會花費太多時間，但上傳照片等內容預計需要一段時間。

我的感覺是這樣的：走你的直覺。如果您的應用程序非常簡單，那麼您應該嘗試將等待/加載時間縮短到不到一秒鐘。如果你不能，那麼你最好的選擇就是添加一個指標，這樣用戶就知道一些計算正在後臺完成。這可以是小動畫或進度條的形式。

Answer 4

您可能想要搜索「SLA」或「服務等級協議」。這些是Web業務中的文檔，可以確保數據返回給用戶的時間長度，無論是HTML文檔還是Web服務調用。