Gernar
Frontend DeveloperПроизводительность

Интервью-вопрос

Что такое критические этапы рендеринга

Это последовательность шагов, через которые браузер превращает ресурсы страницы в видимый интерфейс. На интервью важно не только назвать этапы. Покажите, какие ресурсы задерживают первый экран и как вы это измеряете.

Добавлен
Редакция

Подготовьте короткий ответ и пару деталей на случай уточняющих вопросов.

🐰0
🥚0

Мини-квиз

Проверка перед разбором

Несколько быстрых вопросов перед разбором. Так проще поймать места, которые только кажутся понятными.

Вопрос 1 из 50 правильно

Как лучше объяснить критические этапы рендеринга?

Вы сейчас отвечаете коротко и хотите показать не только определение, но и практический смысл.

Варианты ответа

Разбор

Разобраться, а не зазубрить

Дальше разбираем суть, типичные уточнения и места, где легко сказать лишнее или перепутать термины.

Базовая идея

Критические этапы рендеринга помогают объяснить, как браузер превращает документы и ресурсы в экран. В базовом ответе не потеряйте цепочку: HTML превращается в DOM, CSS превращается в CSSOM, затем браузер строит render tree, считает геометрию на этапе layout, рисует пиксели на paint и собирает слои на этапе compositing.

Не останавливайтесь на списке терминов. Добавьте, что каждый этап может задержаться из-за ресурсов или тяжелой работы на main thread. Так вы связываете устройство браузера с реальной проблемой: медленным первым экраном, плохим LCP, дергаными анимациями и интерфейсом, который уже виден, но еще плохо реагирует на действия.

Первый рендер
  1. 1Получить HTML и начать парсинг
  2. 2Построить DOM и дождаться нужного CSSOM
  3. 3Собрать render tree
  4. 4Посчитать layout и выполнить paint
  5. 5Собрать слои в итоговый кадр
Что легко задерживает
  1. 1Большой CSS в head без разделения
  2. 2Синхронный script перед важным контентом
  3. 3Тяжелые шрифты и LCP-изображения без приоритета
  4. 4JavaScript, который долго занимает main thread
  5. 5Частые чтения и записи layout-свойств вперемешку

Как JavaScript и CSS влияют на первый рендер

CSS обычно критичен для первого рендера, потому что без CSSOM браузер не может корректно построить render tree. Если в head лежит большой общий CSS-файл, первый экран может ждать стили, которые нужны ниже или на другой странице.

JavaScript тоже может блокировать путь. Обычный script без defer или async останавливает парсинг HTML, пока файл не загрузится и не выполнится. Если такой скрипт стоит перед важным контентом, пользователь увидит страницу позже.

Плохой пример:

<head>
  <link rel="stylesheet" href="all-pages.css" />
  <script src="app.js"></script>
</head>

Здесь большой CSS и синхронный скрипт могут задержать первый рендер. Пользователь дольше видит пустой экран. Есть еще один риск: app.js может выполниться до разметки из body и сломать инициализацию UI, если код сразу ищет элементы на странице.

Более безопасный вариант для некритичного кода:

<head>
  <link rel="stylesheet" href="critical.css" />
  <script src="app.js" defer></script>
</head>

defer не блокирует парсинг HTML и выполняет скрипт после построения документа. Это не универсальный рецепт для любого проекта. На интервью важно показать принцип: критичное для первого экрана загружаем рано, некритичное не ставим на пути первого рендера.

Как выбирать оптимизацию

Не отвечайте, что достаточно просто минифицировать все файлы. Минификация полезна, но она не решит проблему, если главный тормоз это тяжелая гидратация, блокирующий шрифт или большой JavaScript на main thread. Сначала найдите узкое место, потом выбирайте действие. Например, не ставьте preload на все шрифты и картинки подряд: так можно забить сеть и ухудшить LCP вместо ускорения.

Как выбрать оптимизацию

