SSG, SSR, ISR: кто собирает HTML и когда

Три ответа на один вопрос

Любая стратегия рендеринга — это ответ на один вопрос: в какой момент сервер превращает ваше React-дерево в HTML? SSG (Static Site Generation) отвечает «во время сборки»: next build рендерит страницу один раз, результат — обычный .html-файл (плюс полезная нагрузка для клиентской навигации), и CDN отдаёт его вечно: TTFB — это скорость ближайшего edge-узла, обычно 10–50 мс, а origin не делает на запрос вообще ничего. SSR (Server-Side Rendering) отвечает «на каждый запрос»: каждый посетитель платит за свежий рендер — сервер забирает данные, исполняет компоненты и стримит HTML. Вы получаете идеальную свежесть и доступ к контексту запроса (cookies, заголовки, гео), а взамен в TTFB въезжает весь ваш слой данных: страница, ждущая запрос к базе на 200 мс, имеет пол TTFB не ниже 200 мс — умноженный на каждого конкурентного пользователя. ISR (Incremental Static Regeneration) — осознанный компромисс: отдавать закешированную статическую страницу немедленно, даже устаревшую, а если она старше своего окна revalidate — запустить перерендер в фоне. Посетитель, который запустил регенерацию, всё равно получает старую страницу; новую увидит следующий. Это паттерн stale-while-revalidate, применённый к целым страницам.

В App Router режим не выбирается флагом конфигурации — поведение маршрута вытекает из того, как он получает данные:

// app/products/[id]/page.tsx

// ISR: страница статическая, перерендеривается в фоне
// не чаще раза в 60 секунд на каждый путь.
export const revalidate = 60;

export async function generateStaticParams() {
  // Топ-100 товаров пререндерим при сборке (SSG);
  // остальные id рендерятся при первом запросе и кешируются (ISR on demand).
  const top = await getTopProducts(100);
  return top.map((p) => ({ id: p.id }));
}

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);
  return <ProductView product={product} />;
}

// Переключить в полный SSR: каждый запрос рендерится заново.
// export const dynamic = "force-dynamic";

Один файл выражает все три режима: пути из generateStaticParams — это SSG, экспорт revalidate превращает кеш в ISR, а force-dynamic (или чтение cookies()/headers()) переводит маршрут в по-запросный SSR. Опасность в том, что всё это неявно: один вызов cookies() глубоко в общем компоненте молча превращает статический маршрут в SSR — и ваша «статическая» страница начинает долбить origin.

Матрица компромиссов: TTFB, свежесть, стоимость инфраструктуры

Разложите три стратегии по трём осям — и выбор станет механическим. TTFB: SSG выигрывает безоговорочно — файл с edge-узла CDN, 10–50 мс, origin не участвует. ISR на горячем пути такой же (это и есть закешированный файл) с редкой фоновой работой. SSR — единственный, у кого TTFB включает вычисления и загрузку данных: реалистично 100–500 мс из региона origin, хуже через континент, и деградирует под нагрузкой, потому что каждый запрос ест CPU сервера. Свежесть: SSR всегда актуален. ISR — ограниченно устаревший: максимум revalidate секунд плюс лаг регенерации. SSG заморожен до следующего деплоя; опечатка на полностью статической странице стоит полного цикла сборки и деплоя — на большом сайте это 10–20 минут. Стоимость инфраструктуры: SSG почти бесплатен на любом масштабе — 10 запросов или 10 миллионов, origin делает одинаково: ничего. ISR стоит один рендер на путь за окно, независимо от трафика — красивое свойство: миллион просмотров в час страницы с revalidate: 60 — это всё ещё ~60 рендеров в час. Стоимость SSR растёт линейно с трафиком; это единственная стратегия, где всплеск трафика — это всплеск вычислений, и единственная, где нужно думать про автоскейлинг и пулы соединений, чтобы пережить главную страницу Hacker News.

Честное правило выбора — не «что лучше», а «какую устарелость этот маршрут может себе позволить»: документация и маркетинг → SSG; листинги товаров, новости, общие для всех дашборды → ISR с окном под реальную частоту изменения данных; всё персонализированное, постраничное по пользователю или читающее cookies → SSR (точнее, динамический рендеринг с кешированными данными под капотом).

Сбои: stale после деплоя и лавина ревалидаций

Две продакшен-аварии определяют эту тему. Первая: ISR отдаёт устаревшее после деплоя. Кеш ISR привязан к сборке. При self-hosted развёртывании кеш по умолчанию живёт в файловой системе каждого инстанса — новый деплой стартует с пустым кешем (или хуже: несколько инстансов держат разные кеши, и пользователи видят разные версии в зависимости от того, в какой под их направил балансировщик). На Vercel кеш общий и переживает деплои для неизменённых страниц, но изменённая страница сбрасывается, и таймеры revalidate сбрасываются вместе с ней. В обоих случаях ментальная модель «деплой сбрасывает всё в свежее» неверна в обе стороны: часть страниц остаётся устаревшей, часть теряет кеш целиком. Для multi-instance self-hosted лекарство — общий обработчик кеша (cacheHandler в next.config.js, указывающий на Redis или аналог), чтобы все поды были согласны, что закешировано. Вторая: лавина ревалидаций (thundering herd). Когда запись популярной страницы истекает — или деплой опустошил кеш — каждый конкурентный запрос в этом зазоре может стать рендером. Внутри одного инстанса Next.js параллельные регенерации дедуплицируются; между инстансами — нет, если ваш cache handler не реализует блокировку. Десять подов × одна истёкшая горячая страница × CMS с rate limit = пятисотки из Hook. Смягчение: разносите окна, чтобы тысячи страниц не истекали синхронно; для данных, меняющихся по событию, предпочитайте on-demand ревалидацию (revalidatePath из вебхука), чтобы окна были длинными; и прогревайте критические пути сразу после деплоя, не отдавая это живым пользователям.