After shipping multiple high-traffic Next.js applications in 2024, we have a clear picture of which performance patterns produce measurable gains and which are premature optimisation. Here is our current playbook.
Server Components First
The default should be React Server Components. Move to Client Components only when you need browser APIs, event handlers, or React hooks. Every unnecessary Client Component adds JavaScript to the bundle. On a typical marketing site, converting 60–70% of components to server-rendered reduces the initial JS bundle by 30–50%.
The mental model we use: if a component only reads data and renders HTML, it should be a Server Component. If it needs to respond to user interactions, it is a Client Component.
Partial Pre-Rendering
Next.js 15's Partial Pre-Rendering (PPR) is the most significant architectural change since the App Router. PPR lets you ship a static HTML shell immediately, then stream in dynamic content. For our e-commerce and SaaS clients, this produced a 40–60% improvement in Time to First Byte without any application-level caching.
Enable it in next.config.ts: experimental: { ppr: true }.
The New Cache API
Next.js 15 ships with unstable_cache and the revalidateTag / revalidatePath invalidation APIs. We use this pattern for all data fetching: cache aggressively, invalidate surgically on mutations.
Image Optimisation
The single highest-impact optimisation we do on every project: add priority to the LCP image. This triggers a <link rel="preload"> and removes the largest contributor to LCP delay. Second: ensure all images have explicit width and height to eliminate CLS.
What Does Not Move the Needle
- Memoising components that render infrequently
- Code splitting chunks that are already below 50kb
- Removing console.logs from production builds
- Switching from npm to pnpm for build speed
Focus on the fundamentals: server components, PPR, and image priority. Everything else is marginal.