Rendering placement, RSC and Cache Components

Why placement changes the system

Choose where each operation executes: build, shared server cache, request, browser startup or later interaction. “Server rendered” is insufficient: HTML delivery, RSC payload delivery and hydration have different costs. A Server Component can fetch directly at the server boundary; a Client Component still needs serialization-safe props and an interaction budget.

Versioned implementation and assumptions

The companion Next.js project pins its framework and enables cacheComponents. Its public reference function uses use cache, a cache lifetime and a tag. The account component reads cookies inside a dynamic Suspense region and deliberately avoids a persistent personal-data cache. This is the selected Cache Components model; do not copy claims about older implicit fetch caching into it. See the official caching source below.

// Route shape, simplified; app/page.tsx is the build-checked version.
<main>
  <h1>Account dashboard</h1>
  <Suspense fallback={<p>Loading account…</p>}>
    <Account />
  </Suspense>
</main>

A public shell can become available while account work is pending. It must not disclose personal details through supposedly public fallback text, metadata or cache keys. A Suspense fallback is not an authorization boundary. Enforce identity before protected data access, regardless of how the component is rendered.

Decision table

Placement	Fits	Hidden cost to verify
Static generation	Public content that tolerates rebuild/refresh delay	Stale assets, publishing delay, personalization accidentally introduced
Request rendering	Identity-dependent initial response	Origin latency, concurrency, serialized payload
Streaming	Independent useful regions with different readiness	Proxy buffering, fallback layout, accessible progress
Browser interaction	Editing, immediate local feedback, device APIs	Download, parse, hydration, long-session memory
Islands	Mostly static pages with isolated interactive regions	Shared state and framework integration overhead

Do not select streaming when the whole task requires one atomic result and a partial result creates misleading confidence. Start independent reads together, but sequence genuine authorization or data dependencies. “Parallelize all fetches” can become a permission bug.

Verification exercise and failure drill

Build and run the Next project in production mode. Read the HTTP body incrementally and observe the static shell and fallback before the delayed account result. Test account switching and logout with the same browser. A production build classifies the route as partially prerendered; that is framework evidence, not proof that every CDN preserves chunk timing.

Capture origin emission and browser receipt times through the real proxy before claiming a streaming benefit. Test a failed secondary region separately from a failed identity read. Retain usable navigation and an explicit retry surface. Avoid announcing every token or repeated skeleton update to assistive technology.

Expected answer and rollout

Move only the public reference data into the shared cache. Keep account data request-scoped. The expected evidence is no Acme detail after switching to Orbit or logout, plus a raw streaming response. Roll out one route with release attribution and shell/error metrics; rollback must retain old hashed assets long enough for already-open tabs.

Executable reference and sources

Implementation · Behavioral evidence · Primary source.

Run the projects and assessment. Human review is pending.