Next.js 15 Server Components: Streaming SSR, Partial Rendering, and Data Fetching
Next.js 15 Server Components fundamentally change how React applications fetch data and render HTML. Instead of shipping a JavaScript bundle that renders in the browser, Server Components execute on the server and stream HTML directly to the client — zero client-side JavaScript for those components. Therefore, initial page loads are faster, bundle sizes shrink dramatically, and your database queries stay on the server where they belong. This guide covers the practical patterns for building production applications with Server Components.
Server Components vs. Client Components: When to Use Each
Server Components run exclusively on the server. They can directly access databases, file systems, and internal APIs without exposing credentials to the browser. Moreover, they don’t add to your JavaScript bundle — a Server Component importing a 200KB charting library costs zero bytes on the client because the component renders to HTML on the server.
Client Components run in the browser and handle interactivity — event handlers, browser APIs, state management, and effects. Mark a component with 'use client' at the top of the file. However, the boundary isn’t all-or-nothing: a Server Component page can contain Client Component islands for interactive elements while keeping the rest server-rendered.
// app/dashboard/page.jsx — Server Component (default)
// No 'use client' directive = Server Component
import { db } from '@/lib/database';
import { DashboardChart } from './DashboardChart'; // Client Component
export default async function DashboardPage() {
// Direct database access — no API route needed
const metrics = await db.query(`
SELECT date, revenue, orders
FROM daily_metrics
WHERE date > NOW() - INTERVAL '30 days'
ORDER BY date
`);
const topProducts = await db.query(`
SELECT name, units_sold, revenue
FROM products
ORDER BY revenue DESC LIMIT 10
`);
return (
<div className="grid grid-cols-2 gap-6">
{/* Server-rendered: zero JS shipped */}
<section>
<h2>Top Products</h2>
<table>
<tbody>
{topProducts.map(p => (
<tr key={p.name}>
<td>{p.name}</td>
<td>{p.units_sold}</td>
<td>{p.revenue.toFixed(2)}</td>
</tr>
))}
</tbody>
</table>
</section>
{/* Client Component island — interactive chart */}
<DashboardChart data={metrics} />
</div>
);
}The key insight is that Server Components serialize their output as HTML, not as a JavaScript bundle. Specifically, the top products table above ships as raw HTML — no React hydration, no JavaScript, just rendered content. Only the DashboardChart ships its React code to the client.
Streaming SSR and Suspense Boundaries
Next.js 15 streams HTML to the browser as each component resolves, instead of waiting for the entire page to render. Wrap slow data-fetching sections in <Suspense> with a fallback, and the rest of the page renders immediately. Additionally, the browser can start rendering the header and navigation while the dashboard data is still loading.
This is transformative for pages with multiple data sources. A product page might fetch product details (fast), reviews (medium), and recommendations (slow). Streaming lets users see and interact with the product while reviews and recommendations load progressively.
// app/product/[id]/page.jsx — Streaming with Suspense
import { Suspense } from 'react';
import { ProductDetails } from './ProductDetails';
import { Reviews } from './Reviews';
import { Recommendations } from './Recommendations';
export default function ProductPage({ params }) {
return (
<main>
{/* Renders immediately — fast query */}
<Suspense fallback={<ProductSkeleton />}>
<ProductDetails id={params.id} />
</Suspense>
{/* Streams in when ready — medium query */}
<Suspense fallback={<ReviewsSkeleton />}>
<Reviews productId={params.id} />
</Suspense>
{/* Streams in last — slow ML recommendation query */}
<Suspense fallback={<RecommendationsSkeleton />}>
<Recommendations productId={params.id} />
</Suspense>
</main>
);
}
// Each component fetches its own data
async function Reviews({ productId }) {
const reviews = await db.reviews.findMany({
where: { productId },
orderBy: { createdAt: 'desc' },
take: 20,
});
return <ReviewList reviews={reviews} />;
}Partial Prerendering: Static Shell, Dynamic Content
Partial Prerendering (PPR) combines static generation with streaming dynamic content. The page shell — header, navigation, footer, static content — is prerendered at build time and served from the CDN edge. Dynamic sections stream in from the server when requested. Consequently, Time to First Byte approaches static hosting speeds while dynamic content stays fresh.
Enable PPR in your Next.js config and wrap dynamic sections with Suspense. The build process detects static and dynamic boundaries automatically. For example, an e-commerce category page has a static layout and navigation but dynamic product listings and prices. PPR serves the static shell instantly from the CDN and streams the product grid from the origin server.
Data Fetching Patterns and Caching
Server Components change data fetching fundamentally — you fetch data where you need it, in the component itself, without API routes or client-side state management. Next.js deduplicates identical fetch calls automatically, so if three components fetch the same user data, only one database query executes.
The caching layer in Next.js 15 defaults to no caching for fetch calls, reversing the aggressive caching defaults of Next.js 14. This is more predictable — you opt into caching explicitly. Use unstable_cache for database queries and next.revalidate for fetch calls when you want time-based or on-demand revalidation.
// Explicit caching with revalidation
import { unstable_cache } from 'next/cache';
const getCachedProducts = unstable_cache(
async (categoryId) => {
return db.products.findMany({
where: { categoryId, status: 'active' },
orderBy: { popularity: 'desc' },
});
},
['products-by-category'], // Cache key prefix
{ revalidate: 300, tags: ['products'] } // 5 min TTL, tag for on-demand invalidation
);
// On-demand revalidation via Server Action
'use server';
import { revalidateTag } from 'next/cache';
export async function updateProduct(formData) {
await db.products.update({ ... });
revalidateTag('products'); // Bust the cache
}Migrating from Pages Router to App Router
Migration doesn’t have to be all-or-nothing. The Pages Router and App Router coexist in the same Next.js project. Start by moving your layout to the App Router’s app/layout.jsx, then migrate individual pages incrementally. Furthermore, getServerSideProps logic moves directly into the Server Component as async data fetching — no wrapper function needed.
The biggest migration challenge is third-party libraries that use React hooks or browser APIs — these must become Client Components. Audit your imports: if a library calls useState, useEffect, or accesses window, the consuming component needs the 'use client' directive. In contrast, utility libraries like date-fns or lodash work fine in Server Components.
Related Reading:
Resources:
In conclusion, Next.js 15 Server Components deliver measurable performance wins by moving rendering and data fetching to the server. Streaming SSR with Suspense eliminates waterfall loading patterns, Partial Prerendering combines static speed with dynamic freshness, and the simplified data fetching model removes entire categories of client-side complexity. Start with new pages in the App Router and migrate existing pages incrementally.