Кнопка, которая едва заметно меняется под пальцем, шторка, выезжающая оттуда, куда нажали, плавное появление новых строк в списке — такую анимацию на сайте почти не замечают, но без неё интерфейс кажется неотзывчивым. А заставка на пять секунд, блоки, которые выплывают при каждом движении колеса, и фон, живущий своей жизнью, замечают все. И часто закрывают вкладку.
Разница не во вкусе дизайнера, а в том, работает ли движение на задачу человека. Разберём, зачем нужна анимация в веб-дизайне, где она помогает, где мешает, как не испортить скорость и доступность и как описать motion-дизайн сайта так, чтобы разработчики сделали ровно то, что задумано.
Зачем нужна анимация в интерфейсе
В интерфейсе у движения четыре полезные работы. Если анимация не делает ни одну из них, её стоит убрать или упростить.
- Обратная связь. Человек нажал — что-то произошло. Кнопка реагирует на нажатие, поле подсвечивается при ошибке, иконка «в корзину» отмечает, что товар добавлен. Без отклика пользователь не уверен, сработало ли действие, и нажимает ещё раз.
- Связь состояний. Меню выезжает из кнопки, которая его открыла, карточка раскрывается в подробности, удалённая строка схлопывается, а не исчезает мгновенно. Движение объясняет, откуда взялся новый элемент и куда делся старый.
- Внимание. Появилось уведомление, изменилась сумма заказа, в форме ошибка ниже видимой области. Короткое движение показывает, куда смотреть. Но работает это, только пока на странице двигается что-то одно.
- Характер бренда. Манера движения — резкая, мягкая, упругая — часть визуального языка, как шрифт и цвет. Это законная задача, но она идёт последней и не должна мешать первым трём.
Хорошая проверка: выключите анимацию и пройдите основной сценарий. Если стало непонятно, что происходит, анимация была полезной. Если ничего не изменилось, кроме ощущения «стало скромнее», она была украшением, и её стоимость стоит взвесить.
Микроанимации и «вау-эффекты»: в чём разница
Микроанимации — маленькие движения в ответ на действия: наведение, нажатие, переключение, загрузка, ошибка. Они короткие, повторяются сотни раз и почти незаметны. «Вау-эффекты» — крупные сцены: анимированный первый экран, 3D-объекты, сложные переходы между страницами, сторителлинг на прокрутке. Они рассчитаны на то, чтобы их увидели и запомнили.
| Микроанимации | «Вау-эффекты» | |
|---|---|---|
| Задача | Отклик и понятность | Впечатление и образ бренда |
| Где | Кнопки, формы, меню, списки, корзина | Первый экран, промо, презентация продукта |
| Как часто видят | При каждом действии | Один-два раза за визит |
| Длительность | Доли секунды | Секунды |
| Нагрузка на страницу | Почти никакой, хватает CSS | Часто библиотеки, видео, WebGL |
| Риск | Невысокий, если они короткие | Медленная загрузка, отвлечение, проблемы на слабых телефонах |
На коммерческом сайте баланс обычно такой: аккуратные микроанимации везде, где есть действие, и один-два эффектных момента там, где человек ещё знакомится с брендом. В каталоге, корзине, форме заявки и личном кабинете «вау» мешает: человек пришёл сделать дело, а не смотреть.
Чем чаще человек видит анимацию, тем короче и тише она должна быть.
Анимация при скролле и параллакс: где риски
Анимация при скролле — когда блоки появляются, выезжают или меняются по мере прокрутки. В умеренных дозах она помогает: подчёркивает начало нового раздела, оживляет длинную страницу. Проблемы начинаются, когда так появляется каждый абзац.
- Контент не готов, когда его ищут. Человек быстро прокрутил к ценам, а они ещё выплывают. Или при переходе по якорю блок пустой, пока не сработает анимация.
- Захват прокрутки. Страница перехватывает колесо или свайп и сама решает, куда ехать. Это ломает привычное управление, особенно на тачпадах и телефонах.
- Укачивание. Параллакс — слои, которые двигаются с разной скоростью, — и крупные движения на весь экран у части людей вызывают дискомфорт и головокружение.
- Нагрузка. Обработчики прокрутки, которые на каждом кадре что-то пересчитывают, делают скролл рваным на слабых устройствах.
- Поисковые роботы и скриншоты. Если контент скрыт до срабатывания скрипта, при сбое скрипта его не увидит никто.
Безопасный вариант — контент виден по умолчанию, анимация только украшает. Появление срабатывает один раз, короткое, с небольшим смещением, а сам текст есть в разметке и доступен без JavaScript. Для отслеживания появления элементов в браузере есть IntersectionObserver, он не нагружает страницу так, как подписка на каждое событие прокрутки.
Длительность и плавность
Для интерфейсных переходов общепринятые ориентиры — порядка сотен миллисекунд. Отклик на наведение и нажатие делают почти мгновенным, десятки миллисекунд. Появление подсказки, переключение вкладки, раскрытие элемента — примерно 150–300 мс. Крупные перемещения, например шторка на весь экран, могут длиться чуть дольше, но если человек успевает заскучать в ожидании, переход слишком длинный.
Несколько правил, которые работают почти всегда:
- Чем больше путь, тем дольше движение, но без перебора: мелкие элементы двигаются быстрее крупных.
- Кривая важнее длительности. Линейное движение выглядит механически. Появление обычно замедляется к концу (ease-out), исчезновение ускоряется (ease-in).
- Исчезновение короче появления. Человек уже решил закрыть элемент, ждать незачем.
- Анимация не блокирует действие. Если можно нажать кнопку, пока идёт переход, нажатие должно сработать.
- Одна система на весь сайт. Набор длительностей и кривых задают токенами, как цвета и отступы, а не подбирают для каждой кнопки заново.
Анимация и скорость сайта
Браузер рисует страницу в несколько шагов: считает расположение элементов (layout), раскрашивает их (paint) и собирает слои (composite). Если анимировать ширину, высоту, отступы или положение через top и left, браузер пересчитывает раскладку на каждом кадре. На мощном ноутбуке этого не видно, на бюджетном телефоне — рывки.
Поэтому правило простое: анимировать transform и opacity, а не layout. Сдвиг, масштаб, поворот и прозрачность браузер обычно обрабатывает на этапе компоновки, без пересчёта страницы. Раскрытие блока по высоте тоже можно сделать через transform или аккуратно ограничить одним элементом.
Видео, Lottie и тяжёлые библиотеки
Фоновое видео на первом экране — частая причина медленной загрузки. Если оно действительно нужно, его сжимают, ставят постер-картинку, не грузят на мобильных или грузят после основного контента. Анимации в Lottie и подобных форматах удобны дизайнерам, но и файл анимации, и плеер весят, а сложные сцены нагружают процессор. Библиотеки анимаций подключают тогда, когда без них не обойтись, а не ради пары появлений, которые решаются CSS.
Core Web Vitals: CLS и INP
Анимация влияет на метрики, по которым Google оценивает пользовательский опыт, и это можно проверить. CLS (Cumulative Layout Shift) считает неожиданные сдвиги контента. Если блок при появлении меняет размер и толкает соседей, сдвиг попадает в метрику; движение через transform сдвигом раскладки не считается. INP (Interaction to Next Paint) показывает, как быстро страница реагирует на действие. Тяжёлые скрипты анимации, которые занимают главный поток, задерживают отклик на клик.
Доступность: prefers-reduced-motion, мигание, автопроигрывание
В iOS, Android, Windows и macOS есть настройка «уменьшить движение». Её включают люди, которых укачивает от анимации, у которых болит голова или которым движение мешает сосредоточиться. Браузер передаёт эту настройку сайту через медиазапрос prefers-reduced-motion, и сайт должен её учитывать: убрать параллакс, появления при скролле и крупные переходы, оставить мгновенную смену состояний или мягкое изменение прозрачности.
У нас на сайте так и сделано: заголовки статей блога появляются по словам, а при включённой настройке «уменьшить движение» эффект отключается и заголовок сразу виден целиком. Это несколько строк CSS, а не отдельная версия сайта.
- Мигание. Вспышки чаще трёх раз в секунду WCAG запрещает: у людей со светочувствительной эпилепсией они могут вызвать приступ. Мерцающие баннеры и резко меняющийся фон — под запретом.
- Автопроигрывание. Если что-то движется дольше пяти секунд само по себе — карусель, бегущая строка, видео, — по WCAG у человека должна быть возможность остановить или скрыть это.
- Фокус и экранные дикторы. Анимированные меню и модальные окна должны правильно переводить фокус клавиатуры, а скрытый анимацией контент — не оставаться доступным для дикторов, пока его не видно.
Анимация на мобильных устройствах
Телефон — самое требовательное место для анимации. Процессоры слабее, чем у ноутбуков, батарея садится, связь нестабильна, а экран маленький, и крупное движение занимает его целиком. То, что на макете в Figma выглядит плавно, на бюджетном Android может дёргаться.
На мобильных нет наведения, поэтому эффекты на hover там бесполезны: отклик должен быть на нажатие. Жесты — свайп, перетаскивание шторки — должны двигать элемент за пальцем, без задержки, а анимация после отпускания продолжает движение, а не начинает новое. Параллакс и тяжёлые сцены на телефонах часто упрощают или отключают совсем.
Как описать анимацию для разработки
Фраза «блок красиво выезжает» каждый поймёт по-своему. Чтобы результат совпал с замыслом, анимацию передают в разработку так же конкретно, как отступы и цвета.
- Прототип или видео. Покажите движение: кликабельный прототип в Figma, ролик или запись экрана. Словами плавность не передать.
- Триггер. Что запускает анимацию: наведение, нажатие, появление в зоне видимости, загрузка данных, ошибка.
- Свойства и значения. Что меняется и от чего к чему: прозрачность с 0 до 1, сдвиг на 16 px, масштаб с 0,96 до 1.
- Длительность, задержка и кривая. Конкретные значения в миллисекундах и название кривой или её параметры. Лучше — ссылкой на токен из дизайн-системы.
- Поведение при reduced-motion. Что остаётся, когда пользователь просит уменьшить движение: ничего, только прозрачность или мгновенная смена.
- Приёмка на устройстве. Проверка на реальном среднем телефоне, а не только на рабочем ноутбуке.
Мы закладываем анимации в дизайн-систему сразу, вместе с компонентами, и проверяем их в сборке, а не только в макетах. Примеры сайтов, которые мы проектировали и разрабатывали, — на странице с нашими работами.
Частые ошибки и чек-лист
Другие ошибки, которые мы встречаем чаще всего:
- анимации по ширине, высоте и отступам, которые дёргаются и сдвигают соседний контент;
- контент, скрытый до срабатывания скрипта при скролле;
- перехват прокрутки и «прилипающие» экраны на длинной странице;
- разные длительности и кривые в каждом блоке без общей системы;
- игнорирование настройки «уменьшить движение»;
- карусели, которые листаются сами и не останавливаются.
Перед запуском пройдите короткий список:
- у каждой анимации есть задача: отклик, связь состояний, внимание или характер бренда;
- микроанимации короткие, а крупные эффекты есть только в одном-двух местах;
- контент виден и без анимации, и без JavaScript;
- анимируются transform и opacity, нет рывков на слабом телефоне;
- анимации не ухудшают CLS и INP в PageSpeed Insights;
- при prefers-reduced-motion движение убрано или заменено на мягкую смену;
- ничего не мигает чаще трёх раз в секунду, автопроигрывание можно остановить;
- длительности и кривые заданы токенами в дизайн-системе.
Частые вопросы
Влияет ли анимация на SEO?
Напрямую нет, но косвенно да. Тяжёлые анимации замедляют загрузку и ухудшают Core Web Vitals, а контент, скрытый до срабатывания скрипта, может не попасть в индекс. Лёгкие CSS-анимации при видимом по умолчанию контенте на SEO не влияют.
Что такое prefers-reduced-motion?
Это медиазапрос CSS, который сообщает сайту, что пользователь включил в системе настройку «уменьшить движение». Сайт по нему отключает или упрощает анимации: убирает параллакс, появления при прокрутке и крупные переходы.
Сколько должна длиться анимация на сайте?
Для интерфейсных переходов общепринятый ориентир — порядка сотен миллисекунд: отклик на нажатие почти мгновенный, раскрытие и появление элементов примерно 150–300 мс. Если анимацию приходится ждать, она слишком длинная.
Нужна ли для анимации отдельная библиотека?
Для большинства микроанимаций и появлений хватает CSS. Библиотеки оправданы для сложных сцен, связанных последовательностей и анимации по прокрутке со множеством шагов, но каждая добавляет вес странице.
