Любой сайт иногда заставляет ждать: грузится каталог, отправляется форма, пересчитывается стоимость доставки, формируется документ. Полностью убрать ожидание нельзя — данные идут по сети, запросы обрабатывает база, файлы весят столько, сколько весят. Зато можно управлять тем, что человек видит в эти секунды. Одна и та же задержка переносится по-разному: пустой белый прямоугольник читается как поломка, а размеченная заглушка — как обычная загрузка. Ниже разбираем приёмы, которыми мы пользуемся в проектах, и порядок, в котором их стоит применять.
Почему пустой экран воспринимается как поломка
Человек оценивает не секунды по таймеру, а понятность происходящего. Если после нажатия ничего не изменилось, первая гипотеза — нажатие не сработало. Дальше следует повторный клик, потом третий, потом уход со страницы. Мы регулярно видим это в записях сессий: три-четыре нажатия подряд по кнопке отправки за полторы секунды, а в почте — три одинаковых заявки.
Обратная ситуация тоже встречается. Интерфейс отвечает мгновенно, но ответ выглядит одинаково при успехе и при ошибке: индикатор покрутился и пропал, а результата нет. Формально ожидание оформлено, фактически человек остался без обратной связи. Поэтому анимацию ожидания мы всегда проектируем вместе с двумя другими состояниями — успехом и ошибкой, а не отдельно от них.
Три способа показать ожидание
Выбор зависит от того, сколько длится операция и знаем ли мы её объём заранее.
| Способ | Когда уместен | Что важно учесть |
|---|---|---|
| Крутящийся индикатор | Короткие операции до 2-3 секунд: отправка формы, подгрузка выпадающего списка | Появляется не мгновенно, а через 200-300 мс, иначе мигает на быстрых ответах |
| Скелетон, то есть серые заглушки блоков | Загрузка списков, карточек товаров, ленты материалов, таблиц | Повторяет реальную раскладку: количество строк, пропорции картинок, высоту карточки |
| Полоса прогресса | Длительные операции с известным объёмом: загрузка файла, импорт данных | Показывает реальный прогресс, а не имитацию движения |
| Текстовый статус | Операции дольше 10 секунд: расчёт, генерация документа, проверка по внешнему сервису | Называет текущий шаг словами, а не процентами |
Комбинировать способы можно и нужно. Например, при отправке большой формы кнопка блокируется и получает индикатор, а под ней появляется строка статуса — так человек видит и что нажатие принято, и что процесс идёт.
Чем скелетон лучше вращающегося индикатора
Скелетон показывает, что именно появится: два блока текста, картинка слева, кнопка внизу. Человек начинает считывать структуру страницы до того, как пришли данные, и субъективное время ожидания сокращается. Кроме того, место под содержимое уже занято — когда данные приходят, вёрстка не прыгает, кнопка не уезжает из-под пальца.
Скачок вёрстки — отдельная проблема, которая портит впечатление даже на быстрых сайтах. Классический случай: карточки товаров отрисовались, человек тянется к кнопке, в этот момент догрузился баннер сверху, содержимое сместилось вниз, палец попал в другую ссылку. Скелетон с правильными размерами закрывает этот сценарий, потому что резервирует высоту блока заранее.
Как мы собираем скелетон
- Берём реальную карточку или строку списка и снимаем с неё геометрию: отступы, высоту строк текста, пропорции изображения.
- Заменяем содержимое нейтральными прямоугольниками того же размера, скругления оставляем те же, что у настоящих элементов.
- Показываем столько заглушек, сколько элементов обычно приходит в первом экране, — не одну и не двадцать.
- Добавляем спокойное движение подсветки. Резкое мигание раздражает и мешает читать соседний текст.
- Проверяем на тёмной теме и на мобильном: серый на сером иногда просто не виден.
Отдельно проверяем поведение при повторных заходах. Если данные уже есть в кеше и приходят за 50 мс, скелетон показывать не нужно вовсе — вспышка серых блоков выглядит хуже, чем мгновенная отрисовка.
Задержка перед появлением индикатора
Небольшая пауза перед показом индикатора — приём, который экономит нервы. Если ответ приходит за 150 мс, показывать ничего не надо: человек и так воспринимает это как мгновенную реакцию. Индикатор, который успел появиться и исчезнуть, читается как дёрганье интерфейса.
Обратное правило тоже полезно: если индикатор всё-таки показан, держим его минимум 400-500 мс. Иначе на быстром соединении получается серия вспышек. Оба порога мы задаём в коде один раз и применяем ко всем состояниям загрузки на проекте, чтобы поведение было одинаковым.
Ошибки, которые встречаются чаще всего
- Кнопка не блокируется при отправке. Человек нажимает трижды, заявка приходит трижды, менеджер звонит по одному обращению три раза.
- При ошибке индикатор просто исчезает. Ничего не произошло, объяснения нет, повторить попытку не предлагают.
- Полоса прогресса доходит до девяноста процентов и стоит. После такого опыта человек перестаёт верить любым индикаторам на сайте.
- Скелетон не совпадает с реальной раскладкой: заглушек три, а карточек приходит восемь, и страница подпрыгивает.
- Индикатор перекрывает весь экран при загрузке одного небольшого блока. Ожидание локальное, а блокируется вся страница.
- Анимация не отключается при системной настройке уменьшения движения. Для части посетителей это вопрос самочувствия, а не вкуса.
Долгие операции: текст вместо анимации
Если операция занимает больше десяти секунд — генерация счёта, обработка большого файла, обмен с внешним сервисом, — молчаливое вращение перестаёт работать. Человеку нужно понимать, что процесс не завис. Помогает простое перечисление шагов словами: проверяем данные, формируем документ, отправляем на почту. Текущий шаг подсвечен, пройденные отмечены.
- Называем шаги языком клиента, а не названиями внутренних сервисов.
- Даём возможность уйти со страницы и получить результат письмом, если операция действительно долгая.
- Сообщаем о завершении явно: строкой на странице, а не только исчезновением индикатора.
- При ошибке пишем, на каком шаге она произошла и что делать дальше.
Что проверяем перед сдачей
| Что проверяем | Как проверяем | Признак проблемы |
|---|---|---|
| Реакция на нажатие | Нажимаем кнопку отправки и смотрим на неё | Первые полсекунды на экране ничего не меняется |
| Защита от повторной отправки | Быстро нажимаем кнопку несколько раз подряд | Приходит несколько одинаковых заявок |
| Поведение на медленной сети | Включаем ограничение скорости в инструментах браузера | Скачки вёрстки, пустые области, вспышки индикатора |
| Состояние ошибки | Отключаем сеть и отправляем форму | Индикатор пропал, сообщения нет |
| Совпадение скелетона с содержимым | Сравниваем заглушку и загруженный блок | Высота отличается, страница подпрыгивает |
| Уменьшение движения | Включаем системную настройку и обновляем страницу | Анимация продолжает работать в полном объёме |
Сначала скорость, потом оформление
Хорошая анимация ожидания смягчает задержку, но не устраняет её. Если каталог отдаётся пять секунд, начинать нужно с запросов к базе, кеширования и веса изображений, а скелетоны добавлять уже поверх. Иначе получается аккуратное оформление медленного сайта: выглядит опрятно, работает по-прежнему долго.
Практический порядок такой. Сначала измеряем реальное время ответа на типовых сценариях и убираем то, что убирается технически. Затем расставляем состояния загрузки там, где задержка осталась. И только потом занимаемся тем, как именно эти состояния выглядят. При обратном порядке усилия уходят на украшение проблемы, которую можно было решить.
Если состояния загрузки на сайте живут каждое по своим правилам, а половина из них появилась случайно, мы приводим их к одной системе в рамках работ по теме проектирование веб-интерфейсов. Начинаем с разбора текущих сценариев ожидания и заканчиваем набором готовых состояний, которые разработчики переиспользуют на всех страницах.
