Время отклика интерфейса

Скорость работы интерфейса значительно влияет на пользовательский опыт.

Быстрый интерфейс дает ощущение контроля и управляемости. Медленный — раздражает, провоцирует ошибки и повышает вероятность того, что пользователи будут звонить в техподдержку, а не пытаться разобраться самостоятельно.

Ответственность дизайнера — следить за скоростью отклика в его продукте:

• Выбирайте решения, которые будут работать быстро.
• Если мгновенный отклик реализовать не получается — используйте приёмы, которые сократят субъективное восприятие времени.
• Доносите важность скорости до команды.
• Следите за скоростью. Если видите, что продукт работает медленно — бейте тревогу.

Для разных действий в интерфейсе понятия «быстро» и «медленно» отличаются.

Отклик в 100 миллисекунд воспринимается как мгновенный — так элементы интерфейса должны реагировать на наведение, движение мыши или клик.

Задержка в 1 секунду заметна, но не выбивает пользователя из контекста. Нормально, если страница или список загружаются за секунду, но если секунда проходит между кликом и открытием меню, это медленно.

Процессы, которые длятся больше секунды, нужно оптимизировать.

Ощущения «быстро» и «медленно» зависят ещё и от контекста. Если информация или действия от продукта нужны срочно, секунды будут идти дольше, чем обычно. Дизайнер не может влиять на контекст использования, но может его учитывать как обстоятельство пользовательских сценариев.

Скорость работы десктопного приложения зависит только от мощности компьютера. На отзывчивость веб-приложений также влияют быстродействие сервера и качество интернет-соединения.

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

Выполнение команды пользователя может занимать какое-то время, но обратная связь интерфейса должна быть мгновенной. Так пользователь сразу поймет, что приложение отреагировало на его действие.

Например, выделяйте пункт меню сразу после нажатия на него, а содержание раздела грузите параллельно:

Показывайте раскрывающийся список мгновенно, а данные — после того, как загрузятся:

Если некритичное действие требует изменений на сервере, используйте «оптимистичные» интерфейсы — показывайте, что всё сработало, еще до того, как пришел ответ от сервера. Например, пользователь лайкает пост, приложение мгновенно увеличивает количество лайков на 1 и отправляет запрос на сервер. Иногда что-то может пойти не так и голос не будет учтен, зато в большинстве случаев пользователь получит мгновенную обратную связь.

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

Например, предзагружайте следующее изображение в галерее, чтобы не пришлось показывать лоадер, когда пользователь захочет к нему перейти:

В «ленивой подгрузке» всегда держите данные на 1–2 экрана вперед.

Если на странице есть что-то тяжелое — обязательно выделяйте эти данные в отдельный запрос, чтобы они не задерживали отображение остальной страницы и грузились параллельно.

Например, страница поисковой системы должна быть сверстана так, чтобы строка поиска появилась самой первой:

На странице бронирования Стаффа занятость переговорок формируется очень медленно, но ее загрузка отделена от остальных элементов, и поэтому сама страница загружается моментально:

Уводите в фон долгие операции. Например, загрузка файла на сервер не должна блокировать действия пользователя на странице.

Неправильно

Правильно

Используйте SVG для всех иконок и небольших иллюстраций. Не используйте шрифт Kontur Iconic в html-верстке, для этого создана специальная SVG-библиотека.

Иллюстрации с большим количеством деталей сохраняйте в SVG и PNG, оптимизируйте, после этого выбирайте файл с меньшим весом.

JPG используйте только для фотографий.

Сжимайте картинки с помощью специальных сервисов — это уменьшает их размер на 50–70 %. Например, используйте сервис Squoosh.

Если картинка весит больше 100 KB, подумайте еще раз, так ли она необходима. Возможно, ее стоит изменить, чтобы уменьшить размер.

Остальные файлы должны сжиматься автоматически: для релиза используйте отдельную конфигурацию вебпака с включенной минификацией.

Кешируйте данные, и загружайте их повторно, только если есть изменения. Это позволяет мгновенно переключаться между загруженными страницами, в том числе делать переход по кнопке «Назад» с сохранением позиции скролла.

Если пользователь взаимодействовал с каким-то элементом, отрендерите только его. Например, не перерисовывайте весь список при удалении одного элемента из справочника.

Формируйте ответы на «тяжелые» запросы на сервере заранее. Например, Контур.Фокус по расписанию готовит списки связанных организаций. Это позволяет показывать их число рядом с ссылкой и загружать содержимое списка мгновенно.

Если замаскировать паузу не получилось, нужно показать индикатор процесса, чтобы пользователь понимал — система получила его команду и занята ее выполнением.

У браузеров есть свои индикаторы, но они появляются только когда загружается новая страница. Если отправлен асинхронный запрос внутри страницы — такой процесс браузеры не показывают, поэтому об обратной связи должно позаботиться само приложение.

Индикаторы загрузки в Safari и Chrome

Мы отличаем две ситуации:

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

Для таких ситуаций мы применяем глобальный лоадер, который располагается вверху экрана. В паре с глобальным лоадером используется минискелетон или полноценный скелетон в том месте страницы, где появится контент:

Исключением являются отдельные тяжелые запросы, выполнение которых, занимает заведомо больше времени. Пример – список переговорок в Стаффе. У такого блока может быть отдельный лоадер, который появляется после рендеринга контента.

См. гайд «Глобальный лоадер».

Если пользователь сам запускает продолжительную задачу, также нужно показать лоадер, но есть несколько отличий:

• на странице может быть одновременно несколько лоадеров, по количеству запущенных задач;
• лоадер размещается максимально близко к тому месту, где вызывалась команда;
• можно и нужно ориентировать по времени завершения задачи или показывать прогресс выполнения;
• уместно использовать красивый анимированный лоадер.

В большинстве таких случаев достаточно спиннера, но иногда стоит потратить время и сделать полноценный прогресс-бар:

См. гайды «Спиннер» и «Прогресс-бар».