Next.js Performance

Where Next.js Performance Wins Come From

Performance in a Next.js app comes from several layers working together: choosing the right rendering strategy per route (static/ISR over SSR where possible), minimizing client-side JavaScript by defaulting to Server Components, and using Next.js's built-in optimization primitives for images, fonts, and scripts instead of naive alternatives.

Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — are the concrete metrics Google uses to measure real-world performance, and they map directly onto the specific optimizations covered in this section.

// A quick performance self-check for any route:
// 1. Is this route static/ISR, or does it need to be SSR?
// 2. Are all fetches inside it parallelized where possible?
// 3. Is "use client" scoped as narrowly as possible?
// 4. Are images using next/image, and fonts using next/font?

Running through this checklist for any slow page usually surfaces the biggest wins quickly.

Core Web Vitals at a Glance

LCP (Largest Contentful Paint)  — how fast the main content appears
INP (Interaction to Next Paint) — how responsive interactions feel
CLS (Cumulative Layout Shift)   — how much content shifts unexpectedly

• LCP is improved by fast server responses, static/ISR rendering, and optimized images.
• INP is improved by shipping less client-side JavaScript and avoiding long-running scripts.
• CLS is improved by reserving space for images/ads and avoiding layout-shifting fonts.
• All three are directly influenced by decisions covered throughout this course.

Performance Levers Cheat Sheet

Where to look first when a Next.js app feels slow.

Measure Before You Optimize

Before changing anything, measure with real tools — Lighthouse in Chrome DevTools, the Vercel Analytics dashboard (if deployed there), or next build's bundle size output — so you're optimizing based on actual data rather than guesses about what's slow.

A Practical Performance Checklist

The remaining lessons in this section cover each of these levers individually, but as a quick reference, most Next.js performance work falls into one of these categories.

• Rendering strategy: static/ISR wherever content allows it.
• Bundle size: minimal "use client" usage, code splitting for large components.
• Images: next/image with correct sizes/priority usage.
• Fonts: next/font for self-hosted, layout-shift-free font loading.
• Third-party scripts: next/script with an appropriate strategy.

Common Mistakes

• Optimizing based on guesses instead of measuring with Lighthouse or real analytics first.
• Treating every performance problem as a rendering strategy problem, when it's sometimes a slow API or database query.
• Ignoring bundle size until it becomes a serious problem, instead of monitoring it incrementally.
• Applying every optimization technique everywhere, rather than focusing on the pages that actually matter most (homepage, landing pages, checkout).

Key Takeaways

• Next.js performance comes from rendering strategy, minimal client JS, and built-in optimization primitives.
• Core Web Vitals (LCP, INP, CLS) give concrete, measurable performance targets.
• Always measure with real tools before making optimization changes.
• The next few lessons cover image, font, and script optimization, plus bundle analysis, in depth.
• Prioritize optimization effort on your highest-traffic, most performance-sensitive pages first.