SpiritCode.blog

Why Is My Next.js App Slow in Production? Fix It Now

Why Is My Next.js App Slow in Production? Fix It Now

description: “I diagnosed a slow Next.js production app and fixed it with image optimization, bundle analysis, and caching. Here’s exactly what changed and why it worked.”

Last updated: June 25, 2026

I shipped a Next.js 13 app for a client last year — everything looked perfect in development. Fast page loads, snappy navigation, zero layout shifts. Then we flipped the switch to production and Lighthouse handed us a score of 41. LCP was sitting at 6.8 seconds. The client was not happy, and neither was I.

The frustrating part? The app was technically fine. It rendered correctly, there were no JavaScript errors, and the API responses were fast. But Next.js performance optimization in production is a different game from what you see in next dev. Webpack compiles differently, caching behaves differently, and if you haven’t explicitly configured things, the defaults will quietly kill your scores.

I spent two days diagnosing and fixing that app. In this post, I’ll walk you through exactly what I found — and how to prevent it from happening to you.

TL;DR

  • Slow Next.js apps in production are almost always caused by oversized bundles, unoptimized images, or missing cache strategies
  • Run @next/bundle-analyzer and Lighthouse CI before deploy — not after
  • Switching to next/image, next/font, and ISR cut my LCP from 6.8s to 1.9s

Why Next.js Performance Optimization Matters in Production

Google’s Core Web Vitals directly impact your search ranking. If your LCP (Largest Contentful Paint) is above 2.5 seconds, you’re already losing organic traffic to competitors. A 1-second delay in mobile response can reduce conversions by up to 20% — I’ve watched this happen in real analytics dashboards, not just in blog stats.

Next.js gives you powerful tools out of the box, but “out of the box” doesn’t mean “optimized by default.” The framework makes smart choices, but it can’t read your mind. Your job is to configure it correctly for production workloads.

This guide focuses on Next.js 13+ with the App Router, but the majority of these optimizations also apply to the Pages Router.

Prerequisites

Before you start, make sure you have:

  • Node.js 18+ installed (Next.js 14 requires it)
  • A Next.js 13+ project using the App Router or Pages Router
  • Access to your Vercel or server deployment logs
  • Lighthouse or PageSpeed Insights to benchmark before and after

Step-by-Step: How I Fixed My Slow Next.js Production App

Step 1: Audit Your Bundle with @next/bundle-analyzer

The first thing I do on any slow Next.js app is run a bundle analysis. Without this step, you’re guessing. Here’s how to set it up:

npm install --save-dev @next/bundle-analyzer

Then update your next.config.js:

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

module.exports = withBundleAnalyzer({
  // your existing config
});

Run the analysis with:

ANALYZE=true npm run build

This opens two interactive treemaps in your browser — one for client bundles, one for server bundles. What I found on my client’s app: a moment.js import (67KB gzipped) buried inside a date-picker component. Replacing it with date-fns dropped the client bundle size by 58KB. That single change moved my FCP by around 400ms.

Pro Tip: Look for packages with a large first-parse cost. Libraries like lodash, moment, and faker are notorious offenders. Use bundlephobia.com to check package sizes before you install.

[SOURCE: https://nextjs.org/docs/app/building-your-application/optimizing/bundle-analyzer]

Step 2: Optimize Images with next/image

Unoptimized images are the number one cause of slow LCP. If you’re using raw <img> tags anywhere, you’re leaving massive image optimization gains on the table.

Here’s what the wrong approach looks like:

// ❌ Don't do this
<img src="/hero-image.jpg" width="1200" height="600" />

Here’s the right approach:

// ✅ Do this instead
import Image from 'next/image';

<Image
  src="/hero-image.jpg"
  alt="Hero banner"
  width={1200}
  height={600}
  priority
  quality={85}
/>

The priority prop tells Next.js to preload the image — critical for LCP because it eliminates the “discovered late” penalty. I missed this on my first pass and was confused why LCP barely improved even after switching to next/image. The quality={85} setting cuts file size by 30–40% with no visible difference on most screens.

One gotcha I hit: remote images from an external CDN require domain whitelisting in next.config.js:

// next.config.js
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cdn.example.com',
      },
    ],
  },
};

Without this, you’ll see: Error: Invalid src prop on next/image, hostname is not configured under images.remotePatterns. That error burned 20 minutes of my life the first time it appeared.

Step 3: Pick the Right Data Fetching Strategy

This is where I see the most Next.js performance mistakes. Developers default to SSR for everything because it feels safe, but SSR means every request hits your server. If your data doesn’t change per-user or per-request, you’re paying for compute you don’t need.

My decision framework:

  • Static data (blog posts, docs, marketing pages) → use SSG with generateStaticParams
  • Data that updates every few minutes → use ISR with revalidate
  • Truly dynamic per-request data (user dashboards, personalized feeds) → use SSR with cache: 'no-store'

For ISR — Incremental Static Regeneration — the setup is minimal:

// app/blog/[slug]/page.js
export const revalidate = 60; // revalidate every 60 seconds

export default async function BlogPost({ params }) {
  const post = await fetchPost(params.slug);
  return <Article post={post} />;
}

On my client’s marketing site, switching from SSR to ISR with a 5-minute revalidation window cut server response times from ~800ms to under 50ms on cached pages. That’s a 16x improvement without touching the application code.

Step 4: Optimize Fonts with next/font

Google Fonts loaded via a standard <link> tag cause a render-blocking request. This is a hidden LCP killer that most developers overlook until they’re deep into a Lighthouse audit.

Replace this:

