Skip to main content

Rendering

How to choose the right rendering architecture for your web project. See the Tech Stack section for our recommended frameworks and tools.

Rendering Strategies​

Modern web applications sit on a spectrum between fully client-rendered and fully server-rendered. Each strategy makes different trade-offs between performance, SEO, interactivity, and infrastructure complexity. Understanding these trade-offs helps you pick the right approach — or the right combination — for your project.

Client-Side Rendering (SPA)​

The server sends a minimal HTML shell along with a JavaScript bundle. The browser downloads and executes that JS, fetches data from APIs, and renders the entire UI on the client.

  • Fast post-load navigation — once the app is loaded, route transitions are instant with no server round-trips.
  • Simple hosting — the output is a set of static files that can be served from any CDN or static host at low cost.
  • Rich interactivity — the entire application state lives in the browser, making complex UI interactions straightforward.
  • Slow First Contentful Paint (FCP) — the user sees nothing meaningful until the JS bundle has been downloaded, parsed, and executed.
  • Large bundles hurt Time to Interactive (TTI) — as the app grows, so does the JS payload, pushing interactivity further out.
  • SEO challenges — search-engine bots that don't execute JavaScript may not index your content correctly.

Best for: internal tools, dashboards, admin panels, and apps behind authentication where SEO doesn't matter.

Further reading: Client-Side Rendering — patterns.dev

Server-Side Rendering (SSR)​

The server generates full HTML for every request. The browser paints the page immediately, then hydrates it with JavaScript to restore interactivity.

  • Fast FCP — users see meaningful content as soon as the HTML arrives, without waiting for JS execution.
  • Excellent SEO — crawlers receive complete HTML, so all content is indexable out of the box.
  • No client-side data-fetch waterfalls — the server can resolve all data dependencies before sending the response.
  • Higher Time to First Byte (TTFB) — the server must compute each page on every request, adding latency.
  • Hydration cost — the page looks ready but isn't interactive until JS loads and hydrates, creating an "uncanny valley" for users.
  • More complex infrastructure — requires a running server and careful caching strategies compared to static hosting.

Best for: content sites that need SEO combined with dynamic or personalized data, such as e-commerce product pages or user-specific feeds.

Frameworks like Next.js, Remix, and Astro all support SSR. See the Tech Stack for our specific recommendations.

Further reading: Server-Side Rendering — patterns.dev

Static Site Generation (SSG)​

Pages are pre-rendered at build time and served as static files from a CDN. No server-side computation happens at request time.

  • Fastest TTFB — pre-built files are served directly from edge caches with no server processing.
  • Excellent SEO — fully rendered HTML is ready for crawlers from the first byte.
  • Lowest infrastructure cost — static hosting is cheap: no application servers, no scaling concerns.
  • Maximum reliability and cacheability — every response is the same static file, making caching trivial.
  • Content only updates on rebuild — changes require a new build and deploy cycle.
  • Build times scale with page count — large sites can face long build durations.

Best for: blogs, documentation sites, marketing pages, and landing pages.

Further reading: Static Rendering — patterns.dev

Islands Architecture​

The page is delivered as static HTML with selectively hydrated interactive "islands." Most of the page ships zero JavaScript; only explicitly marked components download and hydrate their own JS.

  • Near-zero JS by default — pages are fast and lightweight unless you opt individual components into interactivity.
  • Independent, parallel hydration — each island loads and hydrates on its own, so one slow component doesn't block the rest.
  • Framework flexibility — different islands can use different UI frameworks on the same page.
  • Less suited for SPA-like apps — if nearly every component is interactive, the islands model adds overhead without clear benefit.
  • Inter-island state sharing — communicating between islands requires explicit patterns (events, shared stores) rather than a single component tree.

Best for: content-heavy sites with pockets of interactivity — marketing sites, docs with interactive demos, e-commerce storefronts.

Astro is our recommended framework for this pattern.

Further reading: Islands Architecture — patterns.dev

Comparison​

DimensionCSR (SPA)SSRSSGIslands
TTFBFast (static shell)Slower (server compute)Fastest (CDN)Fast–Fastest
FCPSlow (JS must execute)Fast (HTML in response)FastestFast–Fastest
TTISlow (large bundle)Moderate (hydration)Fast (minimal JS)Fast (minimal JS)
SEOChallengingExcellentExcellentExcellent
Dynamic contentExcellentExcellentPoorGood (server islands)
Hosting costLow (static host)Medium–High (server)Lowest (CDN)Low–Medium
CachingEasy (static assets)Complex (per-request)TrivialMostly trivial

Real-world performance depends heavily on implementation quality, bundle size, and infrastructure — these are directional guidelines, not guarantees.

For definitions of FCP, TTFB, LCP, and how to measure them, see Performance & Core Web Vitals.

How to Choose​

Start with the simplest option that meets your requirements, then scale up complexity only when needed.

  • Default to SSG for content sites, docs, blogs, and marketing pages — it's the fastest and cheapest option.
  • Use Islands (Astro) when you need selective interactivity on an otherwise static site — this is our recommended default for new content-focused projects. See Astro.
  • Choose SSR when pages require per-request personalization, real-time data, or user-specific content that can't be pre-built.
  • Use CSR (SPA) for highly interactive applications like dashboards or admin panels where SEO is not a concern.
tip

Modern frameworks let you combine strategies within a single project. Start static and upgrade individual routes to SSR or client-side rendering as requirements demand.

Emerging Patterns​

info

The rendering landscape continues to evolve. Keep these patterns on your radar:

  • Streaming SSR — the server sends HTML in chunks as data resolves, reducing perceived load time.
  • React Server Components (RSC) — a component-level server/client boundary where only interactive components ship JavaScript to the browser.
  • Incremental Static Regeneration (ISR) — individual pages rebuild on demand without requiring a full site rebuild.
  • Edge rendering — SSR logic runs at CDN edge nodes, cutting latency by moving compute closer to users.
  • Partial prerendering — combines a static shell with dynamically streamed content in a single response.

These trends are converging toward per-component rendering decisions rather than app-wide strategy choices.

Project Recipes​

For practical implementations of these rendering strategies, see the project cookbooks: