Режимы рендеринга в Nuxt 4

Nuxt 4 позволяет рендерить одно и то же приложение несколькими способами. Неправильный выбор стратегии может привести к лишней нагрузке на сервер, более медленной первоначальной загрузке, устаревшему контенту или ненужным сложностям с SEO.

Важно понимать, что Nuxt не заставляет весь сайт использовать одну стратегию рендеринга. По умолчанию применяется универсальный рендеринг, но отдельные маршруты можно пререндерить, кэшировать, рендерить по запросу или перевести на клиентский рендеринг с помощью hybrid rendering и routeRules. Edge rendering добавляет ещё один вариант того, где выполняется серверный рендеринг, а не создаёт принципиально новую модель рендеринга. (nuxt.com)

Краткий ответ

По умолчанию Nuxt 4 использует универсальный рендеринг. Nuxt генерирует первоначальный HTML на сервере, отправляет его браузеру, после чего Vue гидратирует этот HTML, делая страницу интерактивной.

Также можно использовать:

• Client-side rendering (CSR) с ssr: false
• Prerendering для генерации HTML во время сборки
• SWR для кэширования отрендеренных ответов и их фонового обновления
• ISR для хранения сгенерированных страниц в поддерживаемых CDN-средах
• Hybrid rendering для комбинирования этих стратегий на уровне отдельных маршрутов

Именно конфигурация routeRules в Nuxt позволяет сочетать эти подходы. (nuxt.com)

Сравнение режимов рендеринга

Таблица упрощает некоторые детали развёртывания, но ключевая идея остаётся важной: для разных URL одного приложения Nuxt оптимальная стратегия рендеринга может отличаться.

Универсальный рендеринг

Универсальный рендеринг — стандартное поведение Nuxt. Параметр конфигурации ssr по умолчанию имеет значение true. (nuxt.com)

Когда пользователь запрашивает страницу:

1. Nuxt выполняет Vue-приложение на сервере.
2. Сервер генерирует HTML.
3. Браузер получает и отображает этот HTML.
4. Загружается клиентский JavaScript.
5. Vue гидратирует существующий HTML и добавляет интерактивность.

Гидратация не означает полную замену страницы, отрендеренной сервером. Vue подключает приложение к уже существующему DOM и добавляет поведение, необходимое для кнопок, изменений состояния, навигации и других интерактивных элементов. (vuejs.org)

Например:

<script setup lang="ts">
const count = ref(0)

function increment() {
  count.value++
}
</script>

<template>
  <button @click="increment">
    Count: {{ count }}
  </button>
</template>

Первоначальная разметка кнопки может быть создана сервером. После гидратации в браузере начинает работать обработка клика.

Универсальный рендеринг особенно хорошо подходит для публичного контента: страниц товаров, блогов, маркетинговых сайтов, маркетплейсов и других страниц, где важно сразу получить готовый HTML. (nuxt.com)

Ограничения гидратации

Поскольку значительная часть приложения выполняется сначала на сервере, а затем снова в браузере, обе среды должны изначально создавать совместимую разметку.

Случайные значения, API, доступные только в браузере, некорректная HTML-структура или вывод, зависящий от часового пояса, могут привести к hydration mismatch — ситуации, когда DOM, ожидаемый клиентом, отличается от HTML, созданного сервером. Vue пытается восстановиться после таких расхождений, но это создаёт дополнительную работу, поэтому их обычно следует избегать. (vuejs.org)

INTERNAL LINK: Несоответствие гидратации в Nuxt

Клиентский рендеринг

Серверный рендеринг HTML можно отключить глобально:

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: false,
})

При клиентском рендеринге браузер получает оболочку приложения, а JavaScript создаёт интерфейс уже в браузере вместо того, чтобы Nuxt формировал содержимое страницы через SSR. (nuxt.com)

Такой подход может быть полезен для:

• авторизованных панелей управления,
• внутренних административных систем,
• высокоинтерактивных инструментов,
• интерфейсов, для которых публичная поисковая индексация не имеет значения.

CSR также устраняет многие проблемы совместимости между сервером и браузером, поскольку рендеринг страницы полностью происходит в браузере.

Компромисс состоит в том, что пользователю может потребоваться сначала загрузить, разобрать и выполнить JavaScript, прежде чем появится основной интерфейс. Поэтому результат сильнее зависит от выполнения JavaScript и производительности устройства пользователя.

CSR и SEO

Неверно утверждать, что Google просто не может индексировать JavaScript-контент, отрендеренный на клиенте.

Google документирует процесс сканирования, рендеринга и индексирования, в котором его Web Rendering Service способен выполнять JavaScript. Однако страницы, где значимый контент появляется только после клиентского выполнения, зависят от этого этапа рендеринга. Google также отмечает, что серверный рендеринг или prerendering остаются полезными для пользователей и поисковых роботов, а не каждый crawler обязательно выполняет JavaScript. (developers.google.com)

Поэтому практическое различие — не в формуле «SSR индексируется, CSR — нет».

