I've been building production apps on the Next.js App Router since it was stable enough to trust, and I've made most of the mistakes you can make with it. NexusEd's frontend runs on Next.js 15, and so does the Affixx marketing and dashboard layer. The App Router's performance ceiling is genuinely high, but you have to understand the mental model to get there. Misunderstand it and you'll build something that performs worse than the Pages Router.
The single most important thing to internalise: components are Server Components by default, and that's a good thing. Server Components run only on the server — no JavaScript shipped to the browser, direct access to databases and APIs without client-side fetch waterfall, and full node environment access.
The decision tree I actually use:
Does this component need:
- onClick, onChange, or any event listener? → Client Component
- useState or useReducer? → Client Component
- useEffect? → Client Component (but ask why first)
- Browser APIs (window, localStorage)? → Client Component
If none of the above → Server Component
The "but ask why first" on useEffect is deliberate. I've seen dozens of useEffect calls that are really just data fetching that belongs in a Server Component. If you're fetching data on mount, move it to the server.
// Before — unnecessary client component
'use client';
export default function CourseList() {
const [courses, setCourses] = useState([]);
useEffect(() => {
fetch('/api/courses').then(r => r.json()).then(setCourses);
}, []);
return <ul>{courses.map(c => <li key={c.id}>{c.title}</li>)}</ul>;
}
// After — server component, no JS shipped, no waterfall
export default async function CourseList() {
const courses = await db.query.courses.findMany({ where: eq(courses.active, true) });
return <ul>{courses.map(c => <li key={c.id}>{c.title}</li>)}</ul>;
}The second version ships zero JavaScript for this component, eliminates a round-trip fetch, and renders faster.
Partial Prerendering (PPR) is the most significant rendering innovation in Next.js 15. It lets you statically render the shell of a page at build time and stream dynamic content into it at request time — all from a single route.
Enable it experimentally:
// next.config.ts
export default {
experimental: {
ppr: true
}
}Then wrap dynamic parts in Suspense:
// app/dashboard/page.tsx
export default function DashboardPage() {
return (
<main>
{/* Static shell — prerendered at build time */}
<DashboardNav />
<DashboardHeader />
{/* Dynamic content — streamed at request time */}
<Suspense fallback={<MetricsSkeleton />}>
<LiveMetrics /> {/* fetches real-time data */}
</Suspense>
<Suspense fallback={<FeedSkeleton />}>
<ActivityFeed /> {/* fetches user-specific data */}
</Suspense>
</main>
);
}The browser receives the prerendered shell immediately (sub-millisecond from CDN edge), then the dynamic parts stream in as they resolve. On NexusEd's dashboard, this reduced perceived load time by roughly 40% compared to full server-side rendering, because the navigation and layout are instant while data loads progressively.
The Next.js 15 caching model changed significantly from v13/14. Here's what actually works.
Fetch cache is the simplest — pass { next: { revalidate: N } } to fetch:
// Cache for 60 seconds, revalidate on-demand
const data = await fetch('https://api.example.com/courses', {
next: { revalidate: 60, tags: ['courses'] }
});unstable_cache wraps any async function, not just fetch. Use it for database queries:
import { unstable_cache } from 'next/cache';
const getCoursesByCategory = unstable_cache(
async (category: string) => {
return db.query.courses.findMany({
where: eq(courses.category, category)
});
},
['courses-by-category'],
{ revalidate: 300, tags: ['courses'] }
);
// Usage in a Server Component — result is cached
const courses = await getCoursesByCategory('programming');Tag-based revalidation is the pattern that makes on-demand revalidation work:
// In your Server Action or API route after a content update
import { revalidateTag } from 'next/cache';
export async function publishCourse(courseId: string) {
await db.update(courses).set({ published: true }).where(eq(courses.id, courseId));
revalidateTag('courses'); // invalidates all caches tagged 'courses'
}Route-level cache behaviour is controlled by segment config exports:
// app/courses/[id]/page.tsx
// Static — prerendered at build time
export const dynamic = 'force-static';
export const revalidate = 3600; // revalidate hourly
// Or dynamic — always server-rendered
export const dynamic = 'force-dynamic';
// Or the default — automatic (Next.js decides based on data fetching)For NexusEd's course catalogue pages, we use revalidate = 3600 with revalidateTag triggered by CMS webhooks. The page is static 99.9% of the time and regenerates only when content changes.
Streaming is not just for performance — it's for user experience under slow data. Place Suspense boundaries at meaningful granularity, not just around the whole page:
// Granular boundaries — each section renders independently
export default function CoursePage({ params }: { params: { id: string } }) {
return (
<div>
{/* This resolves fast — static course metadata */}
<Suspense fallback={<CourseHeaderSkeleton />}>
<CourseHeader id={params.id} />
</Suspense>
{/* This may be slower — aggregated enrollment stats */}
<Suspense fallback={<StatsSkeleton />}>
<EnrollmentStats id={params.id} />
</Suspense>
{/* This is slowest — user-specific progress */}
<Suspense fallback={<ProgressSkeleton />}>
<UserProgress id={params.id} />
</Suspense>
</div>
);
}Each Suspense boundary resolves and renders independently. The fast parts appear immediately; the slow parts fill in. The user sees something useful within 100ms even if the slowest query takes 800ms.
Over-clientifying: Adding 'use client' to a component that only needs it for a small interactive element. Instead, keep the parent as a Server Component and create a small client leaf:
// Bad: entire product card becomes a client component for one button
'use client';
export function ProductCard({ product }: Props) { ... }
// Good: only the interactive part is a client component
export function ProductCard({ product }: Props) {
// Server Component — no 'use client'
return (
<div>
<h2>{product.name}</h2>
<AddToCartButton productId={product.id} /> {/* client leaf */}
</div>
);
}No Suspense on slow data fetches: If a page has a Server Component that runs a slow query, the entire page render blocks until that query returns. Wrap slow fetches in Suspense to unblock the rest of the page.
Calling cookies() or headers() unnecessarily: These opt your route into dynamic rendering. Only call them in components that genuinely need request-specific data.
The App Router rewards correct mental models and punishes misunderstanding. Once it clicks, it's the best frontend architecture I've worked with for content-heavy, data-driven applications.