В Chrome 146, вышедшем в стабильный релиз в марте 2026 (бета — 11 февраля), появилась встроенная поддержка scroll-triggered animations: управление воспроизведением, паузой и сбросом анимаций в зависимости от позиции прокрутки, целиком через CSS, с возможностью выноса обработки в отдельный поток браузера. Это делает scroll-driven animations не просто экспериментальной возможностью, а частью стабильной платформы.

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

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

Почему эта тема снова актуальна

Эффекты на scroll — это не редкий экзотический кейс. Они встречаются в лендингах, медиа-страницах, продуктовых интерфейсах и даже в простой микронавигации.

Проблема в том, что исторически у команды часто было всего два режима:

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

С появлением в Chrome 146 нативных scroll-triggered animations — возможности декларативно привязывать воспроизведение, паузу и сброс анимации к позиции прокрутки через CSS — третий вариант стал заметно реальнее. Браузер берет на себя контроль scroll-положения и может выносить обработку в отдельный поток, освобождая основной от лишней работы.

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

Что не так с анимациями на scroll через JavaScript

Сами по себе обработчики прокрутки не зло. Проблема в том, что они очень легко затягивают в компонент лишнюю логику.

Чаще всего это выглядит так:

  • слушаем scroll;
  • вычисляем видимость или прогресс;
  • кладем это в состояние;
  • дергаем стили или классы;
  • думаем, как не устроить лишние обновления.

Чем сложнее эффект, тем выше шанс, что решение начнет зависеть от throttling, debounce, requestAnimationFrame, вычисления layout и других вещей, которые мало кто хотел бы тащить в обычный UI-компонент.

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

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

React здесь часто становится лишним посредником

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

Если реальная задача звучит как “плавно показать блок, когда он входит в определенную фазу прокрутки”, то тянуть для этого в React обработчик событий и внутреннее состояние — довольно дорогой способ описания проблемы.

Где CSS-подход действительно выигрывает

CSS и решение на уровне платформы выигрывают там, где задача в первую очередь визуальная, а не продуктовая.

Например:

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

В таких сценариях главное преимущество не в том, что “CSS моднее”. Главное преимущество в том, что браузер ближе к самому механизму отрисовки и может делать эту работу без лишнего посредника в виде состояния React и пользовательского кода.

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

Это полезно и для производительности, и для границ ответственности

Производительность — очевидный бонус. Но для больших интерфейсов не менее важен другой эффект: код разделяется чище.

  • визуальная реакция остается в визуальном слое;
  • бизнес-логика остается в бизнес-логике;
  • компонент меньше знает о механике анимации.

Такой раздел полезен и при профилировании. Когда интерфейс ведет себя тяжело, проще увидеть, это действительно проблема рендера и данных, или просто анимационный слой взял на себя слишком много работы. Здесь полезно держать под рукой и Профилирование производительности React-приложения.

Где JavaScript все еще нужен

Было бы ошибкой сделать из этой темы новый догмат. Не все scroll-сценарии стоит уносить в CSS.

JavaScript по-прежнему нужен, если:

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

Еще один важный момент: иногда эффект сам по себе не стоит своей сложности. Если команда тратит больше времени на анимацию, чем на сам UX (user experience, то есть пользовательский опыт), это уже плохой сигнал независимо от технологии.

Как принимать решение в реальном проекте

Самая полезная рамка здесь простая.

1. Визуальная или продуктовая логика

Если это в первую очередь визуальное поведение, CSS-подход стоит проверить первым.

2. Нужен ли здесь state в React

Если состояние существует только ради самой анимации, это повод спросить, нельзя ли убрать посредника.

3. Цена поддержки

Важно не только “можно ли сделать”, но и “кто будет это поддерживать через полгода”. Чем меньше магии и самодельной синхронизации, тем лучше.

4. Слабый UX не стоит усложнять дорогой реализацией

Иногда правильный ответ — не “переписать на CSS”, а “сделать эффект проще”. Это часто лучший компромисс для команды и продукта.

Итог

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

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

Наиболее конкретный следующий шаг — один эффект на прокрутке в текущем проекте и честная проверка: достаточно ли здесь CSS, или логика уже связана с состоянием компонента. Очень часто именно в таком маленьком эксперименте и становится виден настоящий выигрыш.