SpiritCode.blog

Next.js App Router TTFB: How I Fixed a 4-Second Response Time

Next.js App Router TTFB: How I Fixed a 4-Second Response Time

Meta description: I spent weeks diagnosing a 4-second TTFB on a Next.js App Router project. Here’s exactly how I fixed it — from cold starts to streaming and caching.

Last updated: May 2026

A few months ago, a client called me frustrated. Their Next.js App Router app was loading painfully slowly — Lighthouse was screaming about a 4.2-second Time to First Byte (TTFB), and Google Search Console was flagging their Core Web Vitals as “Poor.” The app was using Server Components and a handful of async fetches inside layouts. Everything looked fine on paper. But in production, it was a disaster.

That debugging session taught me more about Next.js App Router internals than any documentation ever did. In this article, I’ll walk you through every fix I applied, in the exact order I found them — with real commands, real error messages, and real performance numbers.

TL;DR

  • Waterfall data fetching inside layouts is the #1 culprit for slow TTFB in App Router — parallelize everything with Promise.all.
  • Wrapping slow sections in <Suspense> lets Next.js stream the shell instantly and defer heavy content.
  • Cold starts on serverless (Vercel, AWS Lambda) can add 800ms–3s — use the Edge Runtime or keep functions warm for critical routes.

Why TTFB Matters in Next.js App Router

Initial Server Response Time (TTFB) is the time between the browser sending a request and receiving the first byte of the HTML response. Google considers anything above 800ms as “Needs Improvement,” and above 1800ms as “Poor.” [SOURCE: https://web.dev/ttfb/]

In the old Pages Router, TTFB was mostly predictable. In the Next.js App Router, the architecture is fundamentally different. Layouts, nested routes, and Server Components all run sequentially by default unless you explicitly wire them otherwise. That’s where most teams get burned.

The React Streaming model in App Router is incredibly powerful — but it requires intentional architecture. If you don’t structure your fetches correctly, you’re essentially building a waterfall that blocks the entire response.

Prerequisites

Before diving in, make sure you’re working with:

  • Next.js 13.4 or later (App Router stable)
  • Node.js 18+
  • Basic understanding of React Server Components and async/await
  • Access to your deployment logs (Vercel, AWS, or self-hosted)

If you’re still on the Pages Router, some of these tips still apply — but the streaming and layout-level fixes are App Router–specific.

Step-by-Step: How I Fixed TTFB in a Real Production App

With the groundwork covered, here’s the exact sequence I followed — from diagnosis to infrastructure-level fixes.

Step 1: Measure First — Use the Right Tools

Before touching a single line of code, I added proper observability. Guessing at performance is a trap.

# Install @vercel/speed-insights for real-user monitoring
npm install @vercel/speed-insights

Then in your root layout.tsx:

import { SpeedInsights } from '@vercel/speed-insights/next';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <SpeedInsights />
      </body>
    </html>
  );
}

I also used next/headers timing logs and Vercel’s Function Logs to pinpoint exactly which route was slow. Without this step, I would have optimized the wrong thing. Every second I saved was based on measured data, not gut feeling.

Step 2: Kill the Data Fetching Waterfall

This was the single biggest win. My original layout looked like this:

// ❌ WRONG — sequential fetches, each waits for the previous
export default async function DashboardLayout({ children }) {
  const user = await getUser();
  const settings = await getSettings(user.id);
  const notifications = await getNotifications(user.id);

  return (
    <div>
      <Sidebar user={user} settings={settings} notifications={notifications} />
      {children}
    </div>
  );
}

Each await was blocking the next one. Three database calls in sequence totaling ~1.8 seconds — just in the layout, before any page content rendered.

The fix — parallelize independent fetches using Promise.all:

// ✅ CORRECT — all fetches fire simultaneously
export default async function DashboardLayout({ children }) {
  const [user, settings, notifications] = await Promise.all([
    getUser(),
    getSettings(),
    getNotifications(),
  ]);

  return (
    <div>
      <Sidebar user={user} settings={settings} notifications={notifications} />
      {children}
    </div>
  );
}

