Покадровая scroll-анимация: как связаны motion-дизайн, FFmpeg и GSAP

Покадровая анимация при скролле выглядит просто: человек прокручивает страницу, а объект плавно вращается, собирается из деталей или меняет состояние. За плавным движением стоят три отдельные части: motion-дизайн, подготовка ассетов и front-end. Их нужно свести в один сценарий и проверить на реальной странице.

Я отношусь к такой анимации как к дополнительному слою проекта. Она не должна заменять понятную структуру, сильный текст и нормальную навигацию. Страница должна объяснять продукт и без эффекта. Когда смысл уже собран, покадровая сцена хорошо показывает устройство продукта, процесс или изменение состояния.

Из чего складывается покадровая анимация

Сначала дизайнер или motion-дизайнер создаёт сцену: 3D-объект, композицию, переходы, свет и движение камеры. Затем результат рендерится в последовательность изображений. Это принципиальный момент: браузеру нужны отдельные кадры, между которыми можно перемещаться в обе стороны вместе со скроллом пользователя.

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

• motion-дизайн задаёт само движение и визуальный сценарий;
• FFmpeg помогает подготовить, переименовать, масштабировать и сжать последовательность;
• JavaScript загружает кадры и рисует их на canvas;
• GSAP и ScrollTrigger связывают прогресс сцены с положением страницы;
• адаптивный сценарий определяет, что увидит пользователь на конкретном устройстве.

Зачем в цепочке нужен FFmpeg

Рендер из motion-программы редко готов к прямой публикации. Кадры могут весить слишком много, иметь избыточное разрешение или содержать технические поля. Вручную обрабатывать сотни файлов бессмысленно. FFmpeg позволяет собрать воспроизводимый процесс: привести серию к нужному размеру, изменить частоту кадров, подготовить превью, проверить последовательность и получить альтернативные версии для разных экранов.

Я не пытаюсь сохранить максимальное качество любой ценой. В вебе важен баланс. Пользователь не должен ждать десятки мегабайт ради эффекта, до которого он ещё не доскроллил. Поэтому исходная сцена обычно превращается в несколько наборов: основной для больших экранов, облегчённый для планшетов и статичный или короткий вариант для слабых мобильных устройств.

Как GSAP связывает кадры со скроллом

На странице создаётся объект состояния, например номер текущего кадра. ScrollTrigger меняет это значение в зависимости от положения пользователя, а функция отрисовки выводит нужное изображение на canvas. Благодаря этому сцена может двигаться вперёд и назад, останавливаться в смысловых точках и синхронизироваться с заголовками или подписями.

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

Загрузка без зависания страницы

Главная техническая задача — не скачать все кадры раньше критического контента. Я разделяю загрузку на этапы: сначала страница получает минимально необходимое изображение, затем браузер подготавливает ближайшие кадры, а остальная последовательность подгружается по мере приближения к секции. Порядок зависит от проекта: иногда важнее заранее загрузить каждое изображение, иногда допустимо показывать только уже готовые кадры.

Canvas также нужно правильно масштабировать под плотность пикселей и размеры контейнера. Просто растянуть картинку CSS недостаточно: на Retina-дисплее она может стать размытой, а на узком экране важная часть композиции уйдёт за границу. Поэтому я отдельно задаю правила вписывания, позицию фокуса и максимальное разрешение.

Почему мобильному устройству нужен другой сценарий

Сенсорная прокрутка, небольшой экран и ограниченная память меняют поведение сцены. То, что выглядит плавно на мощном компьютере, на телефоне может тормозить, перегревать устройство или мешать быстро добраться до информации. Поэтому адаптив — это не уменьшенная копия desktop-эффекта.

На мобильных я могу сократить число кадров, уменьшить дистанцию закрепления, отказаться от pin-секции или заменить последовательность на изображение и короткое ненавязчивое движение. Для пользователей с настройкой reduced motion нужен спокойный вариант без обязательной управляемой анимации. Облегчённый fallback входит в нормальную разработку мобильной версии.

Когда эффект действительно оправдан

Покадровая сцена полезна, когда она объясняет изменение: раскрывает конструкцию, показывает этапы производства, демонстрирует принцип работы или ведёт человека через сложный объект. Делать её только ради того, чтобы сайт «был как у Apple», не всегда разумно. У Apple за подобной подачей стоят подходящие материалы, команда и конкретная продуктовая задача.

Я подключаю motion как отдельную часть оценки. Для неё нужны подготовленные материалы и согласованный сценарий, а иногда участие motion-дизайнера. Срок и стоимость определяют количество сцен и кадров, адаптивные версии и требования к производительности. До начала работы я объясняю, где эффект усилит проект, а где лучше оставить обычный быстрый блок.