Next.js Performance Optimization Guide

A slow website costs you users. Studies show that 53% of mobile visitors leave a page that takes longer than 3 seconds to load. In Next.js, the good news is that most performance wins are built right in — you just need to know how to use them.

This guide walks you through every major optimization technique available in Next.js, with simple explanations and copy-paste code examples. By the end, you'll have a clear action plan to make your app noticeably faster.

---

Why Performance Matters More Than Ever

Google uses Core Web Vitals as a ranking signal. That means a slow site doesn't just frustrate users — it also hurts your search engine visibility.

The three Core Web Vitals you need to care about are:

Metric	What it measures	Good score
LCP (Largest Contentful Paint)	How fast the main content loads	Under 2.5 seconds
FID / INP (Interaction to Next Paint)	How fast the page responds to clicks	Under 200ms
CLS (Cumulative Layout Shift)	How much the page jumps around while loading	Under 0.1

Next.js is built with these in mind. Let's go through each optimization one by one.

---

1. Image Optimization

Images are usually the biggest reason pages load slowly. A single unoptimized hero image can easily be 3–5MB. Next.js solves this with its built-in <Image> component.

What the Next.js Image component does automatically

• Converts images to modern formats like WebP and AVIF (much smaller file sizes)
• Resizes images to match the exact display size — no more sending a 4000px image to a 400px slot
• Lazy loads images by default — only loads images when they're about to appear on screen
• Prevents layout shift by reserving space for the image before it loads

Basic usage

// Always import from 'next/image', never use a plain <img> tag
import Image from 'next/image';

export default function Hero() {
  return (
    <Image
      src="/hero.jpg"
      alt="A developer working on a laptop"  // Always write descriptive alt text
      width={1200}   // The display width in pixels
      height={630}   // The display height in pixels
      priority       // Add this for above-the-fold images so they load first
    />
  );
}

When to use the priority prop

Add priority to any image that appears above the fold (visible without scrolling) — like hero banners, logo images, or profile photos at the top of a page. This tells Next.js to preload the image immediately instead of waiting.

// Hero image — above the fold, use priority
<Image src="/banner.jpg" alt="Banner" width={1200} height={500} priority />

// Product thumbnail — below the fold, no priority needed (lazy loads by default)
<Image src="/product.jpg" alt="Product" width={400} height={400} />

Images from external URLs

If your images are hosted on a CDN or external service, you need to whitelist the domain in next.config.js:

// next.config.js
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'images.unsplash.com',  // Allow Unsplash images
      },
      {
        protocol: 'https',
        hostname: 'cdn.yoursite.com',     // Allow your own CDN
      },
    ],
  },
};

The fill prop for responsive images

When you don't know the exact dimensions (like a full-width banner), use fill inside a relatively-positioned container:

<div style={{ position: 'relative', width: '100%', height: '400px' }}>
  <Image
    src="/cover.jpg"
    alt="Cover photo"
    fill                        // Fills the parent container
    style={{ objectFit: 'cover' }}  // Crops cleanly like CSS background-size: cover
  />
</div>

---

2. Code Splitting

Every line of JavaScript your app loads makes the browser do more work. Code splitting breaks your app into smaller pieces so users only download the code they actually need right now.

Automatic code splitting (free, built-in)

Next.js automatically splits code at every route boundary. When a user visits /about, they only download the JavaScript for the About page — not the Dashboard, Settings, or any other page.

You get this for free without doing anything. But you can go further.

Dynamic imports for heavy components

Some components are large but only needed in certain situations — a rich text editor, a PDF viewer, a complex chart library. Use dynamic() to load them only when required:

import dynamic from 'next/dynamic';

// This component won't be included in the initial page bundle.
// It loads only when it's about to render on screen.
const RichTextEditor = dynamic(
  () => import('@/components/RichTextEditor'),
  {
    loading: () => <p>Loading editor...</p>,  // Show this while the component loads
    ssr: false,  // Skip server-side rendering for browser-only components
  }
);

export default function BlogEditor() {
  return (
    <div>
      <h1>Write your post</h1>
      <RichTextEditor />  {/* Loads only when this page renders */}
    </div>
  );
}

When to use ssr: false

Set ssr: false when your component uses browser-only APIs like window, document, or localStorage. These don't exist on the server, so trying to render them server-side causes errors.

// Chart library uses browser canvas APIs — skip SSR
const Chart = dynamic(() => import('@/components/Chart'), { ssr: false });

// Map component uses window.google — skip SSR
const MapView = dynamic(() => import('@/components/MapView'), { ssr: false });

