Skip to main content

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​

RouteStrategyWhy
/login, /registerCSRBehind no auth, simple forms
/dashboardCSRAuthenticated, highly interactive
/projects/*CSRAuthenticated, real-time data
/blog/*SSRSEO needed, content-heavy
/pricingSSR or StaticPublic page, SEO critical
/docs/*StaticContent rarely changes

Hybrid Approach​

Most production apps use a hybrid approach:

  1. Public pages (marketing, docs, blog): SSR or static generation for SEO and performance
  2. 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