US DOD MIL-STD 1472-F Human Engineering Standard имеет наиболее широко принятые требования для максимально допустимого времени ответа (из таблицы XXII, стр. 196, время в секундах):
Key Response (нажатие клавиши до положительного ответа, например, «щелчок»): 0,1
Печать ключа (нажатие клавиши до появления символа): 0,2
Поворот страницы (конец запроса до появления первых нескольких строк): 1,0
Сканирование страницы (конец запроса, пока текст не начинает прокручиваться): 0,5
XY Ввод (от выбора поля до визуальной проверки): 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 с, вам необходимо предоставить обратную связь, такую как спрайтер или пульсатор. Если время отклика составляет минимум 5-15 с (в зависимости от используемого вами стандарта), укажите индикатор выполнения. При использовании индикатора выполнения очень длительное время отклика (порядка или минуты в течение даже часов) может быть приемлемым, если вы настроите его для пользователя как «пакетный» процесс, а не как интерактивная программа. Гораздо лучше для пользователя сделать весь ввод и подождать час, чем делать ввод четыре раза, ожидая 15 минут после каждого.
Приведенный выше список соответствует принятым стандартам. Как долго ваши пользователи готовы ждать (например, перед тем, как сдаться), по существу сводятся к тому, что пользователь делает анализ затрат и выгод. Что я собираюсь получить стоит ждать? Каковы мои потраченные расходы? Есть ли альтернатива (например, другой веб-сайт), которая может сделать это лучше? Могу ли я заниматься другими делами, пока жду, чтобы максимально использовать свое время? Тем не менее, независимо от того, что пользователи захотят сделать, вы можете поспорить, что они будут повторять задержки, превышающие указанные выше стандарты.