Lazy loading third-party libraries

You can also dynamically import plain JavaScript modules, not just components:

// Instead of importing at the top (loads on every page):
// import confetti from 'canvas-confetti';

// Load it only when the button is clicked:
async function handleCelebrate() {
  const confetti = (await import('canvas-confetti')).default;
  confetti({ particleCount: 150, spread: 70 });
}

---

3. Caching Strategies

Caching means storing a pre-built version of your page so the server doesn't have to rebuild it from scratch on every request. Done right, it's one of the biggest performance wins available.

Next.js gives you three rendering and caching modes — each suited for different types of content.

Static Generation (SSG) — fastest option

Best for: blog posts, marketing pages, documentation, product listings — any content that doesn't change per user.

The page is built once at deploy time and served instantly to every visitor from a CDN. No database queries, no server processing per request.

// app/blog/[slug]/page.js (App Router)

// This runs at BUILD TIME, not on each request
export default async function BlogPost({ params }) {
  // Fetches data once during build — result is baked into the HTML
  const post = await fetch(`https://api.yoursite.com/posts/${params.slug}`)
    .then(res => res.json());

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

Incremental Static Regeneration (ISR) — best of both worlds

Best for: e-commerce products, news articles, dashboards — content that changes but doesn't need to be 100% real-time.

The page is pre-built like SSG, but it automatically regenerates in the background after a set time period. Users always get a fast cached page, and it stays up to date.

// app/products/[id]/page.js

async function getProduct(id) {
  const res = await fetch(`https://api.yoursite.com/products/${id}`, {
    next: {
      revalidate: 3600,  // Rebuild this page at most once per hour (3600 seconds)
    },
  });
  return res.json();
}

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.price}</p>
    </div>
  );
}

On-demand revalidation

You can also trigger a page rebuild manually — for example, when a product is updated in your CMS:

// app/api/revalidate/route.js

import { revalidatePath } from 'next/cache';

export async function POST(request) {
  const { path } = await request.json();

  // Rebuild the specific page that was updated
  revalidatePath(path);

  return Response.json({ revalidated: true });
}

// Your CMS webhook hits this endpoint when content changes
// POST /api/revalidate  { "path": "/products/sneakers-v2" }

Server-Side Rendering (SSR) — use sparingly

Best for: pages that need real-time, user-specific data — dashboards, cart pages, live feeds.

The page is rebuilt on every single request. It's always fresh, but it's also the slowest option. Only use SSR when the data truly can't be cached.

// app/dashboard/page.js

async function getUserData() {
  // No caching — fetch fresh data on every request
  const res = await fetch('https://api.yoursite.com/user/me', {
    cache: 'no-store',  // Disables all caching for this request
  });
  return res.json();
}

export default async function Dashboard() {
  const user = await getUserData();

  return <h1>Welcome back, {user.name}</h1>;
}

Caching decision guide

Your content	Best strategy	Why
Blog posts, docs	Static Generation (SSG)	Never changes, serve instantly
Product pages, news	ISR with revalidate	Changes occasionally, still fast
User dashboard	SSR with cache: 'no-store'	Personal, must be fresh
API responses	revalidate: N	Control freshness per endpoint

---

4. Font Optimization

Fonts are a sneaky performance killer. Loading a font from Google Fonts means a round-trip network request that blocks rendering. Next.js has a built-in solution.

// app/layout.js

import { Inter, Fira_Code } from 'next/font/google';

// Next.js downloads the font at BUILD TIME and self-hosts it
// No external network request at runtime — fonts load instantly
const inter = Inter({
  subsets: ['latin'],          // Only load the characters you need
  display: 'swap',             // Show fallback font while loading, then swap
  variable: '--font-inter',    // Expose as a CSS variable for use in Tailwind
});

const firaCode = Fira_Code({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-fira-code',
});

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

What this does behind the scenes: Next.js downloads the font files at build time, self-hosts them alongside your app, and injects them with zero layout shift. No more flash of unstyled text (FOUT) and no extra DNS lookup.

---

5. Script Optimization

Third-party scripts — analytics, chat widgets, ad trackers — can seriously slow down your page. The <Script> component gives you control over when they load.

import Script from 'next/script';

