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

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

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

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

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

  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.

Визуальная проверка: Browser Rendering: text update, затем layout change и transform 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. CWV baseline и bottleneck map​

Связка: Senior q-3, Next.js q-10, Next.js q-14, DOM/a11y audit pack.

Что сделать:

  1. Снимите baseline для одного критичного экрана: LCP, INP, CLS, TTFB, transfer size, main-thread long tasks.
  2. Найдите LCP element и выпишите waterfall: server work, cache, image/font, render-blocking CSS/JS, client bundle.
  3. Внесите 2 оптимизации и зафиксируйте before/after: что изменилось, какая метрика затронута, какой пользовательский эффект улучшился.

Артефакт: CWV baseline/after table + TTFB/LCP bottleneck map.

Критерий готовности: вы не говорите "ускорю страницу" абстрактно, а показываете конкретную метрику, причину, evidence и проверку после фикса.

2. Rendering strategy decision table​

Связка: Senior q-4, Next.js q-3, Next.js q-8.

Что сделать:

  1. Выберите стратегию для 5 экранов: landing, blog article, catalog, product page, account/checkout.
  2. Заполните таблицу route -> freshness -> SEO -> personalization/auth -> cache -> mode -> failure mode -> validation.
  3. Для каждого route назовите, что сломается при неправильном выборе: stale content, private data leak, high TTFB, poor first content, hydration mismatch.

Артефакт: rendering strategy decision table.

Критерий готовности: вы выбираете CSR/SSR/SSG/ISR не по моде, а по данным, freshness, personalization, cacheability, SEO и hydration risk.

3. Hydration mismatch runbook​

Связка: Next.js q-6, Next.js q-19, Next.js q-20.

Что сделать:

  1. Воспроизведите mismatch на нестабильном значении: Date, random, locale/timezone, window/localStorage или неправильная HTML-вложенность.
  2. Заполните diagnosis table: source of nondeterminism -> server render -> first client render -> fix -> why not suppressHydrationWarning.
  3. Исправьте root cause: deterministic initial render, client boundary/effect, stable placeholder или маленький no-SSR island там, где это оправдано.

Артефакт: hydration mismatch runbook from symptom to root cause.

Критерий готовности: вы отличаете hydration mismatch от обычного client update и не прячете warning косметическим suppress.

4. Main thread, lists и client boundary cost​

Связка: Senior q-14, Senior q-15, Next.js q-17, Browser Rendering: layout thrashing.

Что сделать:

  1. Разберите экран со списком: 100, 1 000, 20 000 элементов, variable row height, keyboard navigation, SEO need.
  2. Заполните large-list decision matrix: pagination, infinite scroll, virtualization, server filtering/sorting, Web Worker, progressive loading.
  3. Проверьте client boundary cost: какие данные реально должны быть client state, что можно оставить server/rendered, где hydration расширяет bundle.

Артефакт: large-list rendering decision matrix + client boundary cost note.

Критерий готовности: вы не ставите virtualization по умолчанию, а доказываете, что bottleneck в DOM/main thread/client JS, и проверяете INP, focus behavior, scroll restoration и a11y risk.

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

  1. Performance budget и CWV: Senior q-3, Next.js q-10, Next.js q-14.
  2. Rendering mode: Senior q-4, Next.js q-3, Next.js q-8.
  3. Hydration: Next.js q-6, Next.js q-19, Next.js q-20.
  4. Main-thread/list cost: Senior q-14, Senior q-15, Next.js q-17.
  5. Практический мост: строка HTML, CSS and rendering, Browser Rendering: layout change и DOM/a11y audit pack.

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

Ready: вы связываете rendering-решение с метрикой, user impact, route constraints, failure mode и проверкой в DevTools/Web Vitals.

Partial: вы знаете SSR/CSR/SSG/ISR и CWV определения, но не можете выбрать стратегию для конкретного route или доказать bottleneck.

Not ready: вы предлагаете "добавить SSR", "добавить memo", "поставить virtualization" или suppressHydrationWarning без диагностики причины.

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

  1. CWV baseline/after table для одного критичного экрана.
  2. TTFB/LCP bottleneck map.
  3. Rendering strategy decision table для 5 route types.
  4. Hydration mismatch diagnosis table and runbook.
  5. Large-list rendering decision matrix.
  6. Client boundary cost note: что стало client-side и почему это оправдано.

Куда дальше​

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