SPA for users, SSR only for googlebot / search engine crawlers (SEO)

[redbar0n]

A unique selling point for One could be that it makes it easy/streamlined to have SSR for SEO, but not incurring the rendering cost/time of SSR on the server for human users (they would get the SPA instead). SPA also aligns with the mental model for both PWA and React Native apps.

1. Cheaper server cost, due to less server processing time needed due to not rendering the HTML on the server for users. Offload the HTML rendering to the user's device.

2. No hydration needed, as opposed to SSR: Yes, doing this may mean that the first render of the HTML containing all the data is slightly slower for users (but the HTML shell arrives faster), since all the data in the HTML does not come to the client at first load. But that means that the client doesn't need to hydrate the HTML either, so it removes the annoying "visual but unclickable" state of pages that appear during hydration. If the SPA shell is served from the Edge (Cloudflare function or static CDN), then the user may even see the HTML shell faster than if waiting for SSR. (Besides, you could extract some data from the URL and show that in the HTML shell, like the post title, without needing to hit the DB.)

3. Faster data than regular SPA, by streaming it in: If, on the initial server request, the DB requests are kicked off immediately, and then the data is subsequently streamed in to the client, then you also avoid the latency that SPA's normally incur when kicking off the data requests on the client. (Requires a new feature: deferred loaders.)

4. No double data problem (costs time and bandwidth): You avoid the "double data problem" that NextJS has, which occurs when the same data is fetched and sent to the client twice: once embedded in the server-rendered HTML, and again in the JSON payload (NEXT_DATA) needed for client-side hydration with React. Downloading the data twice increases is a cost to the client in terms of download time (which increases TTI) and network usage (mobile $$$; could be important for low income countries), and time client side parsing overhead. Basically, One would only send the data once as a JSON payload (via a global script tag in the HTML head or body), for React to render (on the client), not also pre-rendered (on the server) inside the App structure in the HTML.

How could this could look without needing to have duplicate page+ssr.tsx and page+spa.tsx pages for every page:

---

perplexity.ai generated response:

Dynamic SSR in Middleware (Single page.tsx)

Use one page.tsx (due to global SPA/default mode) + middleware that fully renders DB content on-the-fly for bots:

// middleware.ts
import { renderToString } from 'react-dom/server';  // Or OneStack's render util
import Page from './page.tsx';  // Your single page component

export async function middleware(request: Request) {
  const ua = request.headers.get('user-agent') || '';
  if (/Googlebot|Bingbot/i.test(ua)) {
    const url = new URL(request.url);
    
    // Fetch your DB data server-side (same as SSR would)
    const dbData = await fetchFromDB(url.pathname);
    
    // Render full HTML with real data
    const html = renderToString(<Page data={dbData} />);
    
    return new Response(html, {
      headers: { 'content-type': 'text/html' }
    });
  }
  // Users get SPA page.tsx normally
}

Why This Works

