Головний потік браузера — дорогий ресурс: як витрачати його ощадливо

Розмови про оптимізацію фронтенду зазвичай точаться навколо мережевих запитів, розміру бандла й кешування. Головний потік згадують рідко, бо на звичайних екранах він не стає проблемою. Але там, де багато взаємодії, жодна економія на мережі не допоможе, якщо потік, який виконує ваш код, заблоковано. Допис «The Browser's Main Thread Is Expensive» у блозі kciter.so присвячений тому, як витрачати цей ресурс ощадливо.

Один потік — два завдання

Головний потік виконує JavaScript — ваш код, обробники подій, таймери, внутрішню логіку фреймворку — і малює екран: обчислення стилів, компонування, фарбування. Для плавності кадр має з'являтися з частотою оновлення дисплея: близько 16,6 мілісекунди на 60 Гц, а практичний бюджет після віднімання витрат браузера — приблизно 10 мс. JavaScript працює за моделлю однопотокового циклу подій: поки виконується одне завдання, не відбувається нічого іншого. Функція на 200 мс на цей час заморожує перемальовування, анімацію та введення. Завдання довші за 50 мс вважають довгими, а метрики INP і TBT по суті вимірюють тривалість блокування головного потоку. Причина зазвичай не в повільному коді — достатньо того, що код займає потік.

Чотири прийоми ощадливого витрачання

Автор групує техніки в чотири кроки. Розбиття ділить довгу роботу на частини й віддає потік між ними — наприклад, після кожних 20 повідомлень чату або з бюджетом 5 мс на кадр, прив'язаним до requestAnimationFrame. Поступливість не прискорює роботу: вона створює проміжки, у яких браузер встигає обробити введення й перемалювати екран.

Групування скорочує завдання, що спрацьовують надто часто — debounce і throttle для прокручування та введення, одне малювання на кадр для живих панелей. Пріоритезація визначає порядок: черга на MessageChannel дозволяє роботі для щойно натиснутого фото випередити фонове створення прев'ю. Відкладання питає, чи потрібна робота саме зараз: розділення коду на старті, IntersectionObserver для побудови лише близьких до екрана постів, зупинка анімацій поза екраном.

Поза головним потоком

Частину роботи можна передати зовсім. Анімація transform і opacity залишається на потоці композитора й не смикається навіть під навантаженням, тоді як анімація top чи width змушує перераховувати компонування щокадру; техніка FLIP перетворює реальну зміну розкладки на анімацію через transform. Web worker бере важкі обчислення, як-от парсинг чи обробку зображень, хоча не має доступу до DOM і зазвичай обмінюється даними копіюванням — якщо буфер не передати, що переносить володіння майже без витрат.

Не робити роботу взагалі

Найбільший виграш часто дає усунення роботи: відкидання застарілих записів, коли потік даних перевищує пропускну здатність, злиття накопичених оновлень в останнє значення, мемоїзація повторюваних обчислень. Застосунки реального часу — стрімінгові платформи, редактори, карти, ігри — гальмують, щойно головний потік завантажений, а новітнє залізо є не в кожного. Перш ніж прискорювати завдання, варто спитати: чи потрібна ця робота взагалі, саме зараз і саме тут?