Перейти к основному содержимому

Рендеринг веб-страницы

Для чего модуль​

Научиться принимать решения по рендерингу через пользовательские метрики и реальные сценарии, а не через «модные подходы».

Результат после прохождения​

  1. Вы понимаете критический путь рендера и умеете находить блокирующие факторы.
  2. Вы интерпретируете LCP/INP/CLS как инженерные сигналы для действий.
  3. Вы выбираете SSR/CSR/SSG/ISR на уровне маршрутов с учетом SEO, latency и стоимости.
  4. Вы умеете диагностировать hydration mismatch и нестабильный initial render.

Термины и аббревиатуры​

ТерминКоротко
LCPСкорость главного контента
INPОтзывчивость
CLSВизуальная стабильность
SSRРендер на сервере
ISRИнкрементальный revalidate

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Используйте один целевой экран для всех уроков модуля.
  2. На каждом шаге фиксируйте baseline и результат изменения.
  3. Не внедряйте оптимизации без явной гипотезы и метрики успеха.

Программа модуля​

Урок 1. Критический путь рендера​

Цель: понимать, где именно браузер тратит время до первого полезного кадра.

Что происходит после navigation​

  1. HTML parsing -> DOM.
  2. CSS parsing -> CSSOM.
  3. DOM + CSSOM -> render tree.
  4. Layout -> paint -> composite.

Блокирующие факторы​

  1. Render-blocking CSS.
  2. Синхронные скрипты в критическом пути.
  3. Тяжелые web-font сценарии без fallback/strategy.
  4. Слишком большой initial JS bundle.

Что обычно улучшает FCP/LCP​

  1. Уменьшение и приоритизация критических ресурсов.
  2. Отложенная загрузка не-критичных блоков.
  3. Оптимизация hero-контента (изображение/текст) для быстрого LCP.

Где ломается в проде​

  1. Один «удобный» shared bundle грузится на все маршруты.
  2. Критический CSS смешан с редко используемыми стилями.
  3. Изображения выше fold не имеют правильных размеров/приоритета.

Мини-задача (обязательная)​

Снимите waterfall одного экрана и выделите 3 ресурса, которые больше всего задерживают first meaningful render.

Что спросит интервьюер: как вы уменьшите время до first meaningful paint без переписывания всего приложения.

Критерий готовности по уроку: вы можете объяснить задержку первого рендера по шагам и предложить 2-3 реалистичные оптимизации.

Урок 2. CWV и диагностика​

Цель: читать Core Web Vitals как рабочую систему принятия решений.

Метрики и смысл​

  1. LCP — скорость загрузки главного контента.
  2. INP — отзывчивость взаимодействий.
  3. CLS — визуальная стабильность.

Lab vs Field​

  1. Lab (Lighthouse) — контролируемый эксперимент.
  2. Field (RUM) — реальный пользовательский трафик.

Вывод: решения принимаются по field-поведению, а lab используется для гипотез и локальной проверки.

Приоритизация улучшений​

  1. Найти наихудший пользовательский сценарий (например, mobile p75).
  2. Выделить bottleneck, который дает максимальный вклад в деградацию.
  3. Проверить эффект после изменения на том же сегменте.

Где ломается в проде​

  1. Команда смотрит только Lighthouse score и игнорирует RUM.
  2. Оптимизируется то, что легко померить, а не то, что болит пользователю.
  3. Нет сегментации (устройства, регионы, сети).

Мини-задача (обязательная)​

Для одного экрана зафиксируйте baseline LCP/INP/CLS, предложите 2 гипотезы улучшения и оцените expected impact.

Что спросит интервьюер: почему «в Lighthouse зеленое» не всегда означает хороший UX в проде.

Критерий готовности по уроку: вы можете обосновать план оптимизации через метрики и пользовательский сценарий, а не через общий score.

Урок 3. SSR, CSR, SSG, ISR​

Цель: выбирать режим рендера как продуктовый компромисс.

Быстрый фреймворк выбора​

  1. Нужен SEO и стабильный контент -> SSG/ISR.
  2. Нужна персонализация на запрос -> SSR/dynamic.
  3. Нужна тяжелая интерактивность после загрузки -> CSR/гибрид.

Trade-offs​

  1. SSR: свежие данные, но выше TTFB/операционная стоимость.
  2. SSG: быстрая отдача, но риск устаревших данных.
  3. ISR: баланс, но нужна дисциплина invalidation/revalidation.
  4. CSR: гибко, но риск медленного first render и SEO-проблем.

Гибридная стратегия по маршрутам​

Обычно лучший путь — не один режим на все приложение, а матрица стратегий на уровне конкретных страниц.

Где ломается в проде​

  1. «Один режим для всего» из-за простоты инфраструктуры.
  2. Отсутствие политики обновления контента для ISR.
  3. Персонализированные данные пытаются кэшировать как публичные.

Мини-задача (обязательная)​

Выберите стратегию рендера для 5 экранов: лендинг, блог, каталог, карточка товара, личный кабинет. Укажите риски и критерии проверки выбора.

Что спросит интервьюер: что вы поменяете первым при плохом LCP на SEO-странице.

Критерий готовности по уроку: вы можете аргументированно защитить рендер-стратегию для каждого типа страницы.

Урок 4. Hydration и клиентские границы​

Цель: устранить нестабильный initial render и трудноуловимые mismatch-баги.

Почему возникает hydration mismatch​

  1. Сервер и клиент рендерят разные значения (Date, random, locale).
  2. Побочные эффекты в render-phase.
  3. Условные ветки, зависящие от browser-only данных.

Правила устойчивого initial render​

  1. На сервере рендерим детерминированный HTML.
  2. browser-only логику переносим в effect/client boundary.
  3. Для нестабильных фрагментов используем явные placeholders/fallback.

Client boundaries и bundle size​

Чем выше по дереву стоит client boundary, тем больше кода уходит в браузер и тем выше цена hydration.

Где ломается в проде​

  1. mismatch проявляется только на части устройств/локалей.
  2. ошибка проявляется «редко», потому что зависит от времени/гонок.
  3. фиксят suppressHydrationWarning, не устраняя причину.

Мини-задача (обязательная)​

Создайте компонент с нестабильным значением (например, дата), воспроизведите hydration mismatch и исправьте его корректно.

Что спросит интервьюер: как вы диагностируете mismatch, если он воспроизводится только в проде.

Критерий готовности по уроку: вы можете довести mismatch до воспроизведения и устранить root cause без «косметических» костылей.

Практика​

  1. Снимите baseline CWV для одного критичного экрана.
  2. Внедрите 2 оптимизации и зафиксируйте after-метрики.
  3. Подготовьте матрицу SSR/CSR/SSG/ISR для маршрутов вашего проекта.
  4. Разберите один hydration mismatch кейс с runbook от симптома до фикса.
  5. Закрепите в Next.js вопросах и Senior Frontend.
  6. Сделайте baseline/after для одного экрана в Песочнице и зафиксируйте влияние изменений.

Связь с треками и вопросами​

  1. Треки: Junior трек, Middle трек, Senior трек.
  2. Вопросы: Next.js, Senior Frontend.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности​

Вы связываете оптимизации рендера с пользовательским эффектом и метриками, а не с абстрактной «красотой архитектуры».

Артефакты после модуля​

  1. Таблица baseline/after по CWV.
  2. Документ выбора рендер-стратегий по типам экранов.
  3. Runbook диагностики hydration mismatch.
  4. Набор из 6 сильных ответов по рендерингу для интервью.

Куда дальше​

  1. React
  2. Next.js
  3. Рендеринг веб-страницы