Точнее будет сказать:

Контент, отрендеренный на сервере или заранее, уменьшает объём работы, необходимой до появления полезного содержимого страницы в полученном HTML.

INTERNAL LINK: JavaScript SEO — как это работает

Prerendering

Prerendering переносит процесс рендеринга с момента запроса на этап сборки.

Вместо генерации страницы при каждом запросе Nuxt создаёт HTML-файл во время развёртывания, а затем отдаёт уже готовый результат.

Nuxt поддерживает prerendering с помощью таких команд:

npx nuxt generate

или:

npx nuxt build --prerender

Crawler Nuxt для prerendering начинает с доступных ему маршрутов и переходит по ссылкам, чтобы находить дополнительные страницы, которые можно сгенерировать. Маршруты также можно задать явно. (nuxt.com)

Prerendering особенно полезен, когда один и тот же контент можно безопасно показывать всем пользователям до следующего развёртывания. Например:

• страница About,
• документация,
• многие статьи блога,
• лендинги.

Главное ограничение — актуальность данных. Если исходный контент изменится после сборки, сгенерированный HTML сам по себе не обновится, если другой механизм не выполнит его повторную генерацию.

Полностью статическое развёртывание через nuxt generate также не включает работающий Nuxt-сервер, поэтому серверные endpoints приложения не смогут функционировать так же, как при серверном развёртывании. (nuxt.com)

Hybrid rendering

Реальные приложения редко полностью соответствуют модели «всё динамическое» или «всё статическое».

Представим интернет-магазин:

• главная страница: в основном стабильная,
• страницы товаров: периодически обновляются,
• личный кабинет: высокоинтерактивный,
• checkout: персонализированный и динамический,
• блог: меняется время от времени.

Использовать для всех этих маршрутов один и тот же способ рендеринга было бы излишне.

Nuxt решает эту задачу с помощью hybrid rendering и routeRules. Nitro, серверный движок Nuxt, применяет нужное поведение в зависимости от запрошенного маршрута. (nuxt.com)

Например:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },

    '/products/**': {
      swr: 3600,
    },

    '/blog/**': {
      isr: 3600,
    },

    '/admin/**': {
      ssr: false,
    },
  },
})

В таком случае один сайт фактически использует сразу несколько стратегий рендеринга.

Главная страница генерируется во время сборки. Страницы товаров могут кэшироваться и обновляться. Страницы блога могут использовать ISR на совместимых платформах развёртывания. Административный интерфейс работает без SSR как клиентское приложение. (nuxt.com)

Это одно из важнейших архитектурных преимуществ системы рендеринга Nuxt.

SWR и ISR

SWR и ISR тесно связаны, но их не следует автоматически считать разными названиями одного и того же механизма.

SWR

При конфигурации:

'/products/**': {
  swr: 3600,
}

Nuxt может кэшировать отрендеренный ответ на заданное время TTL. После того как кэш устареет, существующий ответ всё ещё может быть отдан пользователю, пока новая версия генерируется в фоне.

Цель — не рендерить одну и ту же ресурсоёмкую страницу при каждом запросе, сохраняя при этом возможность её обновления.

ISR

Например:

'/blog/**': {
  isr: 3600,
}

Nuxt описывает ISR как механизм с похожим поведением повторной генерации, но с интеграцией в CDN-кэш на поддерживаемых платформах. В текущей документации Nuxt по рендерингу для этого поведения routeRules указана поддержка Netlify и Vercel. (nuxt.com)

Поэтому платформа развёртывания имеет значение. Не стоит выбирать ISR только потому, что эта аббревиатура кажется предпочтительнее SWR.

INTERNAL LINK: ISR и SWR в Nuxt

Edge rendering

Edge-side rendering часто относят к режимам рендеринга Nuxt, но сам Nuxt делает важное уточнение: edge rendering правильнее считать целью развёртывания, а не отдельным режимом рендеринга.

Страница по-прежнему рендерится на сервере. Разница в том, что выполнение происходит в edge-среде ближе к пользователю, а не исключительно на одном традиционном origin-сервере. (nuxt.com)

Именно Nitro позволяет приложениям Nuxt работать в различных серверных средах, включая обычные серверы, serverless-платформы и edge runtimes. (nuxt.com)

Edge-развёртывание может сократить сетевое расстояние, но оно не делает любое приложение автоматически быстрее. По-прежнему имеют значение расположение базы данных, API-запросы, ограничения runtime, стратегия кэширования и поведение cold start.

Как выбрать стратегию

Для каждого маршрута полезно задать два вопроса:

Нужен ли этой странице HTML, зависящий от конкретного запроса?

Если нет, prerendering может быть достаточным.

Насколько быстро изменения должны становиться видимыми?

Если контент меняется только вместе с развёртыванием, его можно пререндерить. Если изменения происходят периодически, может подойти кэширование через SWR или ISR. Если страница должна отражать данные каждого отдельного запроса, обычный SSR может быть проще. Если это приватный и высокоинтерактивный интерфейс, разумным вариантом может быть клиентский рендеринг.