<!-- ❌ Avoid in your layout -->
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap" rel="stylesheet" />

With this:

// ✅ app/layout.js
import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
});

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

next/font automatically self-hosts the font files, eliminates the external network request, and injects the correct font-display: swap behavior. It also generates unique class names to prevent any FOUT (Flash of Unstyled Text). This is a zero-downside change that takes five minutes.

Step 5: Implement HTTP Caching Headers

Even with ISR, you need proper HTTP caching strategy headers so that CDNs like Vercel Edge, Cloudflare, or AWS CloudFront can serve responses without hitting your origin.

In the App Router, configure this through route handler responses:

// app/api/products/route.js
export async function GET() {
  const products = await fetchProducts();

  return Response.json(products, {
    headers: {
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400',
    },
  });
}

The stale-while-revalidate directive is the key — it tells the CDN to serve the cached response instantly while fetching a fresh copy in the background. This is what makes ISR feel instant to end users.

[SOURCE: https://web.dev/articles/stale-while-revalidate]

Step 6: Lazy Load Heavy Client Components

Not everything needs to be in your initial JavaScript bundle. Heavy UI components like modals, charts, and rich text editors can be loaded on-demand using React Server Components patterns and dynamic imports.

import dynamic from 'next/dynamic';

const RevenueChart = dynamic(() => import('@/components/RevenueChart'), {
  loading: () => <p>Loading chart...</p>,
  ssr: false, // Use for client-only components that need browser APIs
});

I applied this to a dashboard with a recharts visualization. Without lazy loading, recharts (~150KB gzipped) was bundled into the main chunk. After dynamic import, it only loads when the user navigates to the analytics page. Initial load dropped by 1.2 seconds in a 3G simulation.

Real-World Tips I Use in Production

Set up Lighthouse CI in your GitHub Actions pipeline. Catch regressions before they hit production. A bundle that sneaks past code review will get caught if you’re enforcing a Lighthouse performance budget.

Use real-user metrics, not just Lighthouse scores. I’ve had pages score 95 in Lighthouse and tank in real-user data because of third-party scripts loading after hydration. Use web-vitals npm package or Vercel Speed Insights to capture what real users experience.

Audit your third-party scripts. Google Tag Manager, Intercom, and chat widgets routinely add 300–800ms to TTI. Use next/script with strategy="lazyOnload" to defer non-critical scripts:

import Script from 'next/script';

<Script
  src="https://www.googletagmanager.com/gtag/js?id=GTM-XXXX"
  strategy="lazyOnload"
/>

Common Errors I Encountered and Fixed

Module not found: Can't resolve 'fs' in client components This happens when a Node.js-only module gets accidentally imported into a client component. Keep server-only code in Server Components or API routes. Add the 'use client' directive only where truly necessary.

NEXT_REDIRECT swallowed by try/catch In Next.js 14, calling redirect() inside a try block throws internally, and the catch block eats the redirect. Always call redirect() outside your try/catch.

Image with src "/hero.jpg" was detected as the Largest Contentful Paint image This is a helpful warning — it means you forgot priority on your above-the-fold image. Add priority to the <Image> component to fix it.

FAQ

Q: Why is my Next.js app slow in production but fast in development? A: In development, next dev uses Babel with hot reloading and skips most optimizations. In production, the app uses SWC compilation, static optimization, and different caching behavior. Always benchmark with next build && next start locally before comparing to deployed performance numbers.

Q: How do I reduce Next.js bundle size in production? A: Start with @next/bundle-analyzer to identify large dependencies. Replace heavy libraries (moment.js → date-fns, lodash → native ES6 methods), use dynamic imports for non-critical components, and use named imports instead of default imports from large libraries to enable proper tree-shaking.

Q: Does using React Server Components improve Next.js performance? A: Yes — React Server Components run on the server and send zero JavaScript to the client. Moving data fetching and static UI out of client components reduces your JavaScript bundle and eliminates client-side waterfalls. This is one of the biggest App Router performance advantages over the Pages Router.

Q: How often should I revalidate data with ISR in Next.js? A: It depends on how frequently your data changes. Marketing pages can use revalidate = 3600 (1 hour). Blog content might use 300–600 seconds. E-commerce inventory might need 30–60 seconds. Measure the trade-off between data freshness and cache hit rate using your analytics platform.

Q: What’s the best way to monitor Core Web Vitals in a Next.js production app? A: Use the web-vitals npm package with a reportWebVitals function, or enable Vercel Speed Insights if you’re deployed on Vercel. For self-hosted apps, forward CWV metrics to Google Analytics 4 or a custom endpoint to capture real-user monitoring data over time.

Conclusion

Next.js performance optimization isn’t a one-time checklist — it’s an ongoing practice. The six fixes covered here — bundle analysis, image optimization, smart data fetching, font loading, HTTP caching, and lazy loading — account for the majority of wins I’ve seen across dozens of production apps.

Start with the bundle analyzer and Lighthouse, identify your biggest bottleneck, fix it, and measure again. You don’t need to do everything at once. Even one of these changes applied correctly can push a Lighthouse score from the red zone into the green.

About the Author

I’m a senior software engineer with over 8 years of experience building production applications with React, Next.js, and Node.js. I’ve shipped apps for SaaS startups, enterprise clients, and open-source projects, and I’ve spent more hours than I’d like to admit staring at Lighthouse reports trying to squeeze points out of Core Web Vitals. My current stack centers on Next.js 14, TypeScript, Prisma, and Vercel. I write about real problems I hit in production — because that’s the content I wish had existed when I was debugging at 2am.