Next.js 16.2: От основ до профессиональной архитектуры

Фундамент Next.js и React: Серверные компоненты, гидратация и границы ответственности

Добро пожаловать в курс «Next.js 16.2: От основ до профессиональной архитектуры». Мы начинаем наше погружение не с написания кода «вслепую», а с понимания фундаментальных принципов, на которых строится современный веб.

Next.js версии 16.2 — это не просто фреймворк поверх React. Это полноценная архитектурная платформа, которая меняет подход к тому, как мы думаем о рендеринге, маршрутизации и взаимодействии с данными. Если у вас уже есть опыт работы с React или старыми версиями Next.js, приготовьтесь: правила игры изменились, и изменились к лучшему.

В этой статье мы разберем три кита современной разработки на Next.js:

React Server Components (RSC) — почему код теперь выполняется на сервере по умолчанию.

Гидратация — как статический HTML оживает в браузере.

Маршрутизация и файловая система — как работают папки, файлы и те самые «квадратные скобки».

React и Next.js: Единое целое

Раньше React был библиотекой исключительно для клиента (браузера). Вы отправляли пустой HTML, загружали огромный JavaScript-файл, и только потом пользователь видел контент. Next.js решал эту проблему через SSR (Server-Side Rendering), но это было скорее надстройкой.

С приходом архитектуры App Router (которая является стандартом в Next.js 16.2), React и Next.js слились в единую экосистему. Теперь React — это библиотека, которая умеет работать и на сервере, и на клиенте, а Next.js — это «клей», который делает это переключение бесшовным.

Серверные компоненты (RSC): Новый стандарт

Главное, что нужно запомнить: в Next.js (App Router) все компоненты по умолчанию являются Серверными (Server Components).

Что это значит?

Когда вы создаете обычный компонент:

Этот код никогда не попадет в браузер пользователя. Он выполнится на сервере, сходит в базу данных, сгенерирует HTML и отправит клиенту только результат.

Преимущества Серверных компонентов: * Безопасность: Вы можете писать запросы к БД прямо в компоненте, не боясь утечки токенов или паролей. * Скорость: Код библиотек для работы с данными (например, ORM) остается на сервере и не увеличивает размер JS-бандла, который скачивает пользователь. * SEO: Поисковики получают полностью готовый HTML.

!Визуализация потока данных от Серверных компонентов к Клиенту, показывающая, что тяжелая логика остается на сервере.

Клиентские компоненты и директива 'use client'

Но веб — это не только статический текст. Нам нужны кнопки, формы, хуки useState и useEffect. Серверные компоненты этого не умеют, так как на сервере нет «клика мыши» или «браузерного хранилища».

Здесь на сцену выходят Клиентские компоненты (Client Components). Чтобы превратить компонент в клиентский, нужно добавить одну строчку в самом верху файла:

Границы ответственности

Важнейший архитектурный навык в Next.js 16.2 — умение правильно проводить границу между сервером и клиентом.

> «Старайтесь оставлять компоненты серверными как можно дольше. Переходите на клиент только тогда, когда вам нужна интерактивность».

Это называется паттерном «Листьев» (Leaf Pattern). Представьте дерево компонентов: ствол и крупные ветки — это серверные компоненты (Layout, Page, Data Fetching), а самые кончики веток (кнопки, инпуты, карусели) — это клиентские компоненты.

Гидратация: Оживление интерфейса

Понятие «Гидратация» (Hydration) часто пугает новичков, но суть его проста.

Представьте, что сервер отправляет вам «сухой» HTML. Он выглядит как готовая страница: есть текст, кнопки, картинки. Но если вы нажмете на кнопку, ничего не произойдет, потому что JavaScript еще не подключен.

Гидратация — это процесс, когда React в браузере «проходится» по этому сухому HTML и «поливает» его JavaScript-ом, прикрепляя обработчики событий (onClick, onChange). После этого страница становится интерактивной.

В Next.js гидратация происходит частично. Серверные компоненты приходят как чистый HTML и не требуют гидратации (им не нужен JS). Гидратируются только те «островки», которые вы помечетили как 'use client'.

Архитектура маршрутизации: Файловая система

