Сколько времени является слишком длинным, чтобы сценарий выполнился?
То, каково макс. время, делают Вы думаете, приемлемо для веб-сценария (PHP, например) для выполнения, прежде чем он начнет становиться раздражением для пользователя (в среднем)? Я всегда думал что, если пользователь должен ожидать больше чем 1 секунда страницы для загрузки (это, конечно после того, как изображения и CSS кэшировались.. это правило действительно только касается последующих запросов), они начали бы раздражаться.
9 ответов
42 секунды.
На самом деле, правда в том, что это больше зависит от возраста и ожиданий пользователя, которого вы обслуживаете. Мои родители, например, могут быть гораздо более терпимы к длительному ожиданию, но также с большей вероятностью будут нажимать на кнопку снова и снова, как они будут нажимать на кнопку перехода или лифта.
Таким образом, реальный ответ заключается в том, как долго пользователь может оставаться без обратной связи? Даже быстрый логотип в виде песочных часов или индикатора выполнения может иметь для пользователя значение. При этом, если сервис, который вы предоставляете, должен работать в режиме реального времени и действовать как настольное приложение, слишком долгое время - это, по сути, "все, что ощутимо".
Итак, ответ на вопрос - зависит от ситуации. Тем не менее, даже "слишком долгое" ожидание можно преодолеть с помощью правильного дизайна пользовательского интерфейса и взаимодействия с клиентом.
Взгляните на эту ссылку:
http://www.simple-talk.com/dotnet/.net- tools / the-cost-of-low-website-performance /
, а затем просто определите уровень разочарования, которого могут достичь ваши пользователи.
Я бы сказал, что за пару секунд до этого вам следует вызвать (PHP)ob_flush() и хотя бы отправить ЧТО-ТО клиенту. Иначе эффект лифта возьмет верх, и пользователь будет обновлять страницу многократно. Что касается общей загрузки страницы, это не имеет значения, пока вы держите пользователя в курсе событий. Прогресс-бар поможет в этом.
Мое эмпирическое правило:
Не допускайте, чтобы обработка данных на стороне сервера занимала меньше секунды в среднем случае и определенно меньше 30 секунд в худшем случае.
Из моего опыта, вы должны дать пользователю хотя бы какое-то уведомление, если что-то займет больше нескольких секунд. Возможно, использовать AJAX с какой-нибудь причудливой анимацией и уведомлением типа "Это займет некоторое время".
Если вы не можете использовать AJAX и ваш PHP-скрипт загружается, например, более 10 секунд, попробуйте подумать о том, как его оптимизировать.
Якоб Нильсен провел некоторые исследования по этому поводу.
- 0,1 секунды - это примерно предел, позволяющий пользователю почувствовать, что система реагирует мгновенно, а это означает, что никакой специальной обратной связи не требуется, кроме как для отображения результата.
- 1.0 секунд - это предел, на котором поток мыслей пользователя не прерывается, даже если пользователь заметит задержку. Обычно никакой специальной обратной связи не требуется при задержках более 0,1, но менее 1,0 секунды, но пользователь теряет ощущение работы непосредственно с данными.
- 10 секунд - это предел. для удержания внимания пользователя на диалоге. В случае более длительных задержек пользователи захотят выполнять другие задачи, ожидая завершения работы компьютера, поэтому им следует дать обратную связь, указывающую, когда компьютер ожидает завершения. Обратная связь во время задержки особенно важна, если время отклика может сильно варьироваться, поскольку в этом случае пользователи не будут знать, чего ожидать.
Чтобы служить источником вдохновения, вы можете посмотреть, как сообщество NetBeans интерпретируют эти значения :
- 0,1 секунды - действия по навигации и редактированию (например, расширение папки, вставка в редактор, навигация в редакторе), и рисование всех строк меню должно завершаться в пределах этого лимита {{1 }}
- 1,0 секунда - все открытия окон и диалогов должны заканчиваться в пределах этого лимита
- 10 секунд - все действия, которые завершаются позже, чем через 1 секунду и обычно занимают менее 10 секунд должны показывать какую-то индикацию занятости (например, курсор в виде песочных часов или текст «подождите ...»); все действия, которые занимают больше времени, чем это ограничение, необходимы для отображения индикатора выполнения с использованием Progress API
Все, что занимает более нескольких секунд времени процесса, должно обрабатываться по-другому, вот некоторые примеры
- Кэшируйте его вывод на стороне сервера
- Запустите задание Cron, которое выполняет обработку
- Породите искусственный процесс с PHP, используя
system()
Проверенная и верная стратегия - всегда управлять ожиданиями. Не заставляйте пользователя угадывать вас или ваше приложение. Если, по вашим оценкам, среднее время обработки определенной страницы выйдет за, скажем, 6-секундный порог, скажем, до того, как пользователь нажмет кнопку. Это очень похоже на ожидание, пока веб-сайт пришлет вам электронное письмо с подтверждением, не зная, когда оно придет, потому что никогда не упоминалось, что это может занять несколько часов из-за трафика, не зависящего от сайта.
Ну предел по умолчанию для выполнения сценария PHP составляет 30 секунд. Если вы просто спрашиваете с точки зрения пользователей, то практическое правило будет: чем быстрее, тем лучше ...