Next.js Performance Checklist 2026: Every Optimization, Ranked

Why Most Next.js Apps Are Slower Than They Need to Be

Honestly, most Next.js apps ship with a dozen obvious performance problems that nobody bothered to fix. Not because the developers are bad — because the defaults look fine in development, Lighthouse passes on localhost, and by the time you notice sluggishness in production, the team's already on the next feature.

This checklist is ranked by actual impact on Core Web Vitals: LCP, INP, and CLS. Not by how impressive the technique sounds in a conference talk. If something moves the needle by 2ms, it's near the bottom. If it cuts your bundle by 40%, it's at the top.

We're talking Next.js 15.x with the App Router. Some of this applies to Pages Router too, but if you're still on Pages in 2026 without a migration plan, that's a separate conversation.

1. Server Components First — The Biggest Win You're Probably Ignoring

The single highest-impact change you can make is auditing which components are unnecessarily marked 'use client'. Every 'use client' boundary you add pulls that component — and everything it imports — into the JavaScript bundle shipped to the browser. That's data fetching logic, utility functions, date formatters, all of it.

A data display component that fetches from your API and renders a table has zero reason to be a Client Component. Move the fetch to a Server Component, pass the data down as props. Your bundle shrinks, your LCP improves, and your server does the heavy lifting instead of making the user's phone do it.

The mental model shift is: Server Components run once on the server and send HTML. Client Components hydrate in the browser and add interactivity. If a component doesn't need useState, useEffect, event handlers, or browser-only APIs — it should be a Server Component. Full stop.

2. Bundle Analysis and Tree-Shaking: Find the Dead Weight

Run @next/bundle-analyzer before you do anything else. You'll almost certainly find something shocking — a 200KB date library where you use one function, or an icon pack where 3,400 icons get bundled because someone imported from the root instead of the specific path.

// Bad: imports the entire lucide-react package tree
import { ArrowRight, Check, X } from 'lucide-react'

// Better: next/dynamic for icons only used conditionally
import dynamic from 'next/dynamic'
const ArrowRight = dynamic(() =>
  import('lucide-react').then((mod) => mod.ArrowRight)
)

// For date handling — use date-fns with explicit imports
import { format } from 'date-fns/format'
import { parseISO } from 'date-fns/parseISO'
// NOT: import { format, parseISO } from 'date-fns'

The date-fns sub-path imports alone can save 80-120KB depending on how many functions you use. Same story with lodash — if you're still doing import _ from 'lodash' in 2026, that's around 70KB of weight you're carrying for no reason. Switch to lodash-es with named imports or just use native JS.

3. Image Optimization: next/image Is Not Enough on Its Own

Yes, next/image handles WebP conversion, lazy loading, and responsive srcsets automatically. But there are configuration mistakes that wipe out most of those gains. The most common one: forgetting to set sizes on images that span different widths at different breakpoints.

If you've got a hero image that's full-width on mobile and 600px on desktop, and you don't specify sizes, Next.js will download the full-resolution version on every device. Set sizes="(max-width: 768px) 100vw, 600px" and you're done. The difference on a 3G mobile connection is brutal.

Also worth checking: your next.config.js remotePatterns vs domains config (domains is deprecated in Next.js 15), and whether you've got unoptimized={true} lurking somewhere from a "quick fix" that never got reverted. That flag disables every single image optimization silently.

4. Caching Strategy: ISR, React Cache, and the fetch() Deduplication Model

The App Router's caching model is legitimately confusing. There are four separate caches layered on top of each other: the Request Memoization cache, the Data Cache, the Full Route Cache, and the Router Cache. Getting them wrong means either serving stale data or hammering your database on every request.

For most apps, the pattern you want is ISR with on-demand revalidation. Set revalidate on your fetch calls or route segments, then call revalidatePath() or revalidateTag() from a Server Action when your data actually changes. This means users always get fast cached responses, and invalidation happens the moment content updates — not on some arbitrary timer.

// In your data fetching function
export async function getProducts() {
  const res = await fetch('https://api.example.com/products', {
    next: {
      tags: ['products'],
      revalidate: 3600 // fallback: revalidate hourly
    }
  })
  return res.json()
}

// In your Server Action after a mutation
import { revalidateTag } from 'next/cache'

export async function updateProduct(id: string, data: ProductData) {
  await db.product.update({ where: { id }, data })
  revalidateTag('products') // instantly busts the cache
}

