How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?

Question

Accepted Answer

Time to First Byte (TTFB) measures the duration between the browser requesting a page and receiving the first byte of response. In SSR-heavy Next.js applications, high TTFB is often caused by server processing time, data fetching latency, or geographic distance. Reducing TTFB requires a multi-layered approach: caching at CDN edge, optimizing database queries and API calls, using streaming to send content progressively, and strategically migrating from SSR to ISR for cacheable content. With Next.js 13+ and modern deployment platforms, you can achieve sub-100ms TTFB even for dynamic pages through these techniques. Implement caching headers with stale-while-revalidate to serve cached responses from CDN edge Use Incremental Static Regeneration (ISR) for pages that don't need per-request freshness Optimize data fetching with parallel requests, database indexing, and connection pooling Leverage streaming SSR with Suspense to send HTML progressively, reducing perceived TTFB Deploy to edge platforms (Vercel Edge, Cloudflare) to minimize geographic latency Prefetch data with middleware or early hints to start processing before page request completes // pages/products/[id].js (Pages Router)
// Add caching headers to SSR responses

export async function getServerSideProps({ params, res }) {
  // Set cache headers to enable CDN caching
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=60, stale-while-revalidate=300'
  );
  
  const product = await fetchProduct(params.id);
  
  return {
    props: { product }
  };
}

// app/products/[id]/page.tsx (App Router with middleware)
// middleware.ts
import { NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const response = NextResponse.next();
  
  // Add caching headers to all product routes
  if (request.nextUrl.pathname.startsWith('/products')) {
    response.headers.set(
      'Cache-Control',
      'public, s-maxage=60, stale-while-revalidate=300'
    );
  }
  
  return response;
}

// Results:
// - First request after cache expiry: 300ms TTFB (origin processing)
// - Subsequent requests within 60s: 20ms TTFB (CDN edge)
// - Requests within stale window (60-360s): 20ms TTFB + background revalidation
// 90%+ reduction in TTFB for repeat visitors If your page doesn't need truly per-request data (e.g., user-specific content), ISR can dramatically reduce TTFB. ISR generates static HTML at build time or on-demand, serving it from CDN edge instantly. Even with revalidation, the first byte comes from cache while regeneration happens in background. For pages that were previously SSR but have cacheable content, this can reduce TTFB from 300-500ms to under 50ms. // Before: SSR - every request hits origin
// pages/blog/[slug].js
export async function getServerSideProps({ params }) {
  const post = await fetchPost(params.slug); // 200ms database query
  return { props: { post } }; // TTFB: ~250ms
}

// After: ISR - cached at edge
// pages/blog/[slug].js
export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);
  return {
    props: { post },
    revalidate: 3600 // Revalidate every hour
  };
}

export async function getStaticPaths() {
  const posts = await fetchAllPosts();
  return {
    paths: posts.map(p => ({ params: { slug: p.slug } })),
    fallback: 'blocking' // Generate on-demand if not pre-rendered
  };
}

// Results:
// - Pre-rendered paths: 30ms TTFB from CDN
// - First visit to new path: 250ms (generation), then cached
// - Subsequent visits: 30ms TTFB
// Average TTFB reduction: 80-90% Parallelize database queries with Promise.all instead of sequential awaits Implement database indexing on frequently queried fields (foreign keys, slugs, timestamps) Use connection pooling to avoid overhead of establishing new database connections per request Consider Redis or Memcached for frequently accessed data to bypass database entirely Create database read replicas to distribute load and reduce contention Use edge-optimized databases like PlanetScale or Turso that are geographically distributed // ❌ Sequential fetches - bad for TTFB
export async function getServerSideProps() {
  const user = await db.user.findUnique(); // 100ms
  const orders = await db.order.findMany({ where: { userId: user.id } }); // 150ms (depends on first)
  const products = await Promise.all(
    orders.map(o => db.product.findUnique({ where: { id: o.productId } })) // 200ms total
  );
  // Total: 450ms before first byte
}

// ✅ Parallel independent fetches
export async function getServerSideProps() {
  const [user, recentOrders, popularProducts] = await Promise.all([
    db.user.findUnique(), // 100ms
    db.order.findMany({ take: 5 }), // 50ms
    db.product.findMany({ where: { popular: true } }) // 80ms
  ]);
  // Total: 100ms (max of parallel operations)
  
  // Handle dependent data after parallel fetches
  const orderDetails = await db.orderDetails.findMany({
    where: { orderId: { in: recentOrders.map(o => o.id) } }

How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?

Reduce TTFB in SSR-heavy Next.js apps by implementing caching strategies, optimizing data fetching, leveraging CDN edge, using streaming SSR, and migrating to ISR where possible

How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?

Reduce TTFB in SSR-heavy Next.js apps by implementing caching strategies, optimizing data fetching, leveraging CDN edge, using streaming SSR, and migrating to ISR where possible

Scenario Questions

Follow-up Questions