Chapter 37: Rendering Strategies
Different pages have different needs. A marketing page benefits from static generation. A dashboard needs client-side rendering. An e-commerce product page needs SSR for SEO. This chapter covers when to use each strategy.
Client-Side Rendering (CSR)​
The default for Vite + React. The server sends a minimal HTML shell, and React renders everything in the browser.
Best for: Authenticated dashboards, admin panels, interactive tools — anything behind a login where SEO does not matter.
Browser: Downloads HTML shell → Downloads JS → Executes React → Renders UI
Pros: Simplest architecture, fast interactions after initial load, no server rendering cost Cons: Blank page until JS loads (poor FCP), not indexable by search engines
This is what our Vite + TanStack Router setup does by default. For most TaskForge pages (dashboard, projects, tasks), CSR is the right choice.
Server-Side Rendering (SSR) with TanStack Start​
When you need faster first-paint and SEO, TanStack Start adds SSR to TanStack Router:
// With TanStack Start, routes can be server-rendered
// The same route file works for both SSR and CSR
export const Route = createFileRoute("/blog/$slug")({
loader: async ({ params }) => {
const post = await fetchBlogPost(params.slug);
return { post };
},
component: BlogPost,
});
function BlogPost() {
const { post } = Route.useLoaderData();
return (
<article>
<h1>{post.title}</h1>
<div dangerouslySetInnerHTML={{ __html: post.content }} />
</article>
);
}
Best for: Public pages (marketing, blog, product pages) that need SEO and fast initial render.
Streaming SSR​
TanStack Start supports streaming, which sends HTML to the browser in chunks as it becomes ready:
Server: Sends <head> + shell immediately
├── Streams header content ────→ Browser renders header
├── Streams main content ──────→ Browser renders main
└── Streams footer + hydration → Browser becomes interactive
This gives users something to see immediately, even while data is still loading on the server.
Choosing the Right Strategy Per Route​
| Route | Strategy | Why |
|---|---|---|
/login, /register | CSR | Behind no auth, simple forms |
/dashboard | CSR | Authenticated, highly interactive |
/projects/* | CSR | Authenticated, real-time data |
/blog/* | SSR | SEO needed, content-heavy |
/pricing | SSR or Static | Public page, SEO critical |
/docs/* | Static | Content rarely changes |
Hybrid Approach​
Most production apps use a hybrid approach:
- Public pages (marketing, docs, blog): SSR or static generation for SEO and performance
- Authenticated pages (app): CSR for simplicity and interactivity
With TanStack Start, you can mix these in the same application. Public routes get SSR while authenticated routes remain CSR.
When You Don't Need SSR​
If your application is entirely behind authentication (like TaskForge's main app), CSR is sufficient. Don't add SSR complexity for pages that:
- Are not indexed by search engines
- Are behind authentication
- Have highly personalized content
- Are primarily interactive (dashboards, editors, tools)
Summary​
- ✅ CSR for authenticated, interactive pages — simplest architecture
- ✅ SSR for public, SEO-critical pages — faster first paint, indexable
- ✅ Streaming SSR for the best of both — progressive rendering
- ✅ Static generation for content that rarely changes
- ✅ Choose strategy per route, not globally
- ✅ Don't add SSR unless you need SEO or faster initial render