Часто это приводит к такой архитектуре:

Marketing pages  → prerender
Blog             → prerender or ISR
Product catalog  → SWR / ISR
Search results   → SSR
User dashboard   → CSR or SSR
Account data     → dynamic server APIs

Нет универсального правила, согласно которому весь проект должен использовать одну стратегию рендеринга.

Частые ошибки

Одна из распространённых ошибок — воспринимать SSR и статическую генерацию как конкурирующие фреймворки. На самом деле это стратегии рендеринга, которые Nuxt умеет комбинировать.

Другая ошибка — глобально включать ssr: false из-за одного компонента, зависящего от браузера. Client-only компонент или настройка конкретного маршрута может решить проблему без перевода всего публичного сайта на CSR.

Обратная ошибка — динамически рендерить каждый запрос, даже если результат меняется редко. В этом случае сервер тратит ресурсы на создание HTML, который можно было сгенерировать или закэшировать один раз.

Наконец, не следует путать edge rendering с prerendering. Пререндеренная страница создаётся до запроса. Edge-rendered страница всё ещё может генерироваться динамически в момент поступления запроса.

Рекомендация SeoNest

Начинайте со стандартного универсального рендеринга Nuxt, если требования приложения не дают чёткой причины выбрать другой подход.

Затем оптимизируйте поведение на уровне маршрутов:

Static enough?      → prerender
Reusable briefly?   → SWR
CDN regeneration?   → ISR where supported
Request-specific?   → SSR
Private app UI?      → consider CSR

После развёртывания измеряйте реальное поведение приложения, а не исходите из предположения, что одна архитектура по определению быстрее другой. Кэширование ответов, объём JavaScript, задержки API, стоимость гидратации, конфигурация CDN и зависимости данных могут быть не менее важны, чем название режима рендеринга.

FAQ

Использует ли Nuxt 4 SSR по умолчанию?

Да. Параметр ssr в Nuxt по умолчанию имеет значение true, а стандартная модель использует универсальный рендеринг. (nuxt.com)

Prerendering — это то же самое, что SSR?

Не совсем. Оба подхода могут создавать HTML до того, как приложение будет отрендерено браузером, но SSR обычно генерирует HTML в ответ на запрос, а prerendering создаёт его во время сборки.

Может ли один сайт на Nuxt использовать несколько режимов?

Да. Hybrid rendering и routeRules позволяют разным маршрутам использовать prerendering, кэширование, SSR или клиентский рендеринг. (nuxt.com)

Мешает ли CSR индексации в Google?

Нет. Google может выполнять JavaScript в процессе рендеринга. Однако HTML, отрендеренный на сервере или заранее, уменьшает зависимость от клиентского выполнения, а возможности других crawler'ов по работе с JavaScript могут отличаться. (developers.google.com)

Edge rendering — это ещё одна форма статической генерации?

Нет. Edge rendering описывает, где происходит серверное выполнение. Статическая генерация описывает, когда создаётся HTML.

Итог

Рендеринг в Nuxt 4 лучше воспринимать как набор инструментов, а не как единственный переключатель между SSR и SPA.

Универсальный рендеринг служит основой по умолчанию. Prerendering убирает ненужную работу во время запроса для стабильных страниц. SWR и ISR позволяют повторно использовать уже сгенерированные ответы, когда контент не нужно создавать заново при каждом запросе. CSR остаётся полезным для частей приложения, ориентированных прежде всего на браузер. Hybrid rendering объединяет эти стратегии, позволяя каждому маршруту использовать подход, соответствующий его реальным требованиям.

Поэтому правильный вопрос — не «Какой режим рендеринга Nuxt лучше?»

А «Что нужно именно этому маршруту?»

Sources

1. Nuxt — Rendering Modes, Nuxt 4 documentation. Primary reference for universal rendering, CSR, hybrid rendering, route rules, SWR, ISR and edge-side rendering. (nuxt.com) Nuxt: Rendering Modes
2. Nuxt — Prerendering, Nuxt 4 documentation. Primary reference for build-time generation and prerender crawling. (nuxt.com) Nuxt: Prerendering
3. Nuxt — Server, Nuxt 4 documentation. Reference for Nitro, universal deployment and hybrid routeRules. (nuxt.com) Nuxt: Server
4. Nuxt — Configuration Reference, Nuxt 4. Reference for the ssr configuration option and its default value. (nuxt.com) Nuxt: Configuration Reference
5. Vue.js — Server-Side Rendering. Reference for Vue SSR, client hydration and hydration mismatches. (vuejs.org) Vue.js: Server-Side Rendering
6. Google Search Central — Understand the JavaScript SEO Basics. Reference for Google's crawling, JavaScript rendering and indexing process. (developers.google.com) Google: JavaScript SEO Basics
7. Google Search Central — Dynamic Rendering as a Workaround. Reference for Google's current preference for SSR, static rendering or hydration rather than dynamic rendering workarounds. (developers.google.com) Google: Dynamic Rendering