Цена стадий и модель процесса рендерера

Ваша страница парсится быстро на M2 MacBook. На среднем Android тормозит. Бутылочное горлышко никогда не бывает «CPU медленный» — оно всегда в том, какой поток делает какую работу и сколько её приходится на поток, который нельзя распараллелить.

Модель процесса рендерера

Современный браузер семейства Chromium запускает каждую вкладку в отдельном процессе рендерера. Внутри этого процесса:

• Главный поток — исполняет парсинг HTML, построение CSSOM, стили, компоновку, подготовку отрисовки и ваш JavaScript. Он однопоточный по дизайну: DOM, CSSOM и состояние JS могут изменяться только одним контекстом исполнения за раз, иначе согласованность невозможна.
• Поток композитора — собирает дерево слоёв и решает, каким слоям нужны новые bitmap-ы.
• Растровые рабочие потоки — параллельно растеризуют отдельные тайлы.
• GPU-процесс — берёт растеризованные тайлы, загружает их как текстуры, выполняет финальный композит-и-показ.

Firefox использует похожее разделение (Quantum CSS для параллельных стилей, WebRender для GPU-driven композитинга); Safari/WebKit разделяет между WebContent-процессом и GPU-процессом. Имена разные, архитектурная рифма универсальна.

Почему главный поток — бутылочное горлышко

Любая работа на главном потоке — парсинг JSON-блоба, десериализация Redux-стейта, компоновка, обработчик клика — конкурирует за то же окно в 16.67 мс. Поток композитора и растровые потоки существуют именно для того, чтобы кусок работы рендеринга мог уйти с главного потока и работать параллельно.

Это архитектурное обоснование того, что transform/opacity-анимации «бесплатные»: они достигают GPU, не трогая узкое горло главного потока.

Усилители цены по стадиям

У каждой стадии есть типовые рычаги, раздувающие её цену.

Парсинг HTML масштабируется с байтами документа. SSR-страница 500 КБ парсится быстрее, чем 2 МБ. Синхронные тэги <script> блокируют парсер — современная практика ставит defer или async на всякий внешний скрипт, не строго нужный для первой отрисовки.

CSSOM растёт с байтами стилей и количеством правил. Неиспользуемый CSS-фреймворк на 800 правил тратит время парсинга, даже если ноль правил матчатся.

Пересчёт стилей стоит примерно размер DOM × селекторы. DOM 5 000 нод плюс 2 000 правил — 10 миллионов проверок мэтчинга. Большинство отсеивается bloom-фильтром, но :has(), descendant combinators без anchor-предка и универсальные селекторы пробивают фильтр.

Компоновка — примерно глубина DOM × зависимости между коробками. Глубоко вложенный flexbox с auto-размерами требует нескольких проходов измерения; плоский grid с явными размерами ячеек — одного.

Отрисовка — площадь × количество paint-операций. box-shadow с большим blur radius и filter-свойства тяжелы для отрисовки: каждый пиксель требует мульти-пиксельной выборки.

Композитинг — количество слоёв × площадь пикселей слоя. Дешёвые стадии дешевле на порядки — но только если верхние стадии не инвалидируют нижние.