Next.js 16 Production — Skipping the Checklist Cost $12,000 in Unused CDN Bandwidth

Production readiness in Next.js 16 is not a feeling — it’s a checklist. We learned this when a client’s launch-day traffic spike caused a 4-hour outage because their database connection pool was too small, their images were unoptimized, and their CDN was revalidating every asset on every request, burning through a $12,000 bandwidth budget in 6 hours.

The problem was not bad code. It was missing configurations: no next.config.js image optimization, no CDN cache headers, no security headers, no load testing, and no error monitoring. Every item on the checklist was a known best practice that got deprioritized in the rush to ship.

This article covers the 10-item production checklist we now enforce for every Next.js deployment. Each item includes a specific configuration change, a verification command, and the real-world failure it prevents. Run through this checklist before every production deployment, and you will never have a launch-day emergency caused by a missing configuration flag.

Item 1: Performance Budgets — The First Thing Before Any Feature Code

A performance budget sets maximum limits for page weight, time-to-interactive, and Lighthouse scores. Without one, performance degrades incrementally with every feature addition. The budget should be: total JavaScript < 300KB (gzipped), total page weight < 1MB, Lighthouse Performance score > 85, and LCP < 2.5 seconds.

Configure the budget in your CI pipeline using Lighthouse CI or a custom script that fails the build if any metric exceeds the threshold. We use Lighthouse CI with a 5% tolerance on the performance score and hard limits on bundle size.

The consequence of skipping this: unmonitored bundle growth. A single third-party library (moment.js, lodash) can add 200KB+ to your bundle without anyone noticing until Lighthouse scores drop from 90 to 60 and organic traffic declines because Google penalizes slow pages.

{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "startServerCommand": "npm run start"
    },
    "assert": {
      "assertions": {
        "performance": ["error", {"minScore": 0.85}],
        "total-byte-weight": ["error", {"maxNumericValue": 1000000}],
        "unused-javascript": ["warn", {"maxNumericValue": 50000}]
      }
    }
  }
}

Item 2: CI Build Caching — Don’t Rebuild node_modules Every Time

Next.js builds can take 5-15 minutes depending on page count and dependency tree. Without proper CI caching, every commit rebuilds everything from scratch. The key caches: node_modules/.cache (next build cache), .next/cache (compilation cache), and node_modules itself (skips npm ci on cache hit).

For GitHub Actions, use actions/cache with specific keys: one for node_modules (hash of package-lock.json) and one for .next/cache (hash of all source files). This reduces build time from 12 minutes to 90 seconds on average.

We learned this when a team member pushed 8 commits in an hour and waited 12 minutes each time for CI. The frustration led to skipping CI checks on minor changes, which eventually led to a broken production deployment.

name: CI
on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Cache node_modules
        uses: actions/cache@v4
        with:
          path: node_modules
          key: modules-${{ hashFiles('package-lock.json') }}

      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: .next/cache
          key: next-${{ hashFiles('app/**/*.{ts,tsx}', 'lib/**/*.ts') }}

      - run: npm ci
      - run: npm run lint
      - run: npm run build

Item 3: Security Headers — Protect Users Before They Arrive

Next.js does not set security headers by default. Your application needs: Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy (strict-origin-when-cross-origin), and Permissions-Policy.

The most important is Content-Security-Policy. Without it, a third-party script vulnerability can exfiltrate user data via XSS. With CSP, even if an attacker injects a script tag, the browser refuses to execute it because the script source is not in the allowed list.

Add these headers via next.config.js using the headers() function. This injects them into every response, including server-rendered pages, API routes, and static files.

const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
  {
    key: 'Content-Security-Policy',
    value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' https:; font-src 'self'; connect-src 'self' https:; frame-ancestors 'none';",
  },
];

const nextConfig = {
  async headers() {
    return [
      { source: '/(.*)', headers: securityHeaders },
    ];
  },
};

Item 4: Error Monitoring — You Can’t Fix What You Can’t See

Next.js 16 swallows server errors by default — they are logged to stdout but never trigger alerts, never appear in APM dashboards, and never reach your error monitoring service unless you explicitly configure it. Sentry, Datadog, or a custom OpenTelemetry pipeline must be configured before production.

The install: npm install @sentry/nextjs then run npx @sentry/wizard -i nextjs to configure. This sets up automatic error tracking for server components, route handlers, server actions, and client-side React error boundaries.

We discovered that our production app had a 3% error rate for two weeks before anyone noticed. The errors were logged to kubectl logs but nowhere else. Sentry would have alerted us within 5 minutes of the first error occurring.

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,
  environment: process.env.NODE_ENV,
});

Item 5: Load Testing — Simulate Traffic Before Real Traffic Arrives

Load testing with k6, artillery, or autocannon reveals bottlenecks before users find them. The minimum viable test: simulate 1,000 concurrent users hitting 5 critical pages (home, search, product, checkout, profile) for 5 minutes. Measure p50/p95/p99 response times, error rates, and throughput.

Key metrics: p95 response time < 500ms, error rate < 0.1%, throughput > 500 req/s, and zero connection timeouts. If any metric fails, the deployment is blocked.

Our launch-day outage was entirely preventable with a 30-minute k6 test. The test would have revealed: CDN cache misses causing 10-second response times (no caching headers), database pool exhaustion at 50 req/s (default pool too small), and image optimization adding 5MB per page load.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '3m', target: 500 },
    { duration: '2m', target: 1000 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.001'],
  },
};

