Тайминги производительности: как долго - долго?

Понятие "до секунды" часто считается оптимальным для загрузки. Но что это означает? Правило секунды должно рассматриваться как правило максимального времени, за которое пользователь поймёт, что запрос был отправлен и будет загружен. Например, когда браузер принимает заголовок страницы или фоновый цвет и показывает её пользователю.

Как правило, первый ресурс, который получает клиент - это HTML документ, который затем делает запрос на загрузку остальных ресурсов. Как было подмечено в статье о критическом пути рендеринга - как только браузер получает данные, он сразу начинает их обработку, вместо того, чтобы дожидаться загрузки всех ресурсов.

Да, одна секунда на загрузку — это хорошая цель. Но лишь немногие приложения достигают этой скорости. Всё зависит от ожиданий. Например, от приложения «Hello World», работающего в корпоративной (локальной) сети, будет ожидаться загрузка за миллисекунды. Пользователь из северной Сибири, пользующийся EDGE-мобильной сетью и устройством 5-летней давности, вероятно, посчитает даже 20-секундную загрузку быстрой. Однако, в среднем, если вы позволяете приложению не отвечать на запрос 3 или 4 секунды, вы, вероятно, потеряете пользователя. И, что ещё хуже, этот пользователь вряд ли вернётся к вам в ближайшее время.

В деле оптимизации производительности рекомендуется обозначить амбициозные задачи по первичной загрузке контента. Например, 5 секунд для 3G сетей и 1.5 секунды для офисного Т1 канала. Для навигации внутри приложения цели должны быть ещё строже. К счастью, для оптимизации можно использовать Service Workers и кеширование.

Браузеры однопоточны (хотя существуют фоновые потоки, доступные с помощью web worker-ов). Это означает, что взаимодействие с пользователем, отрисовка и выполнение скриптов выполняются в одном потоке. Если поток занят вычислением сложной JavaScript логики, этот поток не сможет обрабатывать пользовательский ввод (например, нажатие кнопок). По этой причине важно разбивать выполнение скриптов на небольшие части, каждый из которых выполняется не больше 50мс. Это позволит потоку своевременно реагировать на пользовательский ввод.

Для того, чтобы прокрутка и другие анимации выглядели плавно, контент страницы должен обновляться с частотой 60 кадров в секунду (60 fps), то есть один кадр раз в 16.7мс. В эти 16.7мс. должны входить выполнение скриптов, компоновка и отрисовка. Делайте приложение таким, чтобы приложение могло использовать 6мс на отрисовку контента, а в остальные 10мс могло заниматься оставшимися вычислениями. Любая другая частота кадров, особенно если она отрывистая и непостоянная, создаёт впечатление зависающего приложения.

Когда пользователь взаимодействует с контентом - очень важно давать обратную связь пользователю. Время реакции не должно составлять больше 100мс, а лучше - 50мс. 50мс ощущаются пользователем как "мгновенно". Реакция на пользовательское взаимодействие должно чаще чувствоваться мгновенным (например, наведение курсора на кнопку). Но это не означает, что реакция должна быть одномоментной. В то время, как задержка в 100мс может вызвать чувство бессвязности действий пользователя и реакции системы, плавный переход между состояниями за время в 100-200мс позволит пользователю заметить, что взаимодействие началось и обрабатывается. Если ответ на действие пользователя занимает больше 100мс, предоставьте некоторую реакцию, которая скажет пользователю, что взаимодействие уже случилось и обрабатывается.