Next.js 15 App Router — у кого реально ускорился TTFB в проде?

[heckman]

Мигрировали крупный e-commerce (около 400 роутов) с Pages Router на App Router в Next.js 15.2. По синтетике Lighthouse всё отлично, но на реальных пользователях по данным RUM TTFB вырос примерно на 80–120 мс на страницах с тяжёлой выборкой из БД. Такое ощущение, что RSC-стриминг где-то буферизуется сильнее чем в Pages + getServerSideProps. Кто проходил похожее — что смотрели в первую очередь? Ставили ли Cache-Control на уровне Route Handler или что-то с Suspense boundaries?

[juniorphoenix]

У нас похожая история на медиа-проекте. Оказалось что дело было в unstable_cache — он при первом хите после revalidate блокирует рендер до завершения fetcher-функции. Перешли на явный Redis через ioredis с ручным TTL, TTFB дропнул с 350 до 190 мс. Ещё помогло вынести тяжёлые секции в отдельные Suspense boundaries с loading.tsx — пользователь видит шелл быстро, данные догружаются.

[togashi]

@juniorphoenix, Проверьте instrumentation.ts и есть ли у вас opentelemetry-sdk подключённый — он иногда добавляет оверхед на каждый запрос из-за span propagation. Мы убрали его из edge runtime и получили -40 мс только на этом.

[genesi]

Самое частое что вижу у людей — забывают что fetch в RSC по умолчанию кешируется, но если внутри компонента вызывается несколько раз с одним URL — каждый вызов это отдельный entry в cache. Мемоизация через React cache() решает. В доке это написано, но теряется в объёме.

[hogan20]

Мы вообще откатились на Pages Router для критичных по перформансу страниц листинга. App Router оставили для CMS-части, дашбордов, статических маркетинг-страниц — там он хорош. Такой гибридный подход пока держим, Next.js официально поддерживает сосуществование.

[torchchan]

А вы смотрели на Partial Prerendering (PPR)? В 15.x он вышел из experimental в canary и обещает именно этот кейс — статический шелл отдаётся из CDN мгновенно, динамические секции стримятся. На синтетике у нас 50-й перцентиль TTFB упал до 60 мс. Но до прода не катили ещё, страшновато.