Server-side rendering is not new. PHP, Rails, and Django have rendered HTML on the server for decades. What changed is the complexity of what we expect from rendered pages. Modern SSR must deliver static content instantly, hydrate interactive widgets without jank, stream progressive updates over a single HTTP response, and do all of this while keeping bundle sizes small enough for a 3G connection in rural Indonesia.
I have spent the last two years migrating three production applications from client-side rendered SPAs to various SSR architectures. The lessons were not always what the framework documentation promised. This article covers what actually matters: the rendering pipeline mechanics, the hydration problem and its emerging solutions, streaming as a first-class pattern, and the island architecture that may make all of this simpler.
How Server-Side Rendering Actually Works
At its core, SSR means running your component tree on the server, serializing the output to an HTML string, and sending that string to the browser. The browser paints the HTML immediately — no waiting for JavaScript to download, parse, and execute before the user sees content. This is the fundamental advantage: perceived performance improves because the browser's HTML parser is fast and incremental.
But the story does not end with the initial paint. A server-rendered page without JavaScript is just a document. To make it interactive — handle clicks, manage state, respond to user input — the framework must "hydrate" the page: download the component JavaScript, walk the existing DOM, and attach event listeners and state management to the already-rendered nodes.
This two-phase process introduces a window of non-interactivity. The page looks ready (the HTML is painted), but it does not respond to user actions until hydration completes. On fast connections with modern hardware, this window is imperceptible. On a mid-range Android phone over a 4G connection, it can last several seconds — long enough for a user to tap a button and wonder why nothing happened.
The Traditional SSR Pipeline
A traditional SSR request follows a synchronous pipeline. The server receives a request, resolves data dependencies (database queries, API calls), renders the full component tree to HTML, and sends the complete response. The browser cannot start painting until the entire response arrives. If one data source is slow — a recommendation engine, a search query, an external API — the whole page waits.
// Traditional SSR — everything blocks on the slowest data source
async function renderPage(req, res) {
// All data must resolve before any HTML is sent
const [user, products, recommendations] = await Promise.all([
fetchUser(req.session.userId),
fetchProducts(req.query.category),
fetchRecommendations(req.session.userId) // Slow: 800ms p95
]);
const html = renderToString(
<App user={user} products={products} recs={recommendations} />
);
res.send(`<!DOCTYPE html><html>${html}</html>`);
}This approach is simple and predictable. It also means your Time to First Byte (TTFB) is bounded by your slowest data source. For pages with uniform data latency, this is fine. For pages that mix fast data (cached product listings) with slow data (personalized recommendations), this is a significant bottleneck.
Streaming SSR: Progressive Rendering Over HTTP
Streaming SSR breaks the all-or-nothing constraint. Instead of waiting for the complete HTML, the server begins sending HTML as soon as the first parts of the page are ready. The browser can start parsing and painting while the server is still rendering later sections.
HTTP/1.1 supports this through chunked transfer encoding. The server sends the response in chunks, each containing a portion of the HTML. The browser's incremental HTML parser handles this naturally — it has always been designed to process HTML as it arrives, not wait for a complete document.
React 18 introduced renderToPipeableStream, which made streaming SSR a first-class API. Combined with Suspense boundaries, it allows you to define which parts of the page can be deferred. The server sends the shell immediately, then streams in the deferred sections as their data resolves.
// Streaming SSR with React — shell renders immediately
function ProductPage({ productId }) {
return (
<Layout>
<ProductHeader id={productId} /> {/* Renders in shell */}
<ProductDetails id={productId} /> {/* Renders in shell */}
<Suspense fallback={<ReviewsSkeleton />}>
<ProductReviews id={productId} /> {/* Streams later */}
</Suspense>
<Suspense fallback={<RecsSkeleton />}>
<Recommendations id={productId} /> {/* Streams later */}
</Suspense>
</Layout>
);
}When the page renders, the header and details (which use fast, cached data) ship immediately. The reviews and recommendations sections initially appear as their skeleton fallbacks. When the data for reviews resolves, React streams a chunk of HTML containing the real content plus a small inline script that swaps the skeleton for the actual content. The browser updates without a full page reload, and the user sees content progressively fill in.
The performance implications are substantial. In our e-commerce migration, streaming SSR reduced p95 TTFB from 1,200ms to 340ms on product pages. The shell rendered in under 400ms regardless of how long recommendations took. Users saw the product name, price, and images almost immediately, even when the recommendation engine was experiencing high latency.
The Hydration Problem
Hydration is the process that transforms server-rendered HTML from a static document into an interactive application. The framework downloads its runtime, re-creates the component tree in memory, walks the existing DOM to match it against the virtual representation, and attaches event listeners. This is computationally expensive, and it must complete before the page becomes fully interactive.
Traditional Hydration
In traditional (full-page) hydration, the framework processes every component on the page, even those that will never need interactivity. A marketing page with a single interactive newsletter form still hydrates the entire layout, header, footer, and every static text block. The JavaScript for all of those components must be downloaded, parsed, and executed.
This creates the "uncanny valley" of SSR: the page looks ready but does not respond to input. Google's INP (Interaction to Next Paint) metric penalizes this directly. A page that takes 2 seconds to hydrate will show poor INP scores for any interaction during that window, even though the content is visually complete.
Selective and Progressive Hydration
React 19 addresses this with selective hydration. When Suspense boundaries are used with streaming SSR, React can prioritize hydrating the components a user is interacting with. If a user clicks on a product card while the recommendations section is still loading, React will hydrate the product card's subtree first.
Vue 3.5 with Nuxt 4 offers a similar capability through its component-level lazy hydration directives. Components can be marked to hydrate on visibility (when they scroll into view), on interaction (when the user hovers or clicks), or on idle (when the browser has spare cycles). This fine-grained control lets developers match hydration strategy to component importance.
Resumability: Skipping Hydration Entirely
Qwik introduced a radical alternative: resumability. Instead of re-executing component code on the client to reconstruct the component tree, Qwik serializes the application state and event handler references into the HTML. When the user interacts with an element, Qwik lazily loads only the specific event handler needed — not the entire component tree.
The result is near-zero startup JavaScript. A Qwik application can become interactive with less than 1 KB of JavaScript, regardless of application size. The trade-off is latency on first interaction: loading and executing the handler introduces a small delay (typically 20-50ms) when the user first interacts with each component. In practice, this is imperceptible to users but measurable in benchmarks.
Resumability has not been widely adopted outside of Qwik, but the concept has influenced other frameworks. React Server Components borrow the idea of keeping some components entirely on the server. Astro's island architecture achieves a similar outcome through a different mechanism.
Island Architecture
Island architecture treats a page as a sea of static HTML with isolated "islands" of interactivity. Each island is an independent component that hydrates separately, with its own JavaScript bundle. The static HTML between islands never needs JavaScript at all.
Astro popularized this pattern and remains its most mature implementation. In an Astro page, you write components in your preferred framework (React, Vue, Svelte, Solid), but they only ship JavaScript when you explicitly mark them as interactive with a client: directive.
<!-- Astro component — static by default -->
<Layout title="Product Page">
<Header /> <!-- Static HTML, zero JS -->
<ProductInfo product={product} /> <!-- Static HTML, zero JS -->
<!-- Interactive island: hydrates on visibility -->
<ImageCarousel client:visible images={product.images} />
<!-- Interactive island: hydrates immediately -->
<AddToCart client:load product={product} />
<!-- Interactive island: hydrates on idle -->
<ReviewForm client:idle productId={product.id} />
<Footer /> <!-- Static HTML, zero JS -->
</Layout>The performance profile of island architecture is compelling for content-heavy sites. A documentation page with a single interactive search widget ships JavaScript only for the search component. A blog post with an interactive code playground ships JavaScript only for the playground. Everything else is pure HTML and CSS.
When Islands Fall Short
Island architecture works best when interactivity is isolated — each island operates independently with its own state. It struggles when islands need to communicate. A product page where the image carousel, variant selector, and add-to-cart button must share state requires either a shared state store (which reintroduces a global JavaScript dependency) or server-mediated communication (which adds latency).
For highly interactive applications — dashboards, email clients, collaborative editors — island architecture adds more complexity than it removes. The overhead of managing inter-island communication and shared state outweighs the benefit of reduced initial JavaScript. These applications are better served by full-application SSR with selective hydration.
Performance Analysis: Measuring What Matters
Different rendering strategies optimize for different metrics. Understanding which metrics matter for your application determines which strategy to choose.
| Metric | Traditional SSR | Streaming SSR | Island Architecture | Resumability (Qwik) |
|---|---|---|---|---|
| TTFB (p50) | 400-800ms | 80-200ms | 50-150ms | 50-150ms |
| FCP (p50) | 500-900ms | 150-350ms | 100-300ms | 100-300ms |
| TTI (p50) | 1.5-4s | 1-3s | 200-800ms | 100-200ms |
| INP (p75) | 150-400ms | 100-300ms | 50-150ms | 40-100ms |
| JS Bundle Size | Full app | Full app | Per-island only | Near-zero initial |
| Complexity | Low | Medium | Medium | High |
These numbers come from our production measurements across three applications: an e-commerce storefront (streaming SSR with React 19), a documentation site (island architecture with Astro 5), and an experimental product configurator (Qwik). All measurements were taken on a mid-range Android device (Pixel 7a) over a simulated 4G connection.
The TTFB vs TTI Tradeoff
Traditional SSR optimizes for the simplest mental model at the cost of TTFB. The server does all the work, sends a complete page, and the result is predictable. Streaming SSR dramatically improves TTFB while keeping TTI roughly similar — the total JavaScript is the same, it just starts arriving sooner.
Island architecture and resumability attack TTI directly by reducing the total JavaScript that must execute. Islands achieve this by excluding static content from hydration. Resumability achieves it by deferring all hydration until interaction.
For content-focused sites where SEO and initial paint matter most, island architecture provides the best ratio of implementation effort to performance gain. For interactive applications where INP and runtime performance matter most, streaming SSR with selective hydration in React or Vue provides a more maintainable architecture.
Framework Comparison for SSR in 2026
Next.js 15 (React 19) offers the most sophisticated SSR story through React Server Components and streaming. The App Router uses server components by default, meaning components run on the server unless explicitly marked with "use client". This reduces client JavaScript significantly for content-heavy applications. The trade-off is architectural complexity — the server/client boundary introduces new constraints on data flow, serialization, and component composition.
Nuxt 4 (Vue 3.5) provides a pragmatic middle ground. Its hybrid rendering allows per-route configuration — some routes can be server-rendered, others statically generated, others client-only. Component-level lazy hydration directives give fine-grained control without the conceptual overhead of server/client component boundaries. The Nitro server engine deploys to edge runtimes with minimal configuration.
SvelteKit 2.5 (Svelte 5) takes the simplest approach. Server rendering is the default. Load functions run on the server, form actions handle mutations without client JavaScript, and the framework progressively enhances pages. There is no separate "server component" concept — the distinction is between data loading (always server) and rendering (server-first with client takeover). The result is a framework that ships less JavaScript by default than either React or Vue.
Astro 5 is the right choice when your content-to-interactivity ratio is high. If 80% of your page is static content with a few interactive widgets, Astro's island architecture delivers the best performance with the least effort. It is not a replacement for a full application framework — it is a content-first framework that happens to support interactive components.
Practical Architecture Decisions
After implementing SSR across multiple production applications, a few principles have become clear.
Start with the content. Before choosing an SSR strategy, map your pages by their interactivity ratio. Pages that are mostly static content with isolated interactive elements are strong candidates for island architecture. Pages with pervasive interactivity benefit from streaming SSR with selective hydration. Forcing an interactive dashboard into an island architecture creates more problems than it solves.
Measure hydration cost separately. Most performance monitoring tools combine FCP and TTI into a single "page load" metric. For SSR applications, the gap between these metrics is the hydration cost — and it is the metric that determines user experience on real devices. A page that paints in 200ms but becomes interactive in 3 seconds is worse than a page that paints in 500ms and becomes interactive in 600ms.
Cache aggressively at the edge. Regardless of SSR strategy, edge caching transforms your performance profile. A streaming SSR page cached at the edge has TTFB equivalent to a static file. Use stale-while-revalidate patterns for content that changes infrequently, and reserve dynamic SSR for personalized or real-time content.
Do not hydrate what does not need to be interactive. This sounds obvious, but in practice most SSR applications hydrate their entire component tree by default. Headers, footers, article content, marketing copy — none of this needs JavaScript. Island architecture enforces this discipline by requiring an explicit opt-in to interactivity. In React and Vue, achieving the same result requires deliberate architecture: separating static layouts from interactive widgets and code-splitting accordingly.
The goal of SSR is not to render HTML on the server. The goal is to deliver a usable page to the user as fast as the network allows. Every architectural decision should be measured against that outcome.
The SSR landscape in 2026 offers genuine options for the first time. Streaming eliminates the TTFB bottleneck. Selective hydration reduces the interactivity gap. Island architecture removes unnecessary JavaScript entirely. Resumability questions whether hydration is needed at all. The right choice depends on your application's specific characteristics — the ratio of content to interactivity, the devices your users carry, and the complexity your team can sustain.