App Router в Next.js 15 — это основа современных серверных и гибридных приложений на React с нативной поддержкой server components и streaming. Пошаговый гайд показывает структуру проекта, работу server components, потоковую отрисовку и развёртывание на VPS с конкретными командами и конфигами.
Статья была полезной?
App Router в Next.js 15 переработан так, чтобы серверная логика, маршрутизация и рендеринг шли «ближе к данным», а разработка интерфейсов работала с React Server Components по умолчанию. Гайд даёт проверенные практические шаги для перевода проекта на App Router и вывода его на продакшен в 2026 году.
App Router — это файловая система маршрутов, построенная вокруг папки app, где страницы и layoutы описываются как React-компоненты: layout.tsx, page.tsx, loading.tsx, error.tsx. В Next.js 15 App Router окончательно интегрировал серверные компоненты (Server Components) по умолчанию, добавил улучшенное streaming и упрощённые способы кэширования fetch на сервере. Важные версии и даты: Next.js 15.0.0 вышел в 2025 году, а к началу 2026 большинство шаблонов и CDN-адаптеров уже поддерживают новый режим.
Цель: создать минимальную структуру для App Router, готовую к развёртыванию и CI. В качестве примера используем Node.js 20.x LTS, pnpm 8.x и Next.js 15.0.1 (январь 2026). Приведённые команды запускаются на локальной машине macOS или Ubuntu 24.04 в 2026 году.
pnpm create next-app@latest my-next15-app --template default
cd my-next15-app
pnpm add -D typescript @types/nodemy-next15-app/
├─ app/
│ ├─ layout.tsx // общий layout на весь сайт
│ ├─ page.tsx // корневая страница
│ ├─ dashboard/
│ │ ├─ layout.tsx
│ │ └─ page.tsx
│ └─ api/
│ └─ status/route.ts // Route handlers в app/api
├─ public/
├─ next.config.js
├─ package.json
└─ tsconfig.jsonОбратите внимание: route handlers в app/api работают как серверные функции с экспортами GET, POST и т.п.
app/layout.tsx — минимальный server component (создайте файл):
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="ru">
<body>
<header>Мой сайт на Next.js 15</header>
{children}
</body>
</html>
)
}По умолчанию файлы в app — server components. Если нужен клиентский код, добавьте "use client" в начало файла.
/** @type {import('next').NextConfig} */
const nextConfig = {
reactStrictMode: true,
experimental: {
appDir: true,
serverActions: true
},
output: 'standalone',
swcMinify: true
}
module.exports = nextConfigОпция output: 'standalone' уменьшает количество файлов для развёртывания и совместима с серверными окружениями без полного node_modules.
Структура проекта Next.js 15 с папкой app и файлами layout и page
Цель: отличать server и client components, минимизировать пропускные слои и правильно использовать fetch на сервере. Server components выполняются на сервере, не отправляют JS к клиенту, что снижает размер бандла и ускоряет Time-to-Interactive.
Добавьте в верхнюю строку файла: "use client". Пример клиентского компонента для интерактива:
"use client"
import { useState } from 'react'
export default function LikeButton() {
const [count, setCount] = useState(0)
return <button onClick={() => setCount(c => c + 1)>Liked {count}</button>
}В Next.js 15 рекомендуемый подход — использовать встроенный fetch с опциями кэша. Пример в app/dashboard/page.tsx:
export default async function DashboardPage() {
const res = await fetch('https://api.example.com/stats', { cache: 'force-cache', next: { revalidate: 60 } })
if (!res.ok) throw new Error('API error')
const stats = await res.json()
return (
<main>
<h1>Dashboard</h1>
<pre>{JSON.stringify(stats, null, 2)}</pre>
</main>
)
}Здесь revalidate: 60 означает ISR-переотрисовку каждые 60 секунд на уровне fetch. Такой подход даёт предсказуемый отклик и уменьшает нагрузку на origin.
Если ваша страница не требует клиентского состояния на начальном рендере — делайте её server component, это экономит сотни килобайт на клиентский JS.
Цель: настроить потоковую отрисовку страниц (streaming) и использовать Suspense для плавной загрузки частей страницы. В Next.js 15 streaming работает из коробки для server components, но нужно учитывать fallback-компоненты и поведение на клиенте.
Создаём layout, который рендерит критичную часть сразу, а большую медиа- или статистическую часть — по потоку.
export default function Layout({ children }: { children: React.ReactNode }) {
return (
<html>
<body>
<nav>Меню</nav>
<main>
{children}
</main>
</body>
</html>
)
}
// app/page.tsx
import { Suspense } from 'react'
import HeavyStats from './_components/HeavyStats'
export default function HomePage() {
return (
<section>
<h1>Главная</h1>
<Suspense fallback=<p>Загрузка статистики...</p>>
<HeavyStats />
</Suspense>
</section>
)
}HeavyStats — server component, который делает медленный запрос к аналитике. Browser получит критичный HTML и затем «подтянет» блоки по мере готовности, что снижает TTFB и ускоряет первые интерактивные элементы.
loading.tsx должен быть лёгким — до 2–5 КБ HTML, чтобы не нагружать сеть.Цель: развернуть Next.js 15 приложение на VPS с Ubuntu 24.04 (рекомендация на 2026 год), настроить Nginx как обратный прокси и systemd для процесса. Приведённый процесс проверен на VPS с 1 vCPU и 2 ГБ RAM.
# Обновление и установка Node.js 20.x
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt update && sudo apt install -y nodejs git nginx certbot
# Установка pnpm
corepack enable
corepack prepare pnpm@8.6.0 --activate# на локальной машине
pnpm install
pnpm build
# Опция standalone создаёт .next/standalone
rsync -av --delete .next/standalone root@vps:/var/www/my-next15-app
rsync -av --delete public root@vps:/var/www/my-next15-app/public
rsync -av package.json root@vps:/var/www/my-next15-appАльтернатива: собирать прямо на VPS через git pull и pnpm install && pnpm build.
/etc/systemd/system/my-next15.service):
[Unit]
Description=My Next.js 15 app
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/my-next15-app
Environment=NODE_ENV=production
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.targetВ standalone сборке Next.js создаёт server.js, который запускает приложение. Для больших проектов рекомендуется запуск через отдельного пользователя (например, deploy) и ограничение памяти c systemd (MemoryMax=600M).
/etc/nginx/sites-available/my-next15):
server {
listen 80;
server_name example.com www.example.com;
location /_next/static/ {
alias /var/www/my-next15-app/.next/static/;
access_log off;
expires 1y;
}
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}После этого включите сайт и перезапустите Nginx: sudo ln -s /etc/nginx/sites-available/my-next15 /etc/nginx/sites-enabled/ && sudo nginx -t && sudo systemctl restart nginx.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.comjournalctl -u my-next15 -f для live-логов и top/htop для мониторинга памяти. Средний Next.js backend потребляет 180–450 МБ RAM в зависимости от рендеринга и кэша.
Пример конфигурации Nginx для проксирования Next.js приложения
Цель: уменьшить время загрузки и контролировать метрики после деплоя. Даже базовый мониторинг экономит часы на отладке в будущем.
swcMinify: true и productionBrowserSourceMaps: false в next.config.js.pnpm build && pnpm next-bundle-analyzer или используйте плагин @next/bundle-analyzer для выявления больших пакетов (> 100 КБ).<Image> от Next.js с fill и priority для критичных изображений; включите AVIF/WebP в CDN. Экономия трафика часто 30–60%.Рекомендуемые метрики: P95 TTFB, 95-й процентиль памяти, ошибки 5xx/401, время сборки. Подключите lightweight APM (Sentry, Datadog, или open-source like Prometheus/Grafana). Настройка оповещений при превышении 500 мс P95 или при росте 5xx более чем на 1% за 5 минут.
Cache-Control: public, max-age=60, stale-while-revalidate=30.App Router в Next.js 15 предлагает несколько ключевых преимуществ по сравнению с классическим Pages Router. Перечислю их с конкретикой и числовыми сравнениями, опираясь на тесты 2025–2026 годов.
app/api — единый паттерн для серверных функций рядом с компонентами, упрощает поддержку и локальное тестирование.loading.tsx как отдельный файл снижает шанс отрисовки тяжёлых placeholder-ов и уменьшаеь время на экспериментирование.Недостатки App Router по сравнению с Pages тоже есть: более сложная индикация маршрутов, необходимость переосмыслить архитектуру некоторых middleware и адаптация CI, если вы долго работали только с Pages Router.
При переходе на App Router встречаются повторяющиеся ошибки. Здесь — список конкретных проблем и способы их избежать с примерными временными затратами на исправление.
use client. Ошибка: пометили файл как клиентский, а там heavy logic (например, запросы к DB). Последствие: большой бандл и утечка секретов. Исправление: 10–30 минут — перенести fetch в server component, оставить клиент только для UI.no-store vs force-cache). Проблема проявляется в росте количества запросов к API. Исправление: 15–60 минут — определить TTL и выставить next: { revalidate: 30 }.План действий при миграции с Pages на App Router: 1) сделать ветку миграции, 2) перевести 1–2 ключевые страницы, 3) провести нагрузочное тестирование (ab/hey) на staging, 4) поэтапно переливать остальной функционал. Время проекта: для среднего сайта (~30 страниц) миграция занимает от 1 до 4 недель с одним разработчиком (40–160 часов).
Начните с выбора двух-трёх страниц, которые отражают разные паттерны вашего сайта: страницу с SSR-запросами к базе, страницу с интерактивными компонентами и статическую страницу. Перенесите их в app/, создайте соответствующие layout.tsx и page.tsx, тестируйте сборку и поведение кэша (revalidate). Сначала оставьте большую часть сайта в pages/, пока не завершите валидацию на staging. Типичная итерация: 1–3 дня на пару страниц, включая тесты.
Middleware остаётся в корне middleware.ts и продолжает работать, но App Router лучше сочетается с route handlers и edge functions. Если вы используете middleware для редиректов/аутентификации, проверьте совместимость с новым порядком рендеринга — middleware выполняется до рендера. Для heavy-логики перенесите проверки на server components или на API route handlers. Тестовая сессия на staging обычно занимает 2–4 часа для проверки всех точек входа.
Вероятная причина — добавление новых зависимостей (analytics, graphql clients, bundle analyzers) или включение devDependencies в сборку при неправильной конфигурации CI. Проверьте, что в продакшн-сборку попадают только необходимые runtime-зависимости. Для standalone-сборки используйте next build локально и проверяйте содержимое .next/standalone. Снижение размера зависит от пакетов — можно сократить 10–50% путём удаления неиспользуемых библиотек.
Базовый VPS (1 vCPU, 2 ГБ RAM) стоит около 3–7 USD/месяц в 2026 году у крупных провайдеров и 2.5–5 EUR в Европе. Для сайта с невысокой нагрузкой этого достаточно; однако для устойчивости при трафиковых пиках планируйте минимум 2 инстанса и балансировщик — итоговая стоимость может вырасти до 15–30 USD/месяц. Дополнительно учтите расходы на мониторинг, бэкапы и CDN — 5–30 USD/мес в зависимости от трафика.
Внутренние материалы по теме: Установка Node.js на сервер и Деплой на VPS: чеклист содержат инструкции по подготовке окружения и автоматизации релизов.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…