Next.js использует файловую систему для создания URL-адресов. Это значит, что структура папок в директории app напрямую отражает структуру вашего сайта.

Основные файлы

В каждой папке маршрута могут лежать специальные файлы:

* page.tsx — сам контент страницы (UI), доступный по этому адресу. * layout.tsx — обертка для страницы и всех вложенных страниц (шапка, подвал, боковое меню). Layout не перерисовывается при навигации между вложенными страницами. * loading.tsx — компонент, который показывается, пока грузится page.tsx. * error.tsx — компонент для обработки ошибок.

Динамические маршруты: Магия квадратных скобок

Вы спрашивали про скобки — это один из самых мощных инструментов Next.js. Часто нам нужно создать страницы не для фиксированного адреса (как /about), а для динамического (например, профиль пользователя или карточка товара).

#### 1. Одинарные квадратные скобки [slug]

Если вы создадите папку app/blog/[id]/page.tsx, то этот файл будет отвечать за любые адреса, подходящие под шаблон /blog/*.

Примеры URL: * /blog/1 * /blog/my-first-post * /blog/react-tutorial

Как получить значение id внутри компонента? Next.js передает его через params:

#### 2. Catch-all Segments [...slug]

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

Если создать app/docs/[...slug]/page.tsx, он поймает: * /docs/getting-started -> slug будет ['getting-started'] * /docs/components/button -> slug будет ['components', 'button']

#### 3. Optional Catch-all [[...slug]]

Двойные квадратные скобки делают параметр необязательным.

Файл app/shop/[[...category]]/page.tsx сработает для: * /shop/clothes/men (с параметрами) * /shop (вообще без параметров!)

Группировка маршрутов (folder)

Если вы видите папку в круглых скобках, например app/(auth)/login/page.tsx, знайте: круглые скобки не влияют на URL.

Это нужно только для организации кода. * Путь будет: /login (а не /auth/login). * Это позволяет создавать разные layout.tsx для разных групп страниц (например, один Layout для админки, другой для сайта), не меняя структуру URL.

Резюме

Server Components — это база. Используйте их для получения данных и генерации статики. Они не отправляют JS в браузер.

Client Components ('use client') — используйте их точечно, только там, где нужен useState, useEffect или обработчики событий.

Гидратация — процесс оживления HTML на клиенте.

Маршрутизация строится на папках. [id] создает динамический сегмент, а (group) позволяет группировать файлы без изменения URL.

В следующей статье мы перейдем от теории к практике и настроим наше рабочее окружение, создав первый проект на Next.js 16.2 с использованием TypeScript и Tailwind CSS.

Архитектура App Router: Группы маршрутов (), динамические сегменты [] и вложенные макеты

В предыдущей статье мы разобрали фундамент Next.js: серверные компоненты, гидратацию и базовые принципы рендеринга. Теперь пришло время построить стены нашего приложения. В Next.js 16.2 архитектура приложения неразрывно связана с файловой системой. То, как вы называете папки и файлы, определяет не только URL-адреса, но и иерархию макетов (Layouts), обработку ошибок и загрузку данных.

Сегодня мы углубимся в «магию» специальных символов в названиях папок: квадратных скобок [] и круглых скобок (). Мы также разберем концепцию вложенных макетов, которая позволяет создавать сложные интерфейсы профессионального уровня.

Динамические сегменты: Квадратные скобки []

В реальных приложениях мы редко знаем все URL-адреса заранее. У нас есть товары, пользователи, статьи блога — у каждого из них свой уникальный идентификатор (ID) или человекочитаемый адрес (slug). Для обработки таких случаев Next.js использует динамические сегменты.

Одинарные сегменты [slug]

Создавая папку с именем в квадратных скобках, например app/products/[id], вы сообщаете роутеру: «Сюда может прийти любое значение, и я хочу получить его как параметр».

Путь app/products/[id]/page.tsx будет соответствовать: * /products/1 * /products/sneakers * /products/abc-123

Как получить доступ к параметру?

В Next.js 16 (и начиная с версии 15) произошли важные изменения. Свойство params теперь является асинхронным (Promise). Это сделано для оптимизации и подготовки к будущим возможностям частичного пререндеринга.

Catch-all Segments [...slug]

Иногда нужно захватить не один сегмент пути, а всю оставшуюся часть URL. Для этого внутри скобок добавляется троеточие.

Папка app/docs/[...slug] будет соответствовать: * /docs/installation -> slug будет ['installation'] * /docs/components/button -> slug будет ['components', 'button']

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

Optional Catch-all [[...slug]]

Двойные квадратные скобки делают параметр необязательным.

Разница между [...slug] и [[...slug]]: * app/shop/[...slug] НЕ сработает для адреса /shop (вернет 404). * app/shop/[[...slug]] СРАБОТАЕТ для адреса /shop (параметр slug будет undefined).

Группы маршрутов: Круглые скобки ()

Одна из самых мощных, но часто недопонимаемых функций App Router — это Route Groups.

Обычно папка в app создает сегмент URL. * app/dashboard/page.tsx -> /dashboard

Но что, если мы хотим сгруппировать файлы логически, не меняя URL? Или, что более важно, создать разные макеты (Layouts) для разных частей сайта?

Для этого имя папки оборачивается в круглые скобки: (folderName).

Пример использования

Представьте структуру:

Что здесь происходит?

URL-адреса остаются чистыми: /about, /settings. В них нет слов marketing или dashboard.

Мы смогли создать два совершенно разных корневых макета. Страницы внутри (marketing) будут использовать один дизайн, а страницы внутри (dashboard) — другой.

Это решает старую проблему React-приложений, когда нужно было условно рендерить хедер или футер в зависимости от страницы.

Вложенные макеты (Nested Layouts)

Сила Next.js заключается в иерархии. Макеты (layout.tsx) вкладываются друг в друга как матрешки.

!Визуализация того, как Root Layout оборачивает Dashboard Layout, который в свою очередь оборачивает конкретную страницу.

Как это работает технически?

Каждый layout.tsx принимает проп children. При рендеринге Next.js берет компонент страницы (или вложенного макета) и помещает его внутрь родительского макета.

Рассмотрим пример панели управления:

Root Layout (app/layout.tsx): Содержит теги <html> и <body>. Он общий для всего сайта.

Dashboard Layout (app/dashboard/layout.tsx): Содержит боковую панель навигации (Sidebar), которая должна быть видна на всех страницах админки.

Page (app/dashboard/settings/page.tsx): Конкретный контент настроек.

Преимущество частичного рендеринга

Самое важное свойство вложенных макетов: при навигации между страницами внутри одного макета, сам макет не перерисовывается.

Если пользователь переходит с /dashboard/settings на /dashboard/profile:

Root Layout остается на месте.

Dashboard Layout остается на месте (состояние скролла бокового меню сохраняется!).

Меняется только часть children (контент страницы).

Это обеспечивает высокую производительность и ощущение нативного приложения.

Практический пример архитектуры

Давайте соберем все знания вместе. Допустим, мы делаем образовательную платформу.

Структура папок:

* app/ * layout.tsx (Глобальные стили, шрифты) * (public)/ (Группа для публичных страниц) * layout.tsx (Хедер с кнопкой "Войти", Футер) * page.tsx (Главная) * courses/ * page.tsx (Список курсов) * (app)/ (Группа для приложения) * layout.tsx (Сайдбар, проверка авторизации) * dashboard/ * page.tsx * learn/ * [courseId]/ (Динамический сегмент курса) * layout.tsx (Меню уроков конкретного курса) * [lessonId]/ (Динамический сегмент урока) * page.tsx (Видео и текст урока)

В этом примере:

Мы разделили публичную часть и приложение через ().

Мы используем [courseId] и [lessonId] для навигации по контенту.

Внутри learn/[courseId] есть свой layout.tsx, который покажет список уроков именно этого курса. При переключении между уроками ([lessonId]) список уроков слева не будет мерцать или перезагружаться.

Резюме

[slug] — создает динамические маршруты. Параметры теперь нужно получать через await params.

[...slug] — захватывает все последующие сегменты пути.

(group) — организует код и позволяет создавать разные корневые макеты, не влияя на URL.

Вложенные макеты — позволяют переиспользовать UI (например, сайдбары) и сохранять их состояние при навигации.

Понимание этих паттернов — ключ к созданию масштабируемых приложений на Next.js. В следующей статье мы поговорим о том, как наполнять эти страницы данными, используя мощь серверных компонентов и Fetch API.

Управление данными: Server Actions, глубокое кэширование и мутации без API-слоя

Мы уже построили фундамент на Серверных компонентах и возвели стены с помощью App Router. Теперь пришло время провести электричество и водопровод — заставить наше приложение работать с данными.

В традиционном React-приложении (или в старых версиях Next.js) взаимодействие с данными выглядело как сложный танец: вы создавали API-роут (pages/api/handler.ts), затем на клиенте писали fetch, обрабатывали isLoading, error, и data через useEffect или сторонние библиотеки вроде React Query. Это создавало огромный слой «клея» между базой данных и кнопкой «Сохранить».

Next.js 16.2 предлагает радикально иной подход. Забудьте о ручном создании API-эндпоинтов для каждой мелочи. Встречайте Server Actions.

В этой статье мы разберем:

Server Actions: Как вызывать серверные функции прямо из кнопок и форм.

Мутации без API: Почему вам больше не нужны папки api для CRUD-операций.

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

Что такое Server Actions?

Server Actions (Серверные действия) — это асинхронные функции, которые выполняются на сервере, но могут быть вызваны из Клиентских или Серверных компонентов.

Технически, когда вы вызываете такую функцию, Next.js делает POST-запрос к самому себе, выполняет код функции, и возвращает результат. Но для вас, как разработчика, это выглядит как вызов обычной JavaScript-функции.

Как создать Server Action?

Ключевой момент — директива 'use server'. Она сообщает компилятору, что эта функция должна остаться на сервере и быть доступной извне.

!Схематичное изображение прямого вызова серверной функции из клиентского интерфейса

Рассмотрим пример создания задачи (Todo):

Теперь используем это действие в компоненте:

Что здесь произошло? * Мы не писали fetch('/api/todos', { method: 'POST' ... }). * Мы не обрабатывали event.preventDefault(). * Этот код работает даже без JavaScript в браузере (благодаря нативной работе HTML-форм), что является вершиной прогрессивного улучшения.

Мутации без API-слоя

В архитектуре Next.js 16.2 понятие «API-слой» становится размытым. Раньше вы обязаны были сериализовать данные в JSON, отправлять их по сети и парсить обратно.

С Server Actions вы работаете с данными напрямую. Вы можете импортировать ORM (Prisma, Drizzle, Mongoose) прямо в файл с экшеном.

Безопасность — это ваша ответственность

Поскольку Server Actions — это публичные эндпоинты (под капотом), вы обязаны валидировать данные и проверять права доступа внутри функции.

Глубокое кэширование и Ревалидация

Одна из самых сложных тем в веб-разработке — инвалидация кэша. Как обновить список задач на экране после того, как мы добавили новую задачу?

В старом React вы бы сделали новый fetch или обновили локальный стейт. В Next.js 16.2 используется механизм Smart Caching.

Data Cache

По умолчанию Next.js агрессивно кэширует данные, полученные в серверных компонентах. Если вы загрузили список задач, Next.js запомнит готовый HTML или JSON-пейлоад.

Когда вы выполняете Server Action (мутацию), вы должны явно сказать Next.js: «Данные изменились, перестрой страницу».

revalidatePath

Функция revalidatePath('/path') — это команда серверу удалить кэш для конкретного пути и запросить свежие данные при следующем рендере.

В примере выше:

Пользователь нажимает «Добавить».

createTodo добавляет запись в БД.

revalidatePath('/todos') помечает кэш страницы /todos как устаревший.

Next.js автоматически делает повторный рендер серверного компонента страницы /todos с новыми данными и отправляет обновленный UI клиенту.

Все это происходит за один сетевой цикл (Round Trip). Вам не нужно вручную обновлять состояние списка на клиенте!

revalidateTag

Для более точечного управления кэшем можно использовать теги.

При получении данных:

В Server Action:

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

Улучшение UX: useActionState и useFormStatus

Server Actions работают асинхронно. Пользователю нужно показывать индикаторы загрузки или сообщения об ошибках. Для этого в React (и Next.js 16) появились специальные хуки.

useFormStatus

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

> Важно: useFormStatus должен использоваться внутри компонента, который находится внутри <form>. Он не сработает в том же компоненте, где объявлена сама форма.

useActionState

Раньше этот хук назывался useFormState. Он позволяет управлять состоянием ответа от Server Action (например, ошибками валидации).

Резюме

Next.js 16.2 стирает границы между клиентом и сервером, делая работу с данными интуитивной и мощной.

Server Actions ('use server') позволяют вызывать серверные функции прямо из UI, устраняя необходимость в создании REST API для внутренних нужд.

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

Ревалидация (revalidatePath) — это механизм, который связывает мутации с обновлением интерфейса, автоматически обновляя кэш и перерисовывая данные.

Хуки useActionState и useFormStatus обеспечивают отличный UX, управляя состояниями загрузки и ошибок.

В следующей статье мы рассмотрим продвинутые паттерны оптимизации: стриминг, Suspense и частичный пререндеринг (PPR), чтобы сделать наши приложения молниеносными.

Продвинутые UI-паттерны: Параллельные маршруты, перехват навигации и стриминг контента

Мы прошли долгий путь: от понимания серверных компонентов до создания мутаций данных без API. Теперь у нас есть надежный фундамент и работающий «двигатель» приложения. Но что делает приложение по-настоящему профессиональным? Это User Experience (UX).

В Next.js 16.2 UX — это не просто красивые анимации. Это архитектурные решения, которые позволяют интерфейсу быть отзывчивым, загружаться частями и сохранять контекст при навигации. Сегодня мы разберем три самых сложных, но мощных инструмента App Router: Стриминг (Streaming), Параллельные маршруты (Parallel Routes) и Перехват маршрутов (Intercepting Routes).

Эти паттерны позволяют создавать сложные интерфейсы, подобные тем, что вы видите в Instagram, Pinterest или продвинутых дашбордах, используя только файловую систему.

Стриминг: Разрывая оковы водопада

В традиционном SSR (Server-Side Rendering) браузер пользователя вынужден ждать, пока сервер подготовит всю страницу целиком. Если у вас быстрый заголовок, но медленный список товаров, пользователь будет смотреть на белый экран, пока не загрузятся товары.

Стриминг позволяет разбить HTML страницы на мелкие части (чанки) и отправлять их клиенту по мере готовности.

!Визуализация того, как стриминг позволяет пользователю увидеть интерфейс раньше, чем загрузятся все данные.

loading.tsx: Мгновенная обратная связь

Самый простой способ включить стриминг — создать файл loading.tsx в папке маршрута.

Next.js автоматически оборачивает ваш page.tsx в React Suspense. Пока асинхронные данные в page.tsx загружаются, пользователь видит скелетон из loading.tsx. Как только данные готовы, скелетон подменяется реальным контентом.

Suspense: Точечный контроль

Иногда loading.tsx слишком груб — он скрывает всю страницу. Если вы хотите показать заголовок сразу, а загружать только тяжелый график, используйте компонент <Suspense> вручную.

Это критически важно для Core Web Vitals. Вы улучшаете метрику First Contentful Paint (FCP), так как пользователь видит интерфейс почти мгновенно.

Параллельные маршруты (Parallel Routes)

До сих пор мы думали о макете (layout.tsx) как о чем-то, что принимает одну страницу через проп children. Но что, если нам нужно отобразить две, три или четыре независимые страницы на одном экране одновременно?

Представьте сложный дашборд: * Слева — навигация. * По центру сверху — график аналитики (грузится 2 секунды). * По центру снизу — список команды (грузится 0.5 секунды). * Справа — уведомления (грузятся 1 секунду).

Если делать это в одном page.tsx, самая медленная часть затормозит всё. Параллельные маршруты позволяют разделить эти части на независимые слоты.

Синтаксис «Собачки» @

Параллельные маршруты создаются с помощью именованных слотов. Это папки, начинающиеся с символа @.

Структура файлов:

Как это работает в Layout?

Теперь layout.tsx в папке dashboard будет принимать эти слоты как пропсы:

Главное преимущество: Каждый слот (@analytics, @team) может иметь свой собственный loading.tsx и error.tsx. Если аналитика упадет с ошибкой, список команды продолжит работать.

Проблема default.tsx

Это самый частый вопрос новичков. Что произойдет, если вы перейдете на вложенный маршрут, например /dashboard/settings?

Next.js попытается найти контент для слотов @analytics и @team для пути /settings. Но его там нет!

В этом случае Next.js ищет файл default.tsx. Если его нет, вы получите ошибку 404. Поэтому всегда создавайте default.tsx в каждом слоте, если хотите, чтобы он не пропадал или показывал заглушку при навигации.

Перехват маршрутов (Intercepting Routes)

Это, пожалуй, самая «магическая» часть Next.js. Этот паттерн решает классическую проблему веба: контекст против ссылки.

Представьте ленту фотографий (как в Instagram).

Когда вы кликаете на фото из ленты, оно открывается в модальном окне поверх ленты. Вы не теряете место скролла.

Но URL в браузере меняется на /photo/123.

Если вы обновите страницу (F5) или отправите ссылку другу, фото откроется не в модальном окне, а как отдельная полноценная страница.

Это и есть Перехват маршрута. Мы «перехватываем» переход на /photo/123 и показываем другой компонент (модалку), но только если переход был совершен внутри приложения (Soft Navigation).

Синтаксис «Точек» (.)

Синтаксис похож на команды терминала cd ..:

* (.)folder — перехват маршрута на том же уровне. * (..)folder — перехват маршрута на уровень выше. * (..)(..)folder — перехват на два уровня выше. * (...)folder — перехват маршрута из корня app.

!Схема работы перехвата: Soft Navigation ведет в перехватчик, Hard Navigation ведет на оригинальную страницу.

Реализация модального окна

Чтобы сделать модалку, нам нужно объединить Параллельные маршруты (чтобы отобразить окно поверх контента) и Перехват (чтобы изменить URL).

Шаг 1: Создаем слот для модалки

Шаг 2: Добавляем слот в Layout

Шаг 3: Создаем перехватчик

В файле app/@modal/(.)photo/[id]/page.tsx мы создаем компонент, который выглядит как модальное окно (с затемненным фоном).

Когда пользователь на главной странице нажмет <Link href="/photo/1">, Next.js:

Изменит URL на /photo/1.

Вместо того чтобы рендерить app/photo/[id]/page.tsx (полную страницу), он отрендерит app/@modal/(.)photo/[id]/page.tsx внутри слота modal.

Слот children (лента) останется на месте!

Если пользователь нажмет F5, перехват не сработает, и загрузится обычная страница app/photo/[id]/page.tsx.

Резюме

Мы разобрали инструменты, которые превращают обычный сайт в сложное веб-приложение:

Стриминг (loading.tsx, Suspense) — улучшает восприятие скорости, показывая контент частями.

Параллельные маршруты (@folder) — позволяют рендерить несколько независимых страниц в одном Layout. Не забывайте про default.tsx!

Перехват маршрутов ((.)folder) — позволяет показывать контент (например, модалки) поверх текущей страницы при навигации, сохраняя при этом возможность поделиться прямой ссылкой.

Эти паттерны требуют практики, так как они меняют привычное представление о маршрутизации. Но именно они позволяют создавать тот самый «app-like» опыт, за который пользователи любят современные интерфейсы.

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

Оптимизация, Middleware и стратегии деплоя высоконагруженных приложений

Мы прошли большой путь: от понимания того, как React работает на сервере, до создания сложных интерфейсов с параллельными маршрутами и перехватом навигации. Теперь у нас есть функциональное приложение. Но готово ли оно к реальному миру?

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

Оптимизация производительности: Core Web Vitals

Google оценивает сайты не только по контенту, но и по техническим метрикам — Core Web Vitals. Next.js 16.2 предоставляет встроенные инструменты для автоматического улучшения этих показателей.

Компонент Image: Борьба с LCP и CLS

Обычный тег <img> — враг производительности. Он загружает картинку в исходном размере, даже если она отображается как иконка 50x50, и вызывает сдвиг макета (Layout Shift) при загрузке.

Компонент next/image решает эти проблемы автоматически:

Автоматическое изменение размера: Сервер генерирует разные версии изображения для телефона, планшета и десктопа.

Современные форматы: Автоматически конвертирует JPG/PNG в WebP или AVIF, которые весят на 30-50% меньше.

Lazy Loading: Картинки, находящиеся вне экрана, не загружаются, пока пользователь до них не доскроллит.

Резервирование места: Предотвращает сдвиг контента (CLS), так как место под картинку бронируется заранее.

Оптимизация шрифтов: next/font

Шрифты часто блокируют отображение текста или вызывают его мигание (FOIT/FOUT). Модуль next/font (ранее @next/font) позволяет:

* Автоматически скачивать шрифты Google Fonts при сборке. * Хостить их на том же сервере (никаких запросов к Google). * Использовать size-adjust для идеального совпадения с системным шрифтом во время загрузки.

Middleware: Управление трафиком на границе

Middleware — это код, который выполняется до того, как запрос будет обработан кэшем или серверными компонентами. Это идеальное место для проверки авторизации, редиректов, A/B тестирования или геолокации.

!Диаграмма показывает, что Middleware перехватывает запрос самым первым

Особенности Middleware

Middleware работает в среде Edge Runtime. Это урезанная версия Node.js, которая запускается мгновенно и потребляет минимум ресурсов.

> Важно: В Edge Runtime нет доступа к полному API Node.js. Вы не можете подключиться к базе данных напрямую (если драйвер не поддерживает Edge) или использовать файловую систему fs.

Пример: Защита маршрутов

Создайте файл middleware.ts в корне проекта (на одном уровне с app):

Использование matcher критически важно. Без него Middleware будет запускаться на каждый запрос, включая картинки и CSS, что замедлит сайт.

Стратегии деплоя и Docker

Next.js — гибридный фреймворк. Вы можете деплоить его тремя основными способами:

Managed (Vercel): Самый простой путь. Zero-config, автоматический Edge Network, CI/CD из коробки.

Self-Hosted (Node.js): Запуск на собственном VPS или в облаке (AWS, DigitalOcean).

Static Export: Генерация чистого HTML/CSS/JS для хостинга на Nginx или S3.

Docker и Standalone Mode

Для серьезных проектов стандартом является Docker. Next.js имеет специальный режим сборки standalone, который автоматически определяет только необходимые файлы для запуска продакшн-версии, уменьшая размер образа с 1GB+ до ~100MB.

В next.config.mjs включите этот режим:

Пример оптимизированного Dockerfile (упрощенный):

Высокая нагрузка и ISR

Как выдержать 10 000 запросов в секунду, если ваша база данных выдерживает только 100? Ответ: Incremental Static Regeneration (ISR).

ISR позволяет вам отдавать статическую страницу (как обычный HTML), но обновлять её в фоне.

Как это работает?

Первый пользователь получает сгенерированную страницу (очень быстро).

Проходит время revalidate (например, 60 секунд).

Следующий пользователь все еще получает старую (кэшированную) версию (очень быстро).

В фоне Next.js пересобирает страницу с новыми данными.

Как только сборка завершена, кэш обновляется.

Эта стратегия позволяет вашему сайту пережить любой «Хабраэффект» или рекламную кампанию, так как нагрузка на базу данных будет предсказуемой (1 запрос в 60 секунд), независимо от количества пользователей.

Заключение курса

Поздравляю! Вы прошли путь от основ React Server Components до настройки Docker-контейнеров.

Мы изучили: * Как App Router меняет архитектуру приложений. * Как Server Actions упрощают работу с данными. * Как Streaming и Suspense улучшают UX. * Как Middleware и ISR делают приложение быстрым и безопасным.

Next.js 16.2 — это мощный инструмент, который стирает грань между фронтендом и бэкендом. Теперь у вас есть все знания, чтобы строить масштабируемые, быстрые и современные веб-приложения. Удачи в разработке!