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

Как Server Components меняют разработку

Server Components выполняются полностью на сервере и отправляют в браузер готовый HTML вместе с компактным описанием структуры для React. JavaScript-код этих компонентов вообще не попадает в клиентский бандл - это главное отличие от обычного подхода. Результат впечатляющий: размер загружаемого кода сокращается на 70%, а начальная загрузка становится заметно быстрее.

Знаете, что особенно удобно? Server Components могут напрямую обращаться к базам данных, файловой системе и внутренним API - всему, что доступно в серверном окружении. Больше не нужно создавать промежуточные API-эндпоинты только для получения данных, которые требуются при рендеринге. Компонент просто берет данные там, где они находятся.

Преимущества Server Components:

• Сокращение объема JavaScript на 70% за счет отсутствия кода компонентов в бандле
• Прямой доступ к защищенным ресурсам (базы данных, файлы, приватные API)
• Лучшая производительность на слабых устройствах благодаря меньшему объему кода
• Оптимизированная начальная загрузка приложения
• Возможность определять загрузку данных на уровне любого компонента

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

Клиентские компоненты никуда не делись - они по-прежнему необходимы для интерактивности. Любой компонент, который требует обработки событий, использования состояния или браузерных API, должен работать в браузере. Главное изменение - теперь разработчик явно выбирает, какие компоненты должны быть клиентскими, добавляя директиву 'use client' в начало файла.

В Next.js 16 по умолчанию все компоненты в App Router являются серверными. Это принципиально отличается от старого подхода и требует переосмысления архитектуры. Вы уже не просто пишете React-компоненты - вы продумываете, где именно должен выполняться код, и выбираете наиболее эффективный вариант.

Когда использовать ‘use client’:

• Компоненты с обработкой событий (onClick, onChange)
• Использование React hooks (useState, useEffect, useContext)
• Доступ к браузерным API (localStorage, navigator, window)
• Чтение данных с помощью useEffect
• Все зависимости таких компонентов остаются в бандле

Архитектурные правила:

• Граница 'use client' должна находиться на самом глубоком уровне дерева компонентов
• Серверные библиотеки (клиенты БД, работа с файлами) не должны импортироваться в клиентских компонентах
• Получение данных происходит в Server Components, а не в useEffect
• Server Actions используются для отправки форм вместо клиентских API-запросов
• Чувствительные данные (ключи API, токены) не передаются пропсами в клиентские компоненты

Turbopack: скорость, которая была нужна

Turbopack стал новым стандартом бундлинга в Next.js 16, заменив Webpack. Производительность - это то, за что борются разработчики фреймворка, и в этот раз результаты впечатляют. Hot Module Replacement работает в 10 раз быстрее, а сборка для production в 4 раза быстрее.

Для разработчиков это означает конкретное удобство: вы меняете код, и изменения появляются в браузере почти мгновенно. Во время разработки это экономит кучу времени, а при работе с большими проектами эффект еще более заметен. Production-сборка, которая раньше могла занять минуты, теперь происходит в считанные секунды.

Что улучшилось с Turbopack:

• HMR (Hot Module Replacement) работает в 10 раз быстрее
• Production-сборки выполняются в 4 раза быстрее
• Меньше времени на ожидание во время разработки
• Масштабируемость для больших проектов
• Встроенная оптимизация для современных машин

React Compiler: автоматическая оптимизация

В Next.js 16 React Compiler достиг стабильности и готов к использованию в production. Это инструмент, который автоматически мемоизирует компоненты и снижает количество ненужных переренdered без каких-либо изменений в вашем коде. Просто включите опцию в конфиге.

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

Есть нюанс: включение React Compiler увеличивает время сборки, так как процесс использует Babel. На данный момент это не включено по умолчанию, так как разработчики Next.js собирают данные о производительности на разных типах приложений.

Как включить React Compiler:

const nextConfig = {
  reactCompiler: true,
};
export default nextConfig;

Server Actions: упрощение работы с формами

Server Actions - это async-функции, которые выполняются на сервере, но можно вызывать из клиентских компонентов как обычные JavaScript-функции. Next.js создает POST-эндпоинт за кулисами и управляет сетевым запросом автоматически. Это означает, что вам не нужно писать отдельные API-маршруты для простых операций.

Это особенно удобно для работы с формами. Вы определяете Server Action прямо в компоненте, передаете его в props action формы, и все работает. Нет необходимости в промежуточном коде - просто функция на сервере, вызываемая из браузера.

Пример простого Server Action:

export default function Page() {
  async function submitFeedback(formData: FormData) {
    'use server';
    const message = formData.get('message') as string;
    await saveFeedback(message);
  }

  return (
    <form action={submitFeedback}>
      <textarea name="message" required />
      <button type="submit">Send Feedback</button>
    </form>
  );
}

Что нужно помнить о Server Actions:

• Они выполняются на сервере, поэтому имеют доступ к защищенным ресурсам
• Аргументы и возвращаемые значения должны быть сериализуемыми (без функций и классов)
• Их нельзя использовать для получения данных - для этого есть Server Components
• Они работают через POST-запросы и не кешируются
• Используйте их для мутаций (создание, обновление, удаление)

Безопасность: о чем нужно знать

Kак и любые серьезные инструменты, Server Components требуют внимания к безопасности. В конце 2025 года была обнаружена критическая уязвимость CVE-2025-55182 (React4Shell) в React Server Components. Она позволяла выполнять произвольный код на сервере без проверки. К счастью, разработчики быстро выпустили патчи.

Уязвимость касалась версий Next.js 14.3.0+ и всех версий 15, 16. Если вы используете эти версии, обновитесь до актуальных патчей: 15.0.5, 15.1.9, 15.2.6 или 16.0.7 и выше.

Уязвимые версии и патчи:

• Next.js 14: начиная с 14.3.0-canary.77
• Next.js 15: все версии (патч: 15.5.7)
• Next.js 16: все версии (патч: 16.0.7)

Как защитить приложение:

• Обновляйте зависимости до последних версий
• Никогда не передавайте чувствительные данные как пропсы в клиентские компоненты
• Используйте Server Actions вместо клиентских API-запросов
• Проверяйте, что библиотеки совместимы с Server Components

Практические рекомендации для разработки

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

Первое - выбирайте библиотеки, совместимые с Server Components. Многие популярные пакеты уже обновлены для поддержки новой архитектуры, но некоторые старые могут работать только в клиентских компонентах. Проверяйте документацию перед интеграцией.

Второе - используйте next/dynamic для динамического импорта тяжелых клиентских компонентов (редакторы rich text, графики, карты). Это гарантирует, что они не будут добавлены в начальный бандл каждой страницы.

Основные правила при разработке:

• Граница 'use client' должна быть как можно глубже в дереве компонентов
• Server Components по умолчанию - клиентские только где нужна интерактивность
• Получение данных в Server Components, не в useEffect
• Используйте Server Actions для отправки форм
• Проверяйте совместимость библиотек с новой архитектурой

Будущее веб-разработки уже здесь

Next.js 16 с полной поддержкой Server Components и Turbopack представляет значительный сдвиг в подходе к веб-разработке. Это не просто обновление фреймворка - это переопределение того, как мы думаем о разделении кода между клиентом и сервером.

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