Какова самая короткая заметная задержка отклика приложений?
Вы не можете импортировать ваши файлы из каталога resources, единственной видимой частью вашего приложения для пользователей должна быть папка public, поэтому вы должны поместить свой файл в папку public. например,
public/js/modjule.js и импортируйте его следующим образом
<script src="{{ asset('js/module.js') }}"
, если ваш сайт работает по протоколу https, вы можете использовать secure_asset()
<script src="{{ secure_asset('js/module.js') }}"
6 ответов
То, что я не забываю изучать, было то, что любая задержка больше, чем 1/10-й из секунды (100 мс) для появления букв после ввода их начинает негативно влиять на производительность (Вы инстинктивно замедляетесь, менее уверенный, что Вы ввели правильно, например), но который ниже того уровня производительности задержки является чрезвычайно плоским.
, Учитывая, что описание, возможно, что задержка меньше чем 100 мс могла бы быть заметна как не являющийся мгновенным (например, обученные бейсбольные судьи могут, вероятно, разрешить порядок двух событий еще ближе вместе, чем 100 мс), но это достаточно быстро, чтобы считаться непосредственным ответом для обратной связи до эффектов на производительность. Задержка 100 мс и больше определенно заметна , даже если это все еще довольно быстро.
Это для визуальной обратной связи, что был получен определенный вход. Затем был бы стандарт скорости отклика в требуемой операции. Если Вы нажимаете на кнопку формы, получая визуальную обратную связь того щелчка (например, кнопка отображается, "подавленный" взгляд) в 100 мс все еще идеально, но после этого Вы ожидаете, что что-то еще произойдет. Если ничего не происходит в течение секунды или два, как другие сказали, Вы действительно задаетесь вопросом, взяло ли это щелчок или проигнорировало его, таким образом стандарт отображения своего рода "работы..." индикатор, когда операция могла бы взять больше, чем секунда прежде, чем показать ясный эффект (например, ожидать нового окна для появления).
Персистентность видения составляет приблизительно 100 мс, таким образом, это должна быть разумная визуальная задержка обратной связи. 110 мс не должны иметь никакого значения, поскольку это - приближенное значение. На практике Вы не заметите задержку ниже 200 мс.
Из моей памяти, исследования показали, что пользователи теряют терпение и повторяют операцию приблизительно после 2 с неактивности (в отсутствие обратной связи), например, нажатие на подтверждение или кнопку действий. Так планируют использование некоторой анимации, если действие занимает больше времени, чем 1 с.
Я работал над приложением, которое имело явную бизнес-цель того, чтобы быть ослепляюще быстрым, и у нас было макс. позволенное время сервера 150 мс для обработки полной веб-страницы.
Никакие убедительные доказательства, но для нашего собственного приложения, мы позволяем максимум одной секунды между пользовательским действием и обратной связью. Если это действительно занимает больше времени, "поле ожидания" нужно показать.
пользователь А должен видеть, что "что-то" происходит в течение секунды после порождения действия.
Для веб-приложений 200 мс рассматривают как unnoticable задержку, в то время как 500 мс приемлемы.
Порог в 100 мс был установлен более 30 лет назад. См .:
Кард, С. К., Робертсон, Г. Г., и Маккинли, Дж. Д. (1991). Визуализатор информации: информационное рабочее пространство. Proc. ACM CHI'91 Conf. (Новый Орлеан, Луизиана, 28 апреля - 2 мая), 181–188.
Миллер Р. Б. (1968). Время отклика в диалоговых транзакциях человек-компьютер. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.
Майерс Б.А. (1985). Важность индикаторов прогресса в процентах для взаимодействия компьютера с человеком. Proc. ACM CHI'85 Conf. (Сан-Франциско, Калифорния, 14-18 апреля), 11-17.