Что такое рендеринг

Рендеринг это не один момент, когда браузер рисует страницу. Это цепочка действий. Браузер получает HTML, CSS и JavaScript, строит внутренние деревья, считает размеры и позиции элементов, рисует пиксели и собирает слои в итоговое изображение.

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

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

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

Плохой пример для частой анимации:

.panel {
  transition: left 200ms;
}

.panel_open {
  left: 0;
}

Так можно случайно получить частый перерасчет layout. Более безопасный вариант для выезжающей панели обычно выглядит так:

.panel {
  transform: translateX(-100%);
  transition: transform 200ms;
}

.panel_open {
  transform: translateX(0);
}

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

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

При SSR сервер формирует HTML на запрос. Пользователь и поисковый робот могут раньше увидеть содержимое, но после этого клиенту все равно нужно загрузить JavaScript и выполнить hydration. Поэтому SSR не означает быстро всегда. Он переносит часть работы на сервер и добавляет вопросы кеширования, нагрузки и согласованности данных. Если страница содержит персональные данные, опасно кешировать готовый HTML как общий публичный ответ. Так можно показать имя, корзину или статус сессии другому пользователю.

При SSG HTML создается заранее на этапе сборки. Это хорошо для документации, лендингов и контентных страниц, где данные редко меняются. Если контент часто обновляется или зависит от пользователя, одного SSG может быть недостаточно.

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

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

Пример, где состояние поднято слишком высоко и заставляет перерендериваться лишнюю часть страницы:

function Page() {
  const [query, setQuery] = useState("");

  return (
    <>
      <SearchInput value={query} onChange={setQuery} />
      <HeavyDashboard />
    </>
  );
}

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

В SSR-приложении сервер может отправить готовый HTML, но браузеру еще нужно подключить обработчики событий и восстановить состояние клиентского приложения. Это и есть hydration. Пользователь может видеть контент, но кнопка еще не работает, пока нужный JavaScript не загружен и не выполнен.

Частая ошибка: использовать значения, которые отличаются на сервере и клиенте.

// Плохой пример для первого SSR-рендера
export function Clock() {
  return <span>{new Date().toLocaleTimeString()}</span>;
}

Сервер и клиент могут получить разное время. В итоге возможен hydration mismatch: текст может мигнуть, React может заменить часть дерева, а пользователь увидит неверное состояние до завершения клиентского рендера. Безопаснее передать одинаковое значение с сервера или показать динамическое время после mount, если оно не должно быть частью серверного HTML.

export function Clock() {
  const [time, setTime] = useState<string | null>(null);

  useEffect(() => {
    setTime(new Date().toLocaleTimeString());
  }, []);

  return <span>{time ?? "Время загружается"}</span>;
}

Похожий риск есть с window, localStorage и случайными значениями во время первого рендера. В SSR их лучше читать после mount или передавать через данные, одинаковые для сервера и клиента.

На интервью удобно отвечать по схеме: сначала определение, затем уровни, затем последствия. Например:

Рендеринг это путь от кода и данных до интерфейса. В браузере это DOM, CSSOM, layout, paint и compositing. Во фреймворке, например React, это пересчет дерева UI и применение нужных изменений к DOM. На практике я смотрю, где выполняется рендеринг, на клиенте, сервере или на сборке, потому что это влияет на первый экран, SEO, hydration и производительность.

Такой ответ показывает, что вы не заучили одно определение, а понимаете, как тема влияет на реальные решения во frontend-разработке.