Executive summary

Wasp's client is a fully client-side React app with no server rendering today. This hurts SEO and page load times for content-heavy pages like landing pages.

This RFC proposes Deep Freeze: a phased plan to add server rendering to Wasp:

The recommended first step is static prerendering (Static SSR) at build time (prerender: "static"): after wasp build, selected pages are rendered to HTML once on the build machine, served statically, and hydrated by the CSR app as normal. No server architecture changes are required.

The two more advanced modes are deferred:

Dynamic SSR (per-request server rendering) would allow embedding auth state and personalized data into the HTML response. However, Wasp's Node server currently handles only API requests — enabling dynamic SSR would require it to also import and render the client bundle, collapsing the clean client/server separation and complicating deployment. Worth revisiting once static prerendering is validated.
React Server Components introduce a hard 'use client'/'use server' boundary that developers must reason about on every page they write — directly conflicting with Wasp's core value of a single mental model. The ecosystem outside Next.js is also not yet stable enough to build on. Deferred until a clearer integration story emerges.

Definitions

React rendering types

We will use this table throughout the following document, so make sure to familiarize yourself with it. In the next sections I’ll explain each term in detail so we are all on the same page:

	Client components	Server components
On the server
(Static / Dynamic)	Server-Side Rendering (SSR)	React Server Components (RSC)
On the client	Client-Side Rendering (CSR)	-

Horizontal axis: Component types

Vertical axis: Rendering location

Cells: $component × $location

Current state

There’s not much to say here:

The front-end part of Wasp is a fully client-side app, using client components, and rendering only in the browser.

We don’t have any support for any static or dynamic serving of apps, and the client app is in fact served from assets in an entirely different service than the server.

In exchange, we completely bypass the cognitive overhead of React’s different rendering stages, as we get a single mental model for the Wasp client, and you don’t need to think where the code is running or what access it has.