1Первый экран зависит от большого CSS-файла?
Выделите critical CSS, остальное грузите позже или по media-условиям.
2Скрипт не нужен до интерактивности страницы?
Используйте defer, динамический import или загрузку после первого рендера.
3LCP-элемент это изображение или шрифт?
Проверьте preload только для действительно важного ресурса, размеры, формат и приоритет загрузки. Лишний preload может отнять сеть у критичных файлов.
4Есть лаги после загрузки?
Ищите лишний layout, дорогой JavaScript и частые изменения DOM в Performance.

Reflow, repaint и runtime-производительность

После первого рендера браузер продолжает пересчитывать и перерисовывать страницу при изменениях. Если вы меняете размеры, позицию, шрифты или добавляете элементы, браузер может снова выполнить layout. Если меняется только визуальное оформление, например цвет фона, часто достаточно paint. Для transform и opacity браузер во многих случаях может использовать compositor, поэтому такие свойства часто выбирают для анимаций.

Не говорите, что transform всегда бесплатен. Слои занимают память, а слишком много слоев тоже может ухудшить производительность. Сильный ответ звучит так: я понимаю, какие изменения затрагивают геометрию, стараюсь не провоцировать лишний layout в циклах и проверяю поведение в Performance, а не оптимизирую по догадке.

Что сказать на интервью коротко

Можно ответить так:

Критические этапы рендеринга это цепочка, по которой браузер превращает HTML, CSS и JavaScript в видимую страницу. Сначала строятся DOM и CSSOM, потом render tree, layout, paint и сборка слоев. На практике я смотрю, какие ресурсы блокируют первый экран: CSS, синхронные скрипты, шрифты, LCP-изображения и тяжелая работа main thread. Оптимизация зависит от узкого места: critical CSS, defer, code splitting, preload и измерение в DevTools.

Эту формулировку можно сократить, если интервью идет быстро. Главное оставить три части: этапы, риск для пользователя и способ оптимизации через измерение.

Частые ошибки

Где обычно ошибаются

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

  1. 1

    Перечислять этапы без практического вывода

    Если вы только называете DOM, CSSOM, layout и paint, ответ звучит как заученное определение. Добавьте, что именно может задержать первый экран и как вы это проверяете. Так вы покажете, что связываете модель браузера с производительностью продукта.
  2. 2

    Считать async и defer взаимозаменяемыми

    async выполняет скрипт сразу после загрузки и может прервать парсинг HTML. defer сохраняет порядок скриптов и выполняет их после парсинга документа. Для обычного некритичного кода приложения чаще безопаснее defer. Иначе можно получить гонки и нестабильную инициализацию.
  3. 3

    Путать layout, paint и compositing

    Изменение width или font-size обычно требует пересчета геометрии. Изменение background-color чаще требует только перерисовки. transform и opacity часто дешевле, но это не магия. Слои тоже занимают память и могут перегрузить compositor.
  4. 4

    Оптимизировать наугад

    Удаление пары килобайт CSS не поможет, если главный тормоз это тяжелая гидратация или LCP-изображение. Сначала снимите trace в Chrome DevTools, проверьте Lighthouse и реальные метрики. Потом выбирайте действие под найденное узкое место.

Follow-up

Что могут спросить дальше

Короткие ответы на вопросы, которые часто идут следом за базовым объяснением критического пути рендеринга.

Живые ответы

Видео с похожим вопросом

Если найдем публичные интервью с таким вопросом, добавим их сюда. Их удобно смотреть после теории, чтобы свериться с живыми ответами.

Пока видео нет. Когда появятся подходящие публичные интервью, добавим их в этот блок, чтобы можно было сравнить разбор с тем, как отвечают реальные кандидаты.

Как можно оптимизировать рендер 😎

Оптимизация рендера начинается с измерений, поиска лишних обновлений и точечного применения мемоизации, виртуализации, разбиения кода и правильной работы со state. На странице разбираем, что сказать на интервью и какие ошибки чаще всего приводят к медленному UI.

Что такое сложная операция 😎

Сложная операция во фронтенде долго занимает CPU, память, сеть или основной поток браузера. Разбираем, как объяснить это на интервью, как распознать риск для UI и какие оптимизации назвать.

Содержание

Базовая идеяКак JavaScript и CSS влияют на первый рендерКак выбирать оптимизациюReflow, repaint и runtime-производительностьЧто сказать на интервью короткоЧастые ошибки