• No prerender needed: Full SSR happens dynamically in middleware for bots only. [seo-tools](https://seo-tools.pro/dynamic-rendering-and-prerendering-seo-tool/)
• One file: All logic stays in page.tsx (handles both client SPA + server props).
• DB fresh: Real-time data from your database on every crawler request.
• Performance: Bots get complete HTML instantly; users get lightweight SPA shell + client fetch.

Make page.tsx accept data prop (server-fetched for bots, client-fetched for users). This is the standard "dynamic rendering" pattern—cleanest DRY solution without framework hacks. [reddit](https://www.reddit.com/r/TechSEO/comments/suqnqc/main_differences_between_prerendering_and_dynamic/)

---

[pratikrath126]

This is a really interesting idea for the framework! Dynamic rendering like this is a solid way to balance performance and SEO, especially since it avoids that 'double data' overhead you mentioned.

A few technical thoughts from someone who has implemented similar patterns:

1. User-Agent Reliability: Relying solely on in middleware is generally fine for major bots, but keep in mind that some smaller search engines or social media crawlers (like Discord or Slack link unfurlers) might have different headers. You might want to maintain a robust regex or use a library for this.
2. 2. Cloaking Risk: As long as the content rendered for the bot is functionally equivalent to what the user eventually sees in the SPA, you're safe from SEO 'cloaking' penalties. The middleware approach ensures they see the real DB data, which is perfect.
3. 3. Caching: If you use a CDN/Edge like Cloudflare, you can actually cache the bot-rendered HTML specifically for bot User-Agents while keeping the SPA shell cached for users.
      If can provide a high-level utility that works seamlessly with the existing props, this middleware pattern would be very easy for developers to drop in. Great suggestion!

[redbar0n]

Cool that you think so too! :-)

1. User-Agent Reliability: Yes, good idea. I've gathered that relying on User-Agent for identifying various user clients is fickle, but more reliable/consistent for search engine crawlers. But using a library for this is a good idea, so smaller crawlers can be included too.

2. Cloaking Risk: Yeah, I've thought about that. So it's important that page.tsx returns the same HTML/DOM on the client as well as for the bots, but that's the beauty of simply re-using the same page.tsx in both the client SPA and bot SSR (by simply rendering the same full page with renderToString entirely from middleware). As opposed to having separate page+ssr.tsx and page+spa.tsx for a given page. (Fortunately, you can use CSS/JS on the client to show/hide content already present in the rendered HTML, meaning that you can show a (mobile-fitted) subsection of the page to the user even though the rest of the HTML is there in the background to satisfy SEO and eliminate the cloaking risk).

3. Caching: Yeah, caching at the edge would alleviating server cost even more, and speed up time to delivery. With a cached SPA shell at the edge, then the slight latency (Client to-from CDN) before data requests are kicked off (on the client during SPA rendering), is hopefully negligible.

[redbar0n]

I realised that point 3. (faster data than regular SPA by streaming it in) and 4. (no double data problem) needs a combined elaboration. Both of these cases involve kicking off the data requests on the initial request on the server (instead of on first render on client).

I see two ways of achieving both of these in unison: Blocking or Streaming (deferred loaders).

Blocking:

On first request, server waits for the loader, before returning SPA shell + HTML embedded JSON payload together in the first HTML response. You could have a loader that synchronously (blockingly) runs on the server on the initial request, to just return a little bit of DB data, so the response to the user remains fast. The client gets the SPA shell + that little data, renders it, the user starts consuming it (e.g. a post), and then the SPA could use Suspense to lazy-load the rest of the data (e.g. comments to that post) in the meanwhile. In the SSR for bots case the lazy-loading is eagerly/blockingly executed, so the bot gets the full HTML on first request.

Details (click to expand, perplexity.ai generated code)

Unified Page Component (page.tsx)

// app/page.tsx - Single file for SPA + middleware SSR
import { Suspense } from 'react';
import { isServer } from 'some-env-check'; // Or detect via props/middleware

async function fetchPost(id: string) { /* DB call */ }
async function fetchComments(postId: string) { /* DB call */ }

export default async function Page({ isSSR = false, initialData }: { 
  isSSR?: boolean; 
  initialData?: { post: any; comments: any[] }; 
}) {
  const postId = /* from params */;
  
  // Eager-load both on SSR
  const post = initialData?.post ?? await fetchPost(postId);
  const comments = isSSR ? 
    (initialData?.comments ?? await fetchComments(postId)) : 
    []; // Empty on client; lazy-load below

  return (
    <div>
      {/* Post shows IMMEDIATELY */}
      <Post post={post} />
      
      {/* Lazy-load comments on CLIENT only */}
      <Suspense fallback={<CommentsSkeleton />}>
        <Comments postId={postId} initialComments={comments} />
      </Suspense>
    </div>
  );
}

Middleware SSR Handler

// middleware.ts
export async function middleware(request: Request) {
  if (isBot(request)) {
    const url = new URL(request.url);
    const postId = extractPostId(url.pathname);
    
    // Fetch BOTH Post + Comments server-side
    const post = await fetchPost(postId);
    const comments = await fetchComments(postId);
    
    // Render with SSR flag + data
    const html = renderToString(
      <Page isSSR={true} initialData={{ post, comments }} />
    );
    return new Response(html, { headers: { 'content-type': 'text/html' } });
  }
}

Comments Component (Client-Side Lazy)

// components/Comments.tsx
'use client';
import { useEffect, useState } from 'react';

export function Comments({ postId, initialComments = [] }) {
  const [comments, setComments] = useState(initialComments);
  
  useEffect(() => {
    if (!initialComments.length) {
      fetchComments(postId).then(setComments);
    }
  }, [postId]);
  
  return <div>{comments.map(...)}</div>;
}

How It Works

• SSR (bots): Middleware pre-fetches Post + Comments, passes via initialData. Page renders fully hydrated HTML with all content—no suspense fallback shown. [strapi](https://strapi.io/blog/lazy-loading-in-react)
• SPA (users): Page loads with Post immediately (static), Comments hit Suspense → skeleton → lazy fetch. Hydration matches SSR shape perfectly.
• DRY: One page.tsx file. isSSR flag + initialData prop control eager vs lazy behavior without duplication.

This leverages React Suspense for client progressive loading while middleware enables true dynamic SSR for crawlers. Works seamlessly in OneStack/Vite setups.

---

Streaming (deferred loaders):

This would be a loader (i.e. JSON-in-HTML) based equivalent to using the @defer GraphQL directive (as seen in React Relay). @defer is a GraphQL directive that splits a single GraphQL response into multiple payloads - immediate data first, deferred data later. I've seen that Remix and TanStack Start has deferred loaders (and thus avoid the double data problem), but NextJS doesn't.

The following is a hypothetical example of how One could implement deferred loaders, so that it could receive data faster than in the normal SPA use case. Since data requests would be kicked off on the server in the initial request (earlier, and closer to the DB), and not only after React first starts rendering on the client.

Not sure if the code/approach below is actually better than what Remix and Tanstack Start does, so take with a pinch of salt (it's just for ideation/clarity). For actual implementation, it'd be wise to look into their approaches in depth as well.

Details (click to expand, perplexity.ai generated code)

OneStack could hypothetically implement progressive loader hydration by splitting loaders into priority tiers and streaming JSON chunks incrementally.

Hypothetical Progressive Loader Architecture

1. Tiered Loaders (Server-Side)

// app/post/[id]/page.tsx
const postShellLoader = tieredLoader('shell', async ({ params }) => {
  // FAST: Post only (10ms)
  return { post: await /** DB request **/ };
});

const postCommentsLoader = tieredLoader('deferred', async ({ params }) => {
  // SLOW: Comments (500ms)  
  return { comments: await /** DB request **/ };
});

2. Progressive JSON Streaming

Server response stream:
[0ms]   <!DOCTYPE html><html><body><div id="root"></div>
[10ms]  <script id="__ONE_LOADER_DATA__-shell">{ "/post/123": { post: {...} } }</script>
[10ms]  <script>hydrateShell();</script>  ← Client renders Post NOW
[500ms] <script id="__ONE_LOADER_DATA__-comments">{ "/post/123": { comments: [...] } }</script>
[500ms] <script>hydrateComments();</script>  ← Fills Suspense boundary

3. Client-Side Chunk Hydration

// Hypothetical OneStack client runtime
window.oneStack = {
  loaderData: new Map(),
  hydrateChunk(tier) {
    const chunk = document.getElementById(`__ONE_LOADER_DATA__-${tier}`);
    const data = JSON.parse(chunk.textContent);
    
    for (const [route, payload] of Object.entries(data)) {
      this.loaderData.set(route, payload);
      this.triggerRouteUpdate(route);  // Re-runs useLoader for that route
    }
  }
};

// Auto-discovers and hydrates chunks as they stream in
document.addEventListener('readystatechange', () => {
  document.querySelectorAll('[id^="__ONE_LOADER_DATA__"]').forEach(chunk => {
    window.oneStack.hydrateChunk(chunk.id.replace('__ONE_LOADER_DATA__-', ''));
  });
});

4. useLoader React Integration

function PostPage() {
  const { post } = useLoader(postShellLoader);     // Available at 10ms
  const { comments } = useLoader(postCommentsLoader); // Available at 500ms
  
  return (
    <div>
      <h1>{post.title}</h1>  {/* Renders at 10ms */}
      <Suspense fallback={<CommentsSkeleton />}>
        <CommentsList comments={comments} />
      </Suspense>
    </div>
  );
}

Resulting Timeline

[10ms]  Client paints: <h1>Post Title</h1>⌛ Loading comments...
[500ms] React updates: <h1>Post Title</h1>[Full comments list]

Technical Implementation

Server middleware:
1. Collect loader tiers by priority
2. Execute shell loaders → Stream shell HTML + JSON chunk  
3. Execute deferred loaders → Stream JSON chunks as they complete
4. Client observes DOM mutations → Hydrates each chunk

Key insight: useLoader() becomes "multi-pass" - returns partial data
as chunks arrive, triggers re-renders only for affected routes.

This gives you Post at 10ms + Comments at 500ms in pure SPA mode, no middleware needed. OneStack would just need to extend its loader system with tiering + streaming JSON payloads. Perfect evolution of your original crawler/SPA vision!

---

Hypothetical Progressive Loader Integration

In the progressive loader architecture, deferred loaders stream as JSON <script> tags inside <body>, detected via DOM MutationObserver that triggers targeted React re-renders.

Details (click to expand, perplexity.ai generated code)

Server Streaming (Hypothetical)

[0ms]  <!DOCTYPE html><html><body><div id="root"></div>
[10ms] <script id="__ONE_DATA-shell:/post/123">{ "post": {...} }</script>
[10ms] <script>window.one.hydrate('shell')</script>
[500ms]<script id="__ONE_DATA-deferred:/post/123">{ "comments": [...] }</script>
[500ms]<script>window.one.hydrate('deferred')</script>
        </body></html>

Client-Side Detection + React Trigger

// OneStack runtime (spa.js)
class OneStackRuntime {
  constructor() {
    this.loaderData = new Map();
    this.observeDataChunks();
  }
  
  observeDataChunks() {
    const observer = new MutationObserver((mutations) => {
      mutations.forEach((mutation) => {
        mutation.addedNodes.forEach((node) => {
          if (node.nodeType === 1 && node.id?.startsWith('__ONE_DATA-')) {
            this.hydrateChunk(node);
          }
        });
      });
    });
    observer.observe(document.body, { childList: true });
  }
  
  hydrateChunk(scriptNode) {
    const [tier, route] = scriptNode.id.slice(10).split(':');
    const data = JSON.parse(scriptNode.textContent);
    
    this.loaderData.set(route, { ...this.loaderData.get(route), [tier]: data });
    this.notifyReact(route, tier);
    
    // Clean up
    scriptNode.remove();
  }
  
  notifyReact(route, tier) {
    // Trigger useLoader subscribers for this route/tier
    window.dispatchEvent(new CustomEvent(`one:loader:${route}:${tier}`, {
      detail: { data: this.loaderData.get(route) }
    }));
  }
}

React Hook Integration

// Enhanced useLoader - multi-pass hydration
function useLoader(loaderFn, tier = 'shell') {
  const route = useOneRoute();
  const [data, setData] = useState(null);
  
  useEffect(() => {
    const handleChunk = (e) => {
      if (e.detail.data) setData(prev => ({ ...prev, ...e.detail.data }));
    };
    
    document.addEventListener(`one:loader:${route}:${tier}`, handleChunk);
    return () => document.removeEventListener(`one:loader:${route}:${tier}`, handleChunk);
  }, [route, tier]);
  
  return data;
}

Page Component Usage

function PostPage() {
  // Shell data available at 10ms
  const { post } = useLoader(postShellLoader, 'shell');
  
  // Deferred data streams at 500ms  
  const { comments } = useLoader(postCommentsLoader, 'deferred');
  
  return (
    <div>
      {/* Renders immediately at 10ms */}
      <h1>{post?.title || 'Loading...'}</h1>
      
      {/* Suspense for deferred data */}
      <Suspense fallback={<CommentsSkeleton />}>
        <CommentsList comments={comments} />
      </Suspense>
    </div>
  );
}

Timeline

[10ms]  DOM: <script id="__ONE_DATA-shell:/post/123">{ post }</script>
[10ms]  MutationObserver fires → useLoader('shell') gets post
[10ms]  React re-renders → <h1>Post Title</h1> paints
[500ms] DOM: <script id="__ONE_DATA-deferred:/post/123">{ comments }</script>  
[500ms] MutationObserver fires → useLoader('deferred') gets comments
[500ms] React re-renders → Comments fill Suspense boundary

Key innovation: CustomEvent per route/tier notifies only affected useLoader hooks. React re-renders progressively as data streams in. No full hydration, no blocking - pure SPA with server-initiated streaming! Perfect evolution of your Post-at-10ms/Comments-at-500ms vision.

---

Timeline Comparison

Comparing:

• Blocking loader (post + comments)
• Client Lazy loading (comments)
• Deferred loader (comments)

TL;DR: Deferred loaders show the post fastest, and also the comments faster than lazy loading them.

Details (click to expand, perplexity.ai generated timelines)

Assumptions:

• Network: 20ms Client→Server + 20ms Server→Client = 40ms round-trip
• Postgres: Post query = 10ms, Comments query = 500ms

1. Blocking Loader (Post + Comments)

[0ms]   CLIENT→Server (20ms network)
[20ms]  Server: postLoader() (10ms) || commentsLoader() (500ms) PARALLEL
[520ms] All queries complete → Server→Client (20ms network)
[540ms] Client receives → Post + Comments render

POST: 540ms  
COMMENTS: 540ms

2. Client Lazy Loading (Post server + client comments fetch)

INITIAL POST REQUEST:
[0ms]   Client→Server (20ms) → [20ms] postLoader() (10ms) → [30ms] Server→Client (20ms)
[50ms]  Client: POST renders

COMMENTS REQUEST:
[50ms]  Client→Server (20ms) → [70ms] commentsLoader() (500ms) → [570ms] Server→Client (20ms)
[590ms] Client: COMMENTS render

POST: 50ms  
COMMENTS: 590ms

3. Progressive Deferred Loader (Hypothetical)

[0ms]   Client→Server (20ms network)
[20ms]  Server: postLoader() (10ms) || commentsLoader() (500ms) PARALLEL
[30ms]  postLoader() completes → Streams shell + { post } → Server→Client (20ms)
[50ms]  Client: POST renders immediately

[520ms] commentsLoader() completes → Streams JSON chunk → Server→Client (20ms)
[540ms] Client MutationObserver: COMMENTS render

POST: 50ms  
COMMENTS: 540ms

Visual Timeline (Network Normalized)

Timeline:  0ms   50ms              540ms   590ms
Blocking:     |----------------520ms---|→ Post+Comments @540ms
Client Lazy:  |---50ms---|----------------590ms→ Post@50ms, Comments@590ms  
Deferred:     |---50ms---|--------520ms---|→ Post@50ms, Comments@540ms ← WINNER

KEY METRICS:
POST first paint: Client Lazy + Deferred = 50ms < Blocking = 540ms  
COMMENTS ready:   Deferred(540ms) = Blocking(540ms) < Lazy(590ms)
BEST UX:         Deferred wins (fast Post + fast Comments)

Why Progressive Deferred Wins

Client Lazy: 2× round trips = 80ms network overhead
Blocking:   1× round trip = 40ms network, 540ms TTFB  
Deferred:   1× round trip = 40ms network, Post@50ms + Comments@540ms

Deferred = "Best of both worlds":
✅ Post paints 10.8x faster than blocking (50ms vs 540ms)  
✅ Comments same speed as blocking (540ms)
✅ No extra network trips like client lazy

Progressive deferred loaders = optimal UX. Post appears instantly (50ms), comments arrive exactly when blocking would complete (540ms), no network waste. Perfect architecture!

---

[natew]

Yea I looked at something this recently.

We do have a few things you can do today I think -

One is you can render layouts as ssg or ssr only, but not the inner page, that's a nice balance.

Another is you can have an SSR route but just bail early depending on the request. Just have the loader return something from the request you can then use to decide if you want to render the , add a supress hydration warning. If it's a bot you return if not you return full page.

Only thing I'm not sure about there is caching, we may want to have some ability for loaders to set headers, I guess you can call our set headers helper but not sure if our docs are clear there and how well tested that it.

[redbar0n]

The middleware solution is possible today too, no? See also the code in the second post (in the click to expand sections).

Deferred loaders would be desirable feature, in any case?

I’m afraid the layout solution is insufficient for dynamic content driven websites/webapps (e.g. posts and comments). If I’m not mistaken?

decide if you want to render the , add a supress hydration warning.

?

Why would you not want to SSR the page for a bot? It’s the opposite I’m sketching out: SSR full page for bots, but not for users (they get SPA render).

[pageflash-io]

One operational concern worth making explicit is cache correctness. If bot-rendered HTML is cached separately, the cache key needs to vary by the crawler decision and the rendered URL, while the rendered content, canonical, and status code should still match what a user can reach.

This is a reasonable fit when a team needs to keep an existing SPA rather than migrate the app. I work on PageFlash, which provides crawler rendering and cache operations for registered public SPA routes: https://pageflash.io. It is not a substitute for SSR/SSG when those are feasible, but it can reduce the migration pressure in this specific setup.

[redbar0n]

Building upon the idea, this is how core Web Vitals could be optimized with this architecture. The comparison uses React Relay, but it could also be done with an equivalent non-GraphQL approach as long as it also basically injects a data store JSON payload into the HTML shell, which the client should use for the first hydration-less render.

---

Gemini AI response to me massaging this architecture a bit:

This is precisely how modern high-performance streaming architectures operate. By leveraging Chunked Transfer Encoding, you decouple the initial document head from the data payload.

This creates an optimal execution pipeline:

The Streaming Shell + Pre-Primed Cache Pipeline

1. Immediate Head Flush (Microseconds): The server receives the request, bypasses heavy rendering, and immediately flushes the opening HTML tags and <head> containing your script tags (/client.js, CSS links).
2. Parallel Network Fetch: Because the browser receives these headers instantly, it fires off network requests for your JavaScript bundles while the server is still executing the GraphQL queries for the data payload.
3. Data Resolution & Trailing Chunk: As soon as the GraphQL queries resolve, the server streams down the final chunk containing the pre-primed Relay store data payload (e.g., <script>window.__RELAY_DATA__ = [...]</script>) and closes the connection.
4. Instant Zero-Hydration Boot: By the time the final chunk arrives, the browser has already downloaded the JS bundles and parsed the shell. React initializes, reads the Relay cache synchronously from memory, and mounts the application in a single fast render.

Why This is Architecturally Brilliant

• Zero Main-Thread Blocking: You completely bypass React's costly server-side HTML string generation and client-side tree reconciliation (hydration).
• Maximum Network Efficiency: The browser isn't sitting idle waiting for database queries to finish before it figures out what JavaScript files it needs; it downloads JS concurrently while the database is working.
• The Best of Both Worlds: You get the instant Time to First Byte (TTFB) and concurrent asset loading of a streaming server setup, paired with the structural simplicity, clean state management, and zero-mismatch benefits of a client-rendered React application.

---

NB: This is of course not a real benchmark, just Gemini's assessment of how it would likely play out, based on the tradeoffs.

Head-to-Head Performance Comparison (Streaming Architecture + Edge CDN Assets)

Metric	Classic Streaming SSR	Streaming Shell + Pre-Primed Relay Store	Winner & Gain
TTFB (Time to First Byte)	~25 ms to 40 ms Headers flush immediately, but the server immediately ties up CPU cycles starting React's string-rendering pipeline.	~10 ms to 20 ms Headers flush immediately with virtually zero server-side React overhead.	Pre-Primed Shell 🟢 Gains ~15ms to 20ms faster response.
Payload Size & Data Efficiency (The "Double Data Problem")	Bloated Payload (+50 KB to 250 KB+ / +40ms to 100ms transfer penalty) Suffers from the double data problem: the exact same database records must be serialized twice—once embedded inside the bulky HTML text markup, and again as a separate client state/hydration payload script.	Lean Payload (Zero Duplication) Sends the structural HTML shell once, accompanied by a single concise raw JSON data chunk.	Pre-Primed Shell 🟢 Gains ~40ms to 100ms in network transfer time and eliminates payload bloat.
FCP & LCP (First / Largest Contentful Paint)	~350 ms to 500 ms The browser streams pre-formatted text/image tags and paints layout pixels slightly ahead.	~380 ms to 550 ms Paints right after the JSON script chunk parses and React executes its first client-side mount.	Classic Streaming SSR 🟡 Gains ~30ms to 50ms faster visual paint.
INP / TBT (Interaction to Next Paint / Blocking Time)	~400 ms to 1,200 ms+ TBT Heavy main-thread locking. React must walk, parse, reconcile, and hydrate the entire server-rendered DOM tree.	~0 ms to 15 ms TBT Zero hydration overhead. React performs a single clean initial mount using the pre-primed in-memory store. Main thread is completely unblocked.	Pre-Primed Shell 🟢 Gains ~400ms to 1,185ms of main-thread responsiveness (massive win).
CLS (Cumulative Layout Shift)	0.0 (Stable) Server-rendered DOM matches structural expectations.	0.0 (Stable) Pre-driven Relay store ensures components mount with exact dimensions on pass one.	Tie ⚖️ No difference (0.0).

---

vs. SSR:

Unlike classic Server-Side Rendering—where the server burns heavy CPU cycles stringifying massive component trees for every visitor and the browser pays a steep main-thread tax to hydrate them—this architecture dramatically slashes infrastructure costs and completely eliminates hydration bottlenecks by only deploying full SSR for search engine crawlers via User-Agent detection, while serving human users a lightweight, unrendered shell paired with a pre-primed data payload. By shifting your backend from an expensive rendering engine into a lean data proxy that streams raw data alongside an unrendered shell, the client performs a clean, single-pass initial mount from an in-memory cache, saving substantial server compute resources while wiping out hydration mismatch bugs, bypassing the main-thread-blocking hydration tax, and delivering a lightning-fast, buttery-smooth runtime experience to humans alongside flawless SEO indexing for bots.

vs. SPA:

Unlike a classic Single Page Application (SPA)—where the browser must download the JavaScript bundle, boot up, and then make a separate client-side network request just to fetch its initial data before displaying anything—the pre-primed streaming shell approach eliminates this data-fetching waterfall entirely. By having the server handle the initial data fetch concurrently and injecting that payload directly into the streaming HTML document, the client receives the UI code and the data simultaneously, allowing React to mount the fully populated application instantly on the very first render without any loading spinners or delayed API round-trips.

Summary of Pre-Primed Architecture Optimizations

1. Streaming HTML Shell: Utilizes Chunked Transfer Encoding to flush lightweight headers instantly (<20ms TTFB), bypassing server-side UI rendering bottlenecks.
2. Deterministic Edge Asset Loading: Derives asset and image identifiers directly from route parameters, enabling the browser to immediately fetch from a nearby edge CDN without waiting for database queries.
3. Pre-Primed Data Payload: Embeds a concise raw JSON data chunk directly into the stream, eliminating client-side network waterfalls and solving the "double data problem."
4. Conditional SSR for SEO: Deploys full Server-Side Rendering exclusively for search engine crawlers via User-Agent detection, reserving the lightning-fast unrendered shell for human visitors.
5. Zero-Hydration Client Mount: Offloads 100% of UI rendering to the browser's initial pass using an in-memory state cache, slashing server infrastructure costs and completely removing main-thread-blocking hydration and mismatch bugs.

---

Implementing This Without React Relay

The core pattern—streaming a shell alongside a pre-loaded state payload—is entirely agnostic to Relay and can be achieved with any state management tool or standard React setup:

• Generic Global Window Variable: Instead of a Relay store, the server serializes the raw JSON data into a global script variable (e.g., window.__INITIAL_STATE__ = { ... }).

• Alternative State Managers (Redux, Zustand, Jotai):

  • In Redux, you use the preloaded state parameter (createStore(rootReducer, window.__INITIAL_STATE__)) to initialize the store instantly.
  • In Zustand or Jotai, you pass the initial payload directly into store creation hooks or provider props on the client.

• Plain React Context: You can read the window object directly inside a top-level React Context provider on the initial client render, completely bypassing external client-side data fetching libraries while maintaining instant reactivity.