EMZETT.
Войти

Стратегии отрисовки: сравнение SSR, SSG, ISR и клиентской отрисовки

Коротко: Веб-страницу можно генерировать во время сборки (SSG), при каждом запросе (SSR), периодически заново (ISR) или в браузере (CSR); выбор влияет на скорость, свежесть, стоимость и пригодность для поисковых систем.

Подробнее: Вопрос в том, когда и где возникает HTML. Фреймворки вроде Next.js позволяют выбирать это для каждой страницы.

Подробности

Стратегии

  • SSG (статическая генерация сайта): HTML генерируется во время сборки и отдаётся через CDN. Очень быстро, дёшево, безопасно; но актуально лишь настолько, насколько последняя сборка. Идеально для блога, документации, вики, посадочных страниц.
  • SSR (отрисовка на сервере): сервер генерирует HTML при каждом запросе; всегда актуально и персонализируемо (cookie), но медленнее и дороже (время вычислений, возможно, база данных).
  • ISR (инкрементальная статическая регенерация): статическая страница со сроком действия (revalidate: 3600); по истечении пересобирается в фоне. Хороший компромисс для списков, магазинов, новостей.
  • CSR (отрисовка на клиенте): браузер загружает JavaScript и строит страницу; хорошо для панелей за входом, хуже для времени первой загрузки и SEO.
  • Streaming/Suspense: страница отдаётся частями; важное появляется первым.

Помощь в выборе

ТребованиеВыбор
Редко меняющееся содержимое, много трафикаSSG
Содержимое меняется каждую минуту/часISR
Разное для каждого пользователя (корзина, профиль)SSR или CSR
За входом, интерактивноCSR (или SSR + клиентские компоненты)
SEO важноSSG/ISR/SSR

Гибриды нормальны: статическая оболочка, динамические части через streaming или клиентский запрос.

Последствия

  • Нагрузка на базу данных: SSR/ISR запрашивают её; с кэшированием (см. unstable_cache, revalidate) и долгими сроками действия нагрузка резко падает, особенно у бессерверных баз данных, которые приостанавливаются в простое и тарифицируют время вычислений.
  • Стоимость и скорость: отдача статических страниц через CDN дешевле всего.
  • Устойчивость: статические страницы продолжают работать, даже если база данных недоступна; поэтому сборки не должны зависеть от базы данных или должны перехватывать ошибки.
  • Свежесть: с повторной проверкой по требованию (теги/пути) можно целенаправленно пересобирать после изменений.

Практика

Начинайте со статики, добавляйте динамику там, где нужно. Измеряйте с Lighthouse/Core Web Vitals (LCP, CLS, INP). Подходящим образом задавайте заголовки кэша. Проверяйте поведение при сбое базы данных и холодных стартах. В Next.js: export const revalidate = 3600, dynamic = 'force-dynamic', generateStaticParams, серверные компоненты с fetch и опциями кэша (смотрите документацию вашей версии, API меняется).

См. также: Next.js App Router, Стратегии кэширования, Теги кэша и revalidateTag, Lighthouse и Core Web Vitals, Бессерверные вычисления