Какие знаешь стадии отрисовки в браузере?

2.2 Middle🔥 161 комментариев

#Браузер и сетевые технологии

Комментарии (1)

🐱

deepseek-v3.2PrepBro AI4 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Стадии рендеринга (отрисовки) в браузере

Процесс отрисовки веб-страницы в браузере — это сложный конвейер, который можно разделить на несколько ключевых стадий. Понимание этого "рендер-конвейера" (Render Pipeline) критически важно для оптимизации производительности фронтенд-приложений. Основные этапы можно сгруппировать в следующий порядок.

1. Парсинг (Parsing) и построение DOM/CSSOM

Браузер начинает с загрузки и анализа исходного HTML, CSS и JavaScript.

Построение DOM (Document Object Model):

<!-- Браузер читает этот HTML -->
<html>
  <head>
    <title>Страница</title>
  </head>
  <body>
    <p>Привет, мир!</p>
  </body>
</html>

    Браузер преобразует HTML в древовидную структуру данных — **DOM-дерево**. Каждый тег становится узлом (node) в этом дереве. Этот процесс может быть приостановлен, если встретится тег `<script>` без атрибутов `async` или `defer`, так как браузеру необходимо загрузить и выполнить JavaScript, который может изменить DOM.

Построение CSSOM (CSS Object Model):

/* Браузер читает этот CSS */
p { color: red; font-size: 16px; }
body { background: #fff; }

    Аналогично, CSS-правила парсятся и преобразуются в **CSSOM-дерево**. Это дерево стилей, которое определяет, как должны выглядеть узлы DOM. Важно: CSSOM строится с учётом каскада и специфичности, поэтому этот процесс часто блокирующий и **render-blocking**.

2. Формирование Render Tree (Дерева отрисовки)

На этом этапе браузер объединяет DOM и CSSOM в единую структуру — Render Tree (или Frame Tree).

Render Tree содержит только видимые элементы, которые будут отрисованы на экране. Элементы с display: none не включаются в него, а элементы с visibility: hidden или opacity: 0 — включаются (они занимают место, но не видны).
Каждый узел в Render Tree (часто называемый renderer или layout object) хранит информацию о геометрии и стилях элемента.

3. Layout (или Reflow) — Расчёт макета

Это стадия вычисления точного положения и размеров каждого видимого элемента на экране. Браузер проходит по всему Render Tree и рассчитывает геометрию: координаты (x, y), ширину, высоту, отступы, границы и т.д. Это очень ресурсоёмкая операция, особенно при изменениях в DOM, которые влияют на геометрию многих элементов (например, изменение ширины body, добавление нового DOM-узла, изменение размеров окна браузера).

// Примеры действий, вызывающих Layout (Reflow):
element.style.width = '300px'; // Изменение ширины
element.classList.add('expanded'); // Класс меняет размеры/позицию
window.addEventListener('resize', callback); // Изменение размеров окна
// Чтение layout-свойств после их записи также может вызвать принудительный синхронный reflow

4. Paint (или Rasterization) — Отрисовка

На этом этапе браузер преобразует рассчитанный макет в пиксели на экране. Происходит заполнение пикселей: рисование текста, цветов, изображений, границ, теней и других визуальных частей элементов. Процесс отрисовки часто разбивается на слои (layers) и может выполняться в несколько проходов. Например, сначала рисуется фон, затем границы, затем текст.

Области отрисовки (Paint rectangles): Браузер пытается определить, какие области экрана изменились, и перерисовать только их, а не всю страницу. Это называется инвалидация областей.

5. Compositing — Компоновка

Современные браузеры используют аппаратное ускорение и разбивают страницу на графические слои (layers). Слои отрисовываются отдельно в памяти (часто в отдельном потоке, называемом Compositor Thread), а затем объединяются в правильном порядке (компонуются) в единое итоговое изображение на экране. Этот этап отвечает за правильное наложение слоёв согласно CSS-свойствам z-index, opacity, transform и другим.

Преимущество: изменения, затрагивающие только композицию (например, анимация с помощью transform или opacity), могут быть выполнены очень дешёво, так как браузеру не нужно пересчитывать Layout и Paint для всего элемента, а достаточно просто переместить/смешать уже готовый слой.

// Оптимально для анимации: вызывает только Compositing stage
element.style.transform = 'translateX(100px)';
// Неоптимально: вызовет Layout, Paint, затем Compositing
element.style.left = '100px';

Критический путь рендеринга (Critical Rendering Path) и оптимизация

Последовательность: DOM → CSSOM → Render Tree → Layout → Paint → Composite называется критическим путём рендеринга. Задача фронтенд-разработчика — максимально его оптимизировать:

Минимизируйте работу на стадии Layout: Избегайте "thrashing layout" (чтение layout-свойств сразу после их записи), используйте requestAnimationFrame для визуальных изменений.
Упрощайте Paint: Уменьшайте сложность селекторов, используйте свойства, не вызывающие Paint (transform, opacity).
Управляйте слоями: Свойства will-change или transform: translateZ(0) могут (с осторожностью) использоваться для создания отдельного графического слоя, что полезно для анимаций.

Понимание этих стадий позволяет осознанно подходить к написанию кода и создавать плавные, отзывчивые интерфейсы с частотой 60 кадров в секунду.