Стратегии отрисовки: сравнение 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, Бессерверные вычисления