export default function Layout({ children }) {
  return (
    <>
      {children}

      {/* afterInteractive: loads after the page becomes interactive */}
      {/* Use for: analytics, tag managers */}
      <Script
        src="https://www.googletagmanager.com/gtag/js?id=GA_ID"
        strategy="afterInteractive"
      />

      {/* lazyOnload: loads during browser idle time */}
      {/* Use for: chat widgets, heatmaps, non-critical tools */}
      <Script
        src="https://cdn.intercom.io/widget.js"
        strategy="lazyOnload"
      />

      {/* beforeInteractive: loads before the page is interactive */}
      {/* Use for: polyfills, critical consent tools — use rarely */}
      <Script
        src="/polyfills.js"
        strategy="beforeInteractive"
      />
    </>
  );
}

Script loading strategies at a glance

Strategy	When it loads	Best for
beforeInteractive	Before page hydration	Polyfills, consent tools
afterInteractive	After page hydration	Analytics, tag managers
lazyOnload	During browser idle time	Chat widgets, social embeds

---

6. Monitoring Performance

Optimization without measurement is guesswork. These tools tell you exactly where your app is slow.

Vercel Analytics + Speed Insights

If you deploy on Vercel, add real-user performance monitoring in two lines:

// app/layout.js
import { Analytics } from '@vercel/analytics/react';
import { SpeedInsights } from '@vercel/speed-insights/next';

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />       {/* Tracks page views and visitor data */}
        <SpeedInsights />   {/* Tracks Core Web Vitals from real users */}
      </body>
    </html>
  );
}

Web Vitals reporting

Capture Core Web Vitals manually and send them to your own analytics:

// app/layout.js or a dedicated component

export function reportWebVitals(metric) {
  // metric contains: name, value, rating ('good', 'needs-improvement', 'poor')
  console.log(metric);

  // Send to your analytics provider
  fetch('/api/analytics', {
    method: 'POST',
    body: JSON.stringify({
      name: metric.name,     // 'LCP', 'FID', 'CLS', 'TTFB', 'FCP'
      value: metric.value,   // The measured value
      rating: metric.rating, // 'good', 'needs-improvement', or 'poor'
    }),
  });
}

Lighthouse (free, built into Chrome)

Run a Lighthouse audit directly in Chrome DevTools:

1. Open Chrome DevTools (F12 or right-click → Inspect)
2. Click the Lighthouse tab
3. Select Performance and click Analyze page load
4. Review your scores and follow the specific recommendations

Aim for a score above 90 in Performance, Accessibility, and Best Practices.

---

7. Bundle Analysis: Find What's Making Your App Heavy

Before optimizing, you need to know what is large. The bundle analyzer shows you a visual map of every package in your JavaScript bundle.

# Install the analyzer
npm install @next/bundle-analyzer

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

module.exports = withBundleAnalyzer({
  // your other Next.js config here
});

# Run the analyzer — opens a visual treemap in your browser
ANALYZE=true npm run build

Look for:

• Packages that are unexpectedly large (moment.js, lodash, etc.)
• Duplicate packages loaded at different versions
• Libraries that could be replaced with smaller alternatives

---

Performance Optimization Checklist

Use this checklist before you launch or after a performance audit:

Images

• Replace all <img> tags with Next.js <Image> component
• Add priority to above-the-fold images
• Use fill + objectFit for responsive containers
• Whitelist external image domains in next.config.js

JavaScript

• Wrap heavy components in dynamic() imports
• Use ssr: false for browser-only components
• Lazy-load third-party libraries with dynamic import()
• Run bundle analyzer to spot bloated packages

Caching

• Use Static Generation for content that rarely changes
• Use ISR with revalidate for content that updates occasionally
• Use cache: 'no-store' only for truly real-time, user-specific pages

Fonts & Scripts

• Replace Google Fonts <link> tags with next/font
• Load analytics scripts with strategy="afterInteractive"
• Load non-critical widgets with strategy="lazyOnload"

Monitoring

• Set up Vercel Speed Insights or Web Vitals reporting
• Run a Lighthouse audit and target 90+ scores
• Fix LCP, CLS, and INP issues flagged by the audit

---

Key Takeaways

• Images are the biggest win — switching to next/image takes five minutes and can cut page weight by 70%
• Dynamic imports keep bundles small — only load JavaScript when it's actually needed
• Match your caching strategy to your content — static for blogs, ISR for products, SSR only for real-time data
• Self-host your fonts — next/font eliminates the external network request and prevents layout shift
• Control third-party scripts — use strategy="lazyOnload" for non-critical tools so they don't block your page
• Measure before and after — Lighthouse and Vercel Speed Insights tell you where to focus your effort

Performance isn't a one-time fix — it's an ongoing habit. Start with images and dynamic imports, and you'll see the biggest gains with the least effort.