Первый сайт на Next.js за день: архитектура, а не просто код

На Хабре вышла статья про «первый сайт на Next.js за день». Звучит как реклама курса, но автор хотя бы делает правильную оговорку: большинство таких гайдов заканчиваются тем, что джун копирует код из блога 2022 года, ловит необъяснимый TypeError и двое суток гуглит стек. Разберём, где именно это ломается и что проверить, прежде чем считать проект готовым.

Server Components — не магия, а граница

В App Router page.tsx и layout.tsx по умолчанию — Server Components. Не клиентские. Серверные. Данные можно запрашивать прямо в компоненте, без useEffect и отдельного API-слоя. Браузер получает готовый HTML и RSC-payload. Клиентский бандл не раздувается кодом, который ему вообще не нужен.

Директива 'use client' — это не «настройка React», а архитектурная граница. Всё выше неё в дереве — на сервере, всё ниже — летит в клиент. Правило: начинаете с Server Component, добавляете 'use client' только там, где реально нужны состояние, обработчики событий или browser API. Кто лепит директиву на корневой layout, тот потом удивляется, почему бандл весит как полноценный SPA.

Параметры в Next.js 16 — Promise, и это ломает всё

Старый код не работает. Первое, что нужно проверить, если вы копируете примеры из туториалов 2022–2023 годов.

// Было в Next.js 13–14
export default function Page({ params }: { params: { slug: string } }) {
// Стало в Next.js 16
export default async function InvitePage({ params }: Props) {

params теперь — Promise. Если забыли await, получите сериализованный объект вместо значения и уйдёте в дебаг на полчаса минимум. API менялся между тринадцатой и шестнадцатой версией несколько раз. Копировать вслепую — прямой путь к ситуации «вроде всё на месте, а кернел-паник нет, но и страницы тоже нет».

Что проверить перед next build

Три вещи, которые экономят нервы в пятницу вечером:

ANALYZE=true next build

Смотрите, что именно летит в клиент. Если там оказался серверный код или тяжёлая зависимость вроде moment.js — ищите, где забыли границу. Это типовой костыль, который потом кочует из проекта в проект.

Lighthouse по ключевым маршрутам. «Next.js делает SEO» — популярное, но неточное утверждение. Фреймворк даёт инфраструктуру для SSR и метаданных. Канонические URL, sitemap, robots.txt, og-разметка — это всё ещё ваша работа. Без них SSR просто отдаёт HTML, который никто не найдёт.

Деплой не на localhost. Vercel — путь наименьшего сопротивления, и для портфолио хватит. Но если планируете нормальный прод, проверьте output: 'standalone' и сборку под свой рантайм. Иначе в какой-нибудь деплой-окно обнаружите, что ваш edge-функционал не работает вне Vercel.

И бэкапы. Серьёзно. .next собирается заново за минуту, но если .env.local уехал в публичный репозиторий — ваш прод-секрет уже в архиве, и ни один git filter-branch его оттуда не вытащит без боли. Не надо так.