7 типовых мест, где Next.js ломает скорость даже при «нормальном» коде

7 типовых мест, где Next.js ломает скорость даже при «нормальном» коде

Первое — смешение server и client без причины: если пометить клиентом весь экран, вы тащите в браузер и логику, и лишний JS. Второе — тяжёлые провайдеры в корне: тема, auth, i18n, store должны оборачиваться точечно, а не держать весь app tree.

Третье — неверные границы Suspense: один долгий boundary может спрятать быстрые куски и ухудшить perceived performance. Четвёртое — данные без кеш-стратегии: когда каждый переход бьёт в сеть, вы получаете лишние запросы и дерганый UX.

Пятое — изображения без размеров и приоритетов: layout shift вредит сильнее, чем кажется. Шестое — неочевидные редиректы и middleware на каждом заходе: они съедают TTFB и усложняют диагностику. Седьмое — сборка без проверки чанков: иногда один общий util-файл тянет в клиент половину проекта.

Если нужен быстрый аудит, начните с трёх вопросов: что реально должно быть client-side, где можно кешировать, и какой код попал в первый экран. Обычно именно там лежит основной выигрыш.