Shipping on the edge with Next.js
How partial prerendering, streaming and edge runtime combine to make apps feel instant — and the trade-offs nobody mentions.
"Fast" is no longer about your server's response time — it is about how quickly the user sees something useful. The modern Next.js toolkit is built around that idea.
Stream what you can, defer what you must
Server Components let you send a static shell instantly and stream the dynamic parts as they resolve. The user reads the hero while the personalised panel hydrates behind it.
export default function Page() {
return (
<>
<Hero /> {/* static, instant */}
<Suspense fallback={<Skeleton />}>
<Personalised /> {/* streamed */}
</Suspense>
</>
);
}
Push logic to the edge
Edge functions run close to the user, which slashes round-trip latency for auth, redirects and personalisation.
- Great for: geolocation, A/B tests, lightweight reads.
- Bad for: heavy compute, large dependencies, anything Node-only.
The edge is a scalpel, not a hammer. Use it where milliseconds of latency actually matter.
The trade-offs nobody mentions
Edge runtime is not Node. No native modules, smaller memory limits, and cold starts that feel fast but still exist. Streaming complicates error handling and analytics. Partial prerendering is brilliant until you need a fully dynamic page.
Measure with real-user metrics, not synthetic scores. The goal is a product that feels instant — the architecture is just how you get there.