This dropped my layout response time from 1.8s to ~620ms. The getSettings and getNotifications calls didn’t depend on user.id in this specific case — I had just written them that way out of habit.

Pro Tip: Always ask “does fetch B actually need the result of fetch A?” before chaining awaits. In my experience, 70% of the time the answer is no.

Step 3: Add Suspense Boundaries for Streaming

Even with parallelized fetches, some components are genuinely slow — think third-party API calls, heavy database aggregations, or personalized data that can’t be cached.

For those, React Suspense + Next.js Streaming is the answer. Instead of blocking the entire page response, Next.js sends the HTML shell immediately and streams in slow sections as they resolve.

// app/dashboard/page.tsx
import { Suspense } from 'react';
import { AnalyticsSkeleton } from '@/components/skeletons';

export default function DashboardPage() {
  return (
    <main>
      <h1>Dashboard</h1>

      {/* This renders instantly */}
      <QuickStats />

      {/* This streams in when ready */}
      <Suspense fallback={<AnalyticsSkeleton />}>
        <SlowAnalyticsWidget />
      </Suspense>
    </main>
  );
}
// SlowAnalyticsWidget.tsx — this is a Server Component
async function SlowAnalyticsWidget() {
  const data = await fetchAnalyticsFromSlowAPI(); // ~2s
  return <Chart data={data} />;
}

The key insight: the browser receives the <h1> and <QuickStats /> HTML almost instantly. The <SlowAnalyticsWidget /> streams in 2 seconds later. TTFB drops, and the user sees meaningful content immediately.

[INTERNAL LINK: related article on React Suspense patterns in production]

Step 4: Configure Route-Level Caching in Next.js App Router

Next.js App Router has a layered caching system that many developers accidentally bypass. I was making fetch() calls without any cache config, which meant every request hit my database fresh.

// ❌ Bypasses all caching
const data = await fetch('https://api.example.com/products');

// ✅ Cache for 60 seconds (revalidate on ISR-style timing)
const data = await fetch('https://api.example.com/products', {
  next: { revalidate: 60 },
});

// ✅ Or use tags for on-demand revalidation
const data = await fetch('https://api.example.com/products', {
  next: { tags: ['products'] },
});

For data that never changes (config, translations), use force-cache:

const config = await fetch('https://api.example.com/config', {
  cache: 'force-cache',
});

This alone reduced my average TTFB by ~400ms on product listing pages. [SOURCE: https://nextjs.org/docs/app/building-your-application/caching]

Step 5: Address Cold Starts on Serverless

After fixing the code-level issues, I was still seeing occasional spikes to 3–4 seconds. The culprit: serverless cold starts.

On Vercel’s Edge Runtime, cold starts are nearly eliminated. Switching my authentication-check middleware from Node.js runtime to Edge Runtime was a quick win:

// middleware.ts
export const config = {
  matcher: ['/dashboard/:path*'],
  runtime: 'edge', // ✅ Near-zero cold start
};

For routes that must use Node.js runtime (e.g., they need fs or native modules), I used Vercel’s Fluid compute setting and added a keep-warm ping via a cron job:

# vercel.json
{
  "crons": [
    {
      "path": "/api/keep-warm",
      "schedule": "*/5 * * * *"
    }
  ]
}

Important: The Edge Runtime doesn’t support all Node.js APIs. Always check compatibility before migrating — I hit a wall when trying to use crypto.createHmac(), which required switching to the Web Crypto API equivalent.

Step 6: Optimize Database Queries and Connection Pooling

The final layer I fixed was the database itself. I was using Prisma with a PostgreSQL connection on every serverless invocation — which was creating a new connection on each cold request.

# Switch to a connection pooler like PgBouncer or Neon's built-in pooling
DATABASE_URL="postgresql://user:pass@neon-pooler.host/db?pgbouncer=true&connection_limit=1"

For Prisma specifically, add this to your schema:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

This pattern — using a pooled URL for queries and a direct URL for migrations — dropped my cold-start DB connection time from ~800ms to under 50ms.

Real-World Tips I Use in Production

  • Never put slow fetches in RootLayout — they block every single page. Move them down the tree or into the specific page that needs them.
  • Use generateStaticParams + revalidate for pages with predictable URL shapes (product slugs, blog posts) — they pre-render at build time and serve instantly.
  • Instrument with OpenTelemetry if you’re self-hosting — Vercel’s built-in tracing doesn’t help you there.

Common Errors I Fixed Along the Way

Error: “Dynamic server usage: headers” breaking static optimization

Error: Dynamic server usage: headers
  This route cannot be rendered statically because it used `headers`

This happened when I accidentally called headers() inside a component that Next.js expected to be statically rendered. Fix: move the headers() call to a dedicated Server Component and pass the result down as props, or explicitly set export const dynamic = 'force-dynamic' on that route.

Uncached fetch warnings in dev mode

warn - No caching activity was detected. Consider caching fetch requests.

Not an error, but a signal you’re leaving performance on the table. Add next: { revalidate } to your fetches.

FAQ

What Is a Good TTFB Target for a Next.js App Router App in Production?

A: Google’s Core Web Vitals guidelines consider TTFB under 800ms as “Good.” In my production Next.js apps, I target under 500ms for cached routes and under 1200ms for fully dynamic, uncached routes. Streaming with Suspense helps you hit these targets even when some data is slow.

Does Using React Server Components Automatically Improve TTFB in App Router?

A: Not automatically. Server Components reduce the JavaScript sent to the client, which helps Time to Interactive (TTI), but TTFB depends on how fast the server can render and respond. You still need parallelized fetches, good caching, and low-latency data sources.

How Do I Diagnose Which Layout Is Causing Slow TTFB in Next.js?

A: Add console.time() / console.timeEnd() around your async calls in development, then use Vercel’s Function Logs or OpenTelemetry traces in production. The next/dist/server/app-render/app-render.js trace points in Vercel’s dashboard are especially useful for pinpointing layout vs. page render time.

Can Switching to Edge Runtime Always Fix Cold Start TTFB Issues in Next.js?

A: Not always. Edge Runtime is fastest for lightweight logic (auth checks, redirects, geolocation), but it has real limitations — no Node.js built-ins, no native addons, and a 1MB code size limit on Vercel. For data-heavy routes, better caching and connection pooling usually deliver bigger wins.

How Does Next.js Streaming Affect TTFB Scores in Lighthouse?

A: Streaming improves perceived performance and LCP (Largest Contentful Paint), but Lighthouse’s TTFB metric measures the time to the first byte of the HTML response — which is the shell. If your shell is fast, your TTFB score improves even if some streamed components take longer. This is why wrapping slow sections in <Suspense> directly improves your Lighthouse TTFB score.

Conclusion

Slow TTFB in Next.js App Router is almost always a combination of sequential data fetching, missing Suspense boundaries, serverless cold starts, and uncached fetch calls. None of these are hard to fix once you know where to look.

Start by measuring — then tackle the waterfall, add Suspense boundaries, configure caching, and finally address infrastructure-level cold starts. In my project, these steps combined reduced TTFB from 4.2 seconds to under 600ms on cached routes and ~900ms on dynamic ones

About the Author

I’m a full-stack engineer with over 10 years of experience building production web applications, primarily with React, Next.js, Node.js, and PostgreSQL. I’ve worked across early-stage startups and enterprise teams, and I’ve spent the last four years specializing in frontend performance, Core Web Vitals optimization, and serverless architecture. When I’m not debugging cold starts, I’m writing about the real-world lessons that documentation tends to leave out.