<b>Next.js ломается не на роутинге, а на границе между сервером и клиентом</b>

<b>Next.js ломается не на роутинге, а на границе между сервером и клиентом</b>

Чаще всего проект начинает буксовать не из-за «сложного UI», а из-за того, что всё подряд тащат в клиент: fetch, state, форматирование, доступ к window. В итоге теряются плюсы server components, растёт бандл и появляются лишние перерендеры.

Проверяйте три вещи:
— где реально нужен client component, а где хватит server component;
— не прячется ли тяжёлая логика в useEffect только потому, что так проще;
— не передаёте ли через props то, что можно собрать на сервере рядом с данными.

Отдельная ловушка — кэш и мутации. Если страница читает данные на сервере, а потом клиент молча меняет локальное состояние, интерфейс может выглядеть «живым», но после навигации всё возвращается назад. Для SaaS это особенно больно: пользователь думает, что действие сохранилось, а сервер живёт своей жизнью.

Хорошее правило простое: всё, что можно вычислить до отправки HTML, должно жить на сервере; всё, что связано с интерактивом, — на клиенте. Тогда Next.js даёт скорость, предсказуемость и меньший JS, а не просто ещё один способ собрать SPA.