Какие режимы рендеринга существуют в Nuxt 3: SSR, SSG, SPA, ISR и гибридный режим?

Обзор режимов рендеринга в Nuxt 3

Nuxt 3 поддерживает несколько стратегий рендеринга, которые можно применять как глобально, так и для отдельных маршрутов через routeRules. Это позволяет строить гибридные приложения, где одни страницы статичны, другие серверно рендерятся, а третьи обновляются по расписанию.

SSR — Server-Side Rendering

Каждый запрос обрабатывается сервером: Nitro выполняет Vue-компоненты, генерирует HTML и отдаёт его браузеру. Браузер получает готовый HTML (хорошо для SEO и TTFB), затем Vue «гидратирует» страницу для интерактивности.

// nuxt.config.ts — SSR включён по умолчанию
export default defineNuxtConfig({
  ssr: true, // можно не указывать, это дефолт
})

Когда использовать: динамические страницы с персонализацией, данными реального времени, аутентификацией.

SSG — Static Site Generation

При сборке Nuxt обходит все маршруты, выполняет SSR для каждого и сохраняет результат как статические HTML-файлы. Итоговый сайт можно хостить на любом CDN без сервера.

# Генерация статики
npx nuxi generate
# Артефакты в .output/public/

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    prerender: {
      routes: ['/sitemap.xml', '/robots.txt'],
      crawlLinks: true, // обходить все ссылки на страницах
    },
  },
})

Когда использовать: маркетинговые сайты, блоги, документация — контент меняется редко.

SPA — Single-Page Application

Сервер отдаёт пустой HTML-шаблон, весь рендеринг происходит в браузере через JavaScript. SEO-преимущества SSR отсутствуют.

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: false, // отключает SSR, включает SPA-режим
})

Когда использовать: внутренние инструменты, дашборды за авторизацией, где SEO не нужен.

ISR — Incremental Static Regeneration

Страница генерируется статически при первом запросе (или при сборке) и кэшируется. Через заданный интервал кэш инвалидируется и страница перегенерируется на следующий запрос. Это гибрид SSG (скорость) и SSR (актуальность данных).

// nuxt.config.ts — ISR через routeRules
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': {
      isr: 60 * 60, // перегенерировать раз в час (в секундах)
    },
    '/news': {
      isr: true, // перегенерировать при каждом запросе после инвалидации
    },
  },
})

Когда использовать: блог, каталог товаров — контент меняется редко, но нужна актуальность.

Гибридный режим с routeRules

Это главное преимущество Nuxt 3 — разные маршруты одного приложения могут использовать разные стратегии рендеринга.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    // Главная — ISR, обновляется раз в 10 минут
    '/': { isr: 600 },

    // Блог — статические страницы, пресгенерируются
    '/blog/**': { prerender: true },

    // API — не кэшируется, всегда свежее
    '/api/**': { cache: false },

    // Дашборд — только клиент (SPA), нет SSR
    '/dashboard/**': { ssr: false },

    // Документация — кэш на CDN на 1 час
    '/docs/**': { cache: { maxAge: 3600 } },

    // Редирект
    '/old-page': { redirect: '/new-page' },
  },
})

Сравнительная таблица

• SSR: SEO хорошо, TTFB средний, требует сервер, данные всегда свежие.
• SSG: SEO отлично, TTFB отличный, не требует сервер, данные при сборке.
• SPA: SEO плохо, TTFB плохой, не требует сервер, данные в браузере.
• ISR: SEO отлично, TTFB отличный, требует сервер, данные периодически обновляются.

Подводные камни

• ISR не поддерживается на всех платформах — ISR работает только там, где Nitro может кэшировать ответы на сервере; Cloudflare Pages в базовом варианте не поддерживает ISR.
• SSG и динамические данные — при nuxi generate данные «замораживаются» на момент сборки; для динамического контента нужны ISR или клиентский data fetching после гидратации.
• routeRules.ssr: false не то же самое что глобальный SPA — при глобальном ssr: false серверные API-маршруты всё равно работают; отдельный routeRules отключает SSR только для рендеринга страниц.
• Кэш ISR не инвалидируется по событию — по умолчанию ISR кэш живёт по времени; для инвалидации по событию (изменение данных в CMS) нужны вебхуки и ручной вызов event.waitUntil или purge API CDN.
• Смешанные стратегии усложняют деплой — гибридный режим с SSR + prerender требует запущенного сервера; деплой на чисто статический хостинг (GitHub Pages) невозможен.
• useFetch и prerender — при пресгенерации Nuxt выполняет fetch-запросы; если внешний API недоступен во время сборки, страница не сгенерируется и сборка упадёт.

• Путать Nuxt rendering modes с похожим API из соседнего фреймворка.
• Не объяснять, где код выполняется: сервер, клиент, build step или runtime.
• Игнорировать влияние на hydration, cache, bundle size или безопасность.

• Точно объясняет назначение механизма «Nuxt rendering modes».
• Показывает корректный минимальный пример без выдуманных API.
• Называет ограничения, failure modes и production-компромиссы.