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).