Удивительные возможности ISR в Next.js: статика, которая умеет дышать

Что такое ISR на самом деле

ISR — это Incremental Static Regeneration.
По сути, это способ сказать фреймворку:
"Отрендери мне страницу как статику, но умей по-тихому её пересобирать в фоне, когда она устареет."

То есть:

первый пользователь получает готовый HTML со скоростью света (из CDN),
один из последующих (по таймеру) — триггерит пересборку,
остальные — продолжают получать старую версию, пока не соберётся новая,
как только новая версия готова — она подменяет старую.

Это не SSR и не SSG. Это переосмысленный SSG с контролируемым обновлением.

Почему это действительно мощно

1. Почти мгновенный TTFB — но данные не устаревают

Сайт отдаёт статику. Без Node.js, без Lambda, без рантайма.
TTFB стремится к нулю. Но вы сами определяете, через сколько секунд эта "статическая" страница считается просроченной. Например:

Каталог товаров — раз в 60 секунд
Блог — раз в час
Главная — раз в 10 минут

2. Работает в фоне, не блокирует запросы

Важно понимать: ISR не блокирует поток.
Даже если страница пересобирается, пользователь не ждёт. Он просто получает последнюю доступную версию.

Никаких спиннеров, загрузок, "подождите, мы обновляем данные" — ISR делает это тихо.

3. Простой API

Вы продолжаете использовать getStaticProps, просто добавляете revalidate:

export async function getStaticProps() {
  const data = await fetch(...)

  return {
    props: { data },
    revalidate: 60, // пересобирать раз в 60 секунд
  }
}

Вот и всё. Никакого магического кода. Вся сложность скрыта в механизме Next.js и CDN.

4. Идеально для headless CMS

Если вы работаете со Strapi, Directus, Sanity или любым другим headless API, ISR — это идеальный способ соединить продакшен и редактируемость.

Контент меняется — страница обновляется. Но пользователи этого не замечают.

Почему это удобно

Мгновенная загрузка

Так как страница лежит на CDN, отдаётся она мгновенно.
Нет необходимости вызывать сервер каждый раз — результат рендера уже готов и кэширован.

Свежие данные без SSR

Вы можете определить, через сколько секунд страница должна быть «протухшей».
Например, товары обновляются каждую минуту, блог — раз в час, а лендинг — раз в сутки.
Как только кто-то заходит на страницу после указанного времени — в фоне запускается её пересборка.

Никаких задержек для пользователей

Важно: посетитель не ждёт, пока страница обновится.
Если старая версия всё ещё валидна — она отдается как есть.
Если она устарела — отдается последняя доступная, а новая собирается в фоне.

То есть никакой блокировки, загрузок или прелоадеров. Пользователь всегда получает результат мгновенно.

Где это особенно уместно

ISR идеально работает в связке с headless CMS.
Если вы работаете со Strapi, Directus, Sanity или даже Markdown-блогом —
ISR позволяет изменять контент в админке, а страница на сайте будет автоматически обновлена в течение заданного интервала.

Это удобно и для SEO, и для UX, и для команды контент-менеджеров.

Что нужно знать

ISR работает только в production.
Пересборка запускается только при следующем заходе на страницу после истечения интервала.
Никакой серверной нагрузки — всё работает через CDN и встроенные механизмы Next.js.
При использовании кастомного сервера нужно правильно настроить кеширование и проксирование, особенно если хостите не на Vercel.

Наш опыт

Мы в ZNN активно используем ISR на всех проектах, где:

контент редактируется через CMS,
важна высокая производительность (по SEO и Lighthouse),
нет желания переплачивать за SSR-инфраструктуру.

В частности, каталоги, статьи, маркетинговые страницы и лендинги — всё это работает у нас через ISR.

Результат — быстрая загрузка, стабильная работа, масштабируемость без боли.

Где мы используем ISR: кейс frontend-main

Одно дело — знать, что ISR существует. Совсем другое — правильно встроить его в архитектуру.
В проекте frontend-main, который мы развиваем в ZNN, мы сознательно выбрали гибридный подход, совмещая статическую генерацию, ISR, серверный рендеринг и клиентские компоненты.

Подход к рендерингу в текущем сайте

Архитектура

Сайт строится вокруг Incremental Static Regeneration — ключевых страниц блога и категорий.
Контент приходит из headless CMS (в нашем случае — Directus), и обновляется каждые 30–60 минут.
Это обеспечивает баланс между скоростью и свежестью:
страницы грузятся мгновенно, но не устаревают.

Главная страница — интерактивная, построена как клиентский компонент с динамической загрузкой данных.
При этом мы сохраняем SSR-гибкость: на первом рендере получаем HTML, а затем происходит гидратация и догрузка содержимого.

Кэширование и надёжность

Мы внедрили уровень кэширования на fetch: API-роуты отдают данные с актуальностью в пределах одного часа.
Если Directus временно недоступен — сайт продолжает работать, подставляя моковые данные.
Такой подход особенно важен в публичных проектах: контент может устареть, но не должен исчезнуть.

Почему это важно

Производительность:
Страницы отдаются из CDN, работают быстро даже при высокой нагрузке.
SEO:
Статические метаданные, OpenGraph, правильные canonical-ссылки — всё это отдается с первого рендера.
UX:
Благодаря клиентским компонентам, мы сохраняем интерактивность и плавные переходы.
Даже если пользователь взаимодействует с сайтом до загрузки данных — он видит адаптивные fallback-элементы.
Отказоустойчивость:
Мы предусмотрели механизм graceful degradation.
Даже если API не отвечает, сайт остаётся работоспособным — пусть и с частично устаревшими или моковыми данными.

Не смотря на это мы не считаем этот сайт эталонным и по прежнему пытаемся добится более лучшего перфоманса не теряя визуальной составляющей.

Заключение

Incremental Static Regeneration — это, по сути, новое понимание статической генерации.
Это статика с механизмом самообновления, работающая как живой сайт, но без типичных минусов SSR.

Если вы ещё не внедряли ISR в своих проектах — это повод пересмотреть архитектуру.
Он избавляет от выбора между «быстро» и «свежо». С ISR вы просто получаете и то, и другое.