Какие стадии рендеринга страниц бывают и какие выполняются на процессоре, а какие на видеокарте

Что проверяют

Понимаете ли вы, что происходит между получением HTML и пикселями на экране, и можете ли объяснить, почему одни анимации плавные, а другие дёргаются. Следом обычно спрашивают, какие CSS-свойства дёшево анимировать и что такое принудительный layout.

Как отвечать

Опишите конвейер на примере Chromium, у других движков этапы похожи:

• парсинг: HTML превращается в DOM, CSS в CSSOM. CPU, главный поток;
• style: браузер сопоставляет селекторы с элементами и вычисляет итоговые стили. CPU, главный поток;
• layout: расчёт геометрии, размеров и позиций боксов. CPU, главный поток;
• paint: не рисование пикселей, а запись списка команд отрисовки (display list). Тоже главный поток;
• разбиение на слои и растеризация: страница делится на слои и тайлы, команды превращаются в пиксели. В современном Chrome растеризация по умолчанию идёт на GPU, если драйвер это позволяет, а программный растр остаётся запасным вариантом;
• composite: готовые слои собираются в кадр с учётом transform и opacity. Отдельный поток композитора и GPU.

Отсюда практический вывод. Изменение width или top запускает layout, paint и композитинг заново. Изменение transform и opacity у элемента на отдельном слое обходится одним композитингом и работает, даже когда главный поток занят JavaScript. will-change: transform заранее выносит элемент на свой слой, но каждый слой стоит видеопамяти.

Проверяется это в DevTools: панель Performance показывает долгие задачи и этапы кадра, вкладка Rendering включает подсветку перерисовки (Paint flashing), панель Layers показывает слои.

Где спотыкаются

Считают, что «рендеринг на видеокарте» значит вся страница на GPU. Стили, layout и запись paint остаются на CPU в главном потоке, и именно там чаще всего теряются кадры.

Не знают про принудительный синхронный layout: чтение offsetHeight или getBoundingClientRect() сразу после изменения стилей в цикле заставляет браузер пересчитывать геометрию на каждой итерации.

Вешают will-change на всё подряд. Сотни слоёв съедают память, и на слабых мобильных устройствах композитинг становится медленнее, а не быстрее.