The react cache function is different — it's for deduplicating identical fetch calls within a single render pass. If your layout and page both call getUser(), wrapping it in cache() means the actual fetch only runs once per request. This is particularly useful when you're if you're building reusable React components that share data dependencies.

5. Font Loading: The CLS Killer Most Teams Miss

Cumulative Layout Shift from fonts is one of the sneakiest performance bugs. You load a page, it looks fine, then 200ms later everything jumps as the custom font kicks in and the fallback font's different line-height shifts all the content down. Your users notice even if they can't articulate why.

Next.js 15 ships next/font with automatic font subsetting, zero layout shift via size-adjust, and self-hosting from Google Fonts without privacy implications. Use it. The config looks like this:

import { Inter, JetBrains_Mono } from 'next/font/google'

const inter = Inter({
  subsets: ['latin'],
  variable: '--font-inter',
  display: 'swap',
  preload: true,
  // Only load the weights you actually use
  weight: ['400', '500', '600', '700']
})

const mono = JetBrains_Mono({
  subsets: ['latin'],
  variable: '--font-mono',
  display: 'swap',
  weight: ['400', '500']
})

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

The size-adjust property that next/font injects under the hood compensates for the metric differences between your fallback font and your custom font. The result is zero layout shift even before the font loads. If you're building a UI with dark/light switching — like the pattern covered in theme toggle for React apps — font stability is especially important since font size differences can compound with color-scheme transitions.

6. Dynamic Imports and Code Splitting for Heavy Components

Not every component needs to be in the initial bundle. Modals, drawers, rich text editors, chart libraries, color pickers — if they're not visible on first render, they shouldn't block it. next/dynamic is your friend here.

The pattern that trips people up is using next/dynamic but forgetting the ssr: false option on browser-only libraries. If you're dynamically importing something that touches window or document, it'll still crash during SSR unless you opt out. And are you actually checking whether your dynamic imports have meaningful loading states, or are you just letting the UI flash empty?

For genuinely heavy UI — think a Markdown editor with syntax highlighting, or a 3D scene — consider the Suspense boundary approach. Wrap the dynamic import in a <Suspense fallback={<Skeleton />}> and your shell renders immediately while the heavy stuff streams in. This is how you get a fast LCP score without stripping functionality. You can also apply this to interactive effects like particle backgrounds in React that add visual weight to a page.

7. Middleware, Edge Functions, and When Not to Use Them

Middleware runs on every request before it hits your routes. That's incredibly useful for auth redirects, A/B testing splits, and geolocation-based routing. It's also a place where people accidentally tank their performance by doing too much computation in a V8 isolate with a cold start budget of ~1ms.

Keep middleware lean. Auth token verification: fine. Database queries: no. Calling external APIs: please don't. If you need anything that takes real time, use an Edge Route Handler instead and call it from the client after the page loads. The middleware runtime doesn't have Node.js APIs — it's the Edge Runtime, which means no fs, no path, no most npm packages.

Edge functions in general are worth using for geolocation redirects, country-based content, and personalization headers. They're not worth using for everything just because they sound fast. A cached response from a regular serverless function is faster than an uncached edge function. The cache wins. Always check your caching strategy before reaching for the edge.

If you're architecting a SaaS with region-specific data requirements, combining edge middleware for routing with RSC for data fetching is a genuinely good pattern. The same principles apply when building component libraries — something the Empire UI glassmorphism components demonstrate with their client/server split.

8. Monitoring Real Performance: Beyond Lighthouse Scores

Lighthouse runs on a throttled CPU simulation in a controlled environment. It's a useful proxy, not the truth. Real User Monitoring — RUM — is what tells you what actual users experience on actual devices on actual networks.

Next.js has useReportWebVitals built in. Use it. Send the data to Vercel Analytics, Datadog, or even just a simple logging endpoint. You want to know your 75th percentile LCP on mobile, not your 50th percentile on the Lighthouse emulated network. The difference between those numbers is often 1.5-2 seconds.

Set up your monitoring before you start optimizing. Otherwise you're flying blind and you won't know if the changes you're making actually help. Performance work without measurement is just speculation. Check your INP scores especially — since INP replaced FID as a Core Web Vital, a lot of teams have interaction latency problems they don't know about yet.

FAQ

Read next