const PAGES = ['/', '/search', '/product/1', '/checkout', '/profile'];

export default function () {
  const page = PAGES[Math.floor(Math.random() * PAGES.length)];
  const res = http.get(`https://staging.example.com${page}`);

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1);
}

Item 6: Image Optimization — The 5MB Page Weight Problem

Next.js’s next/image component provides automatic image optimization, but it must be explicitly configured. Without configuration, images are served at their original resolution and format. A hero image from a CMS might be 4000x3000px at 2MB, served as-is to every user.

Configure next.config.js with: images.formats (include image/avif and image/webp), images.deviceSizes (breakpoints for responsive images), and images.imageSizes (thumbnail sizes). This enables automatic format conversion, resizing, and responsive image generation.

The impact: our average page weight dropped from 5.2MB to 890KB after configuring image optimization. LCP improved from 4.2s to 1.8s. The CDN bandwidth bill dropped 80%.

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [375, 640, 768, 1024, 1280, 1536],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
    remotePatterns: [
      { protocol: 'https', hostname: 'images.ctfassets.net' },
      { protocol: 'https', hostname: 'res.cloudinary.com' },
    ],
  },
};

Item 7: Bundle Analysis — Find the 200KB Library You Forgot About

Bundle analysis reveals exactly which packages contribute to your JavaScript bundle size. The tool: @next/bundle-analyzer. Install it, add the configuration, and run ANALYZE=true next build. It generates an interactive treemap showing every module’s size contribution.

We found a 200KB charting library being imported in a page that didn’t even render charts. Someone had imported it in a shared component and tree-shaking couldn’t eliminate it because it was used conditionally. The bundle analyzer made it obvious in 5 seconds.

The goal: keep the initial bundle under 100KB (gzipped) per page. Use experimental.optimizePackageImports to automatically tree-shake large icon libraries and utility packages.

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

const nextConfig = {
  experimental: {
    optimizePackageImports: [
      'lucide-react',
      'date-fns',
      '@radix-ui/react-icons',
      '@mui/icons-material',
    ],
  },
};

module.exports = withBundleAnalyzer(nextConfig);

Item 8: CDN Caching Headers — The $12,000 Mistake

Without explicit cache headers, most CDNs default to no-cache or short cache durations. Every request to your origin costs money (CDN egress fees) and increases latency. The fix: set aggressive cache headers for static assets and appropriate headers for dynamic content.

The pattern: hashed assets (_next/static/.js, .css, *.png) get Cache-Control: public, max-age=31536000, immutable. These files never change — a new hash means a new file. Non-hashed assets (HTML pages, API responses) get shorter cache durations or private caching.

Our CDN was revalidating every asset on every request because no cache headers were set. The CDN’s default was to treat all responses as uncacheable. Every page load triggered 50+ origin requests for JavaScript, CSS, and images.

async headers() {
  return [
    {
      source: '/_next/static/(.*)',
      headers: [
        { key: 'Cache-Control', value: 'public, max-age=31536000, immutable' },
      ],
    },
    {
      source: '/static/(.*)',
      headers: [
        { key: 'Cache-Control', value: 'public, max-age=31536000, immutable' },
      ],
    },
  ];
},

Item 9: Database Connection Limits — The Silent Bottleneck

Next.js server components and route handlers often share a database connection pool. The default pool sizes are designed for single-process environments. With PM2 clustering or multiple pods, the total connections = workers * pool_size, which can exceed database limits quickly.

The configuration: set pool size to 4-5 per worker, use a connection pooler (PgBouncer) between the app and database, and configure database-side max connections to handle the total (workers * pool_size + 20% headroom).

We defaulted to Prisma’s pool size of 10 connections per process. With 4 PM2 workers, that’s 40 connections. Our Postgres was configured for 25 max connections. When traffic spiked, connections were queued, queries timed out, and every page returned a 500 error.

import { PrismaClient } from '@prisma/client';

const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClient | undefined;
};

const prisma = globalForPrisma.prisma ?? new PrismaClient({
  // Pool size per PM2 worker
  // With 4 workers: 4 * 4 = 16 connections
  log: ['error'],
});

globalForPrisma.prisma = prisma;

export default prisma;

Item 10: Instrumentation and Observability — See Everything Before It Breaks

The final checklist item ties everything together: instrumentation.ts for OpenTelemetry, custom error monitoring (Sentry), request logging (pino), and performance metrics (Lighthouse CI, web vitals).

The minimum viable observability stack: Sentry for error tracking, pino for structured logging, instrumentation.ts for OpenTelemetry tracing, and next/script with useReportWebVitals for client-side performance.

Without instrumentation, you are flying blind. Our production outage was prolonged because the team had no dashboards, no alerts, and no logs to trace the cascade from cache headers to database pool exhaustion. By the time they identified the root cause, the outage had lasted 4 hours.

export async function register() {
  if (process.env.NEXT_RUNTIME === 'edge') return;

  const { NodeSDK } = await import('@opentelemetry/sdk-node');
  const { OTLPTraceExporter } = await import('@opentelemetry/exporter-trace-otlp-proto');
  const { HttpInstrumentation } = await import('@opentelemetry/instrumentation-http');

  const sdk = new NodeSDK({
    traceExporter: new OTLPTraceExporter({
      url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT,
    }),
    instrumentations: [new HttpInstrumentation()],
  });

  sdk.start();
}