Какие режимы рендеринга есть в Next.js: SSR, SSG, ISR и CSR?

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

CSR — Client-Side Rendering

Сервер отдаёт почти пустой HTML и JS, страница строится в браузере. Просто, но медленный первый контент и слабая индексация. Подходит для закрытых кабинетов.

SSR — Server-Side Rendering

HTML формируется на каждый запрос. Данные всегда свежие, хорошо для SEO и персонализации, но каждый запрос нагружает сервер, а TTFB выше.

// Pages Router
export async function getServerSideProps() {
  const data = await fetchData();
  return { props: { data } };
}

В App Router серверные компоненты рендерятся на сервере по умолчанию, динамическая отрисовка включается при использовании cookies, headers или cache: 'no-store'.

SSG — Static Site Generation

HTML создаётся один раз при сборке и раздаётся с CDN. Максимально быстро и дёшево, но данные устаревают до следующей сборки. Подходит для блога и документации.

export async function getStaticProps() {
  return { props: { posts: await fetchPosts() } };
}

ISR — Incremental Static Regeneration

Статическая страница обновляется в фоне по таймеру или по запросу:

export async function getStaticProps() {
  return { props: { data }, revalidate: 60 }; // не чаще раза в 60 секунд
}

Пользователь получает быструю статику, а данные остаются достаточно свежими. В App Router аналог — revalidate и revalidateTag.

Как выбирать

• Данные меняются редко → SSG.
• Часто, но допустима небольшая задержка → ISR.
• Нужны свежие или персональные данные при каждом запросе → SSR.
• Интерактивная часть без SEO → CSR.

Коротко для собеседования

CSR строит страницу в браузере, SSR — на сервере при каждом запросе, SSG — при сборке, ISR — статика с фоновым обновлением. Выбор зависит от свежести данных, SEO и нагрузки.