<b>App Router ломает старые паттерны Next.js: где чаще всего теряют производительность</b>

<b>App Router ломает старые паттерны Next.js: где чаще всего теряют производительность</b>

App Router удобен, пока не смешать его с привычками из pages router. Типовая ошибка — держать весь экран в client components. В итоге теряются преимущества server rendering, растёт JS на клиенте и усложняется hydration.

Проверь архитектуру так:
— по умолчанию делай компонент server-side;
— client ставь только там, где нужен state, events, browser API;
— данные грузить ближе к серверу, а не через лишний fetch в useEffect;
— тяжёлые интерактивные блоки выносить отдельно, а не размазывать по странице.

Ещё один частый провал — неправильные границы между layout, page и nested routes. Когда общий layout тянет лишние зависимости, весь сегмент становится тяжелее. Если нужен кэш, подумай о том, где уместны isr и где достаточно ssr, а где данные вообще должны жить в edge_compute.

Отдельно следи за error/loading/not-found: в App Router они не декоративные, а часть контракта маршрута. Хорошая схема — минимальный серверный каркас, точечный client слой и чёткие boundaries для ошибок. Тогда nextjs ведёт себя предсказуемо, а vercel не превращает деплой в лотерею.