# SSR
With SSR on, a page is rendered on the server with its data already loaded, so
the browser gets real HTML on the first response — not an empty shell that
fetches afterward. Point0 does this without you marking anything: it renders the
page, finds the queries it tried to run, fetches them on the server, and
re-renders until nothing is left pending. Then it ships the HTML plus a
dehydrated query cache, and the page hydrates into the normal SPA.
```ts
// engine.ts
import { Engine } from '@point0/engine'
export const engine = Engine.create({
ssr: true, // server-render pages; off unless you turn it on
clients: [
/* ... */
],
})
```
That single line is the whole setup. The rest of this page explains the loop,
the tuning options, and the prefetch policies that decide how much work each
navigation does.
## How a render becomes HTML
SSR runs a **render-to-discover** loop. There's no manifest of "what this page
needs" — Point0 learns it by rendering:
1. Render the page once on the server.
2. Look at the query cache for any [query](query) that is **pending** — a query
the render started but couldn't resolve synchronously.
3. Fetch those queries on the server (their loaders run here, with your server
code).
4. Render again. Now those queries resolve from cache, which may reveal _new_
pending queries deeper in the tree.
5. Repeat until a render adds no new pending queries.
```tsx
// this page renders, the loader is found pending, fetched, then re-rendered
export const ideaPage = root.lets
.page('/ideas/:id')
.with(ideaQuery, ({ params }) => ({ id: Number(params.id) }))
.page(({ data: { idea } }) => {idea.title}
)
// server ships HTML with already filled in; no loading flash on the client
```
In practice this is **2–4 re-renders per request** — one to discover, one or two
to fetch and settle. A page with no data settles in a single render; a chain
where one query's result feeds the next (via an [SsrStore](ssr-store)) can take
five. You don't manage any of this; it's the price of not having to declare your
data dependencies up front.
And if you don't want to pay it, you don't have to. The re-renders are a
convenience, not a tax: tell Point0 up front what a page needs — warm its cache
in [`.onPrefetchPage`](#onprefetchpage) (below), which runs once before the
first render — and that render already has the data, so the loop settles in a
single pass. So there are two comfortable modes: **convenient but with
re-renders** (write nothing, let the loop discover), or **a little extra work
and zero re-renders** (declare the data once). Pick per page.
Two things the loop deliberately does **not** do:
- **Client loaders don't run on the server.** A `.clientLoader()` query stays
pending through SSR and renders its loading state — the data arrives after
hydration. Only server queries are fetched during SSR.
- **Disabled queries are skipped.** A query with `enabled: false` is never
prefetched, which is exactly how a dependent query waits for its input.
## Shipping the HTML, then the SPA
After the loop settles, the server sends the rendered HTML with a serialized
store (including the resolved query cache) injected as a `