[Olena_Top]

Привіт, колеги! В епоху динамічних інтерфейсів (Awwwards-стайл) анімації є всюди. Але яке реальне навантаження вони створюють на пристрій користувача? Я проаналізував кілька десятків технічних матеріалів (з web.dev, MDN, блогів розробників браузерів), щоб раз і назавжди розібратися у вічній суперечці: CSS проти JS, та CPU проти GPU.

Ось реальні дані та цифри, які варто знати кожному верстальнику та фронтендеру.

1. Бюджет кадру: 16.6 мілісекунд
Щоб анімація виглядала плавною, вона має працювати на швидкості 60 FPS (кадрів на секунду). Це означає, що у браузера є лише 16.6 мс на підготовку одного кадру. Якщо браузер не встигає — кадри випадають, і користувач бачить 'jank' (смикання).
Рендеринг кадру проходить такі етапи: Style -> Layout (Reflow) -> Paint -> Composite.
Найважчі для процесора (CPU) етапи — це Layout (перерахунок геометрії всієї сторінки) та Paint (малювання пікселів).

2. Магія CSS: Апаратне прискорення (GPU)
Чому всі кажуть, що CSS-анімації швидші? Бо вони декларативні. Браузер заздалегідь знає, що буде відбуватися.
Але є нюанс! CSS буде швидким ТІЛЬКИ, якщо ви анімуєте властивості

Код:

transform

(translate, scale, rotate) та

Код:

opacity

.
Дані: Якщо ви анімуєте `margin-left` на 100px, процесор змушений робити етап Layout 60 разів на секунду. Якщо ви використовуєте `transform: translateX(100px)`, браузер виносить цей елемент на окремий композитний шар (Composite Layer) і передає роботу відеокарті (GPU). GPU просто соває готову картинку. Навантаження на CPU при цьому падає майже до 0%.

3. JavaScript Анімації: Проблема Головного Потоку
Історично JS-анімації через `setInterval` були жахливими. Зараз використовується `requestAnimationFrame()`, який синхронізується з частотою оновлення монітора.
Головна проблема JS-анімацій в тому, що вони виконуються в Головному потоці (Main Thread).
Критичний факт: Якщо ваш сайт завантажує важкий React-додаток, парсить великий JSON або просто виконує складну бізнес-логіку — головний потік блокується. JS-анімація в цей момент просто завмре. Натомість CSS-анімація на GPU (через transform) продовжить плавно працювати навіть при намертво завислому JS!

4. Коли ж використовувати JS (GSAP)?
Попри навантаження на CPU, JS (наприклад, бібліотека GSAP) є незамінним для:
- Складної секвенції (таймлайни).
- Фізики (відскоки, інерція).
- Анімацій, що залежать від скролу (ScrollTrigger).
Сучасний GSAP під капотом змінює той самий `transform`, тому його продуктивність дуже близька до CSS, але з повним контролем над процесом.

Висновки та Best Practices:
- НІКОЛИ не анімуйте width, height, top, left, margin, padding. Це вбивство для бюджетних смартфонів.
- ЗАВЖДИ анімуйте `transform` та `opacity`.
- Використовуйте `will-change: transform;`, щоб підказати браузеру заздалегідь створити GPU-шар. Але обережно: кожен такий шар споживає оперативну пам'ять (VRAM).
- Для простих станів (hover, toggle) -> беріть CSS. Для складних таймлайнів -> JS (GSAP).

Хто стикався з жорсткими 'гальмами' анімацій на мобільних пристроях? Які властивості найбільше грузили ваш сайт?

[Kiber_Arkhitektor]

Дуже крутий аналіз з правильними цифрами! Я колись зробив типову помилку джуна — анімував `box-shadow` на 50 картках товарів одночасно при наведенні. Топові Макбуки ще тягнули це, а от бюджетні Android-телефони просто зависали намертво.

Виявляється, тіні змушують браузер перемальовувати (робити етап Paint) кожен піксель тіні на кожному кадрі. Замінив це на трюк: додав картці псевдоелемент `::after` з готовою статичною тінню, і просто анімував йому `opacity` від 0 до 1. І магія — отримав стабільні 60 FPS на будь-якому калькуляторі.

[Yulia_JS]

До речі, щодо порівняння швидкості. Багато хто досі свято вірить, що JS апріорі повільніший за CSS. Але розробники з GreenSock робили офіційні бенчмарки: якщо вам потрібно анімувати, наприклад, 5000 елементів одночасно, GSAP іноді працює навіть ШВИДШЕ за нативні CSS-transitions!

Це відбувається тому, що рушій GSAP дуже круто оптимізує запис у DOM, батчить оновлення і уникає так званого 'Layout Thrashing', на якому CSS часто спотикається при масових апдейтах.

[rullan]

Дуже цікавий пункт про `will-change`. Нещодавно читав статтю на Хабрі (чи десь ще), де неопитний розробник додав `* { will-change: transform; }` до всього сайту, щоб 'все працювало на відеокарті'.

Спочатку сайт дійсно літав, а через хвилину браузер просто крашнувся від нестачі оперативної пам'яті (Out of Memory). Кожен GPU-шар має вагу в мегабайтах. Тож `will-change` — це як снайперська гвинтівка, яку треба юзати точково, а не палити з неї як з кулемета.

[Stas_Frontend]

А як щодо Web Animations API (WAAPI)? Автор не згадав про цю технологію. Він же дозволяє писати анімації прямо на JS з таймлайнами і контролем (як у GSAP), але при цьому вони виконуються на рівні рушія CSS (на Compositor Thread), минаючи головний потік. Хтось юзав WAAPI у реальному продакшені? Бо поки відчувається як крута демка, яку всі ігнорують.

[rullan]

@Stas_Frontend, WAAPI — штука крута, але його ігнорують через підтримку браузерів (історично) і трохи кострубатий синтаксис порівняно з тим же GSAP. Плюс, у WAAPI досі є проблеми з анімацією скролу та SVG-морфінгом. Поки GSAP існує і працює так добре, більшість бізнесу просто купує ліцензію і не грається з сирими веб-стандартами.