Chapter 6: The Rendering & Front-End Layer

Partial Prerendering: the SSG-vs-SSR tradeoff collapses

PPR was experimental in Next.js 14, refined in 15, and shipped stable in Next.js 16 (October 2025) under the renamed cacheComponents: true config — the old experimental.ppr flag was removed (Next.js docs; Pockit, PPR Deep Dive). The mental model: everything outside a React <Suspense> boundary is part of the static, CDN-cached shell; everything inside streams in dynamically. Functions and components opt into caching with the new "use cache" directive.

// Static shell served instantly from the edge:
export default function ArticlePage({ params }) {
  return (
    <Article slug={params.slug} />        {/* "use cache" → static */}
    <Suspense fallback={<Skeleton />}>
      <ReaderStats slug={params.slug} />   {/* dynamic, streamed */}
    </Suspense>
  );
}

This is the closest the industry has come to "one rendering model to rule them all," and Vercel's own guidance is that PPR should be the default strategy for most new Next.js apps going forward (samcheek.com, PPR in Production 2026). The cost: it is React/Next-specific and adds conceptual overhead — you must reason carefully about which data is request-time vs build-time, and the failure mode (accidentally opting a whole route into dynamic rendering) silently destroys your cache hit rate.

Islands architecture and resumability — the anti-hydration camp

The opposing philosophy says: most of a content page is never interactive, so why ship and replay JavaScript for all of it? Islands architecture renders static HTML and hydrates only discrete interactive components ("islands"), with the rest as zero-JS HTML.

• Astro popularized this. Astro 5 (late 2025) made server islands stable — islands that server-render dynamic content separately from the static page, with per-island cache headers and automatically encrypted props (astro.build, Astro 5.0). Astro 6 (2026) deepened Cloudflare/edge integration.
• Fresh (Deno) is a Preact-based island framework with a JIT, zero build step (deno.com, Intro to Islands).
• Qwik goes further with resumability: instead of reducing hydration, it eliminates it. The server serializes app state into the HTML and the client "resumes" execution without replaying component code (patterns.dev). This yields near-zero startup JS regardless of app size, at the cost of a smaller ecosystem and a steeper mental model.

For an AI-native CMS, islands are attractive: the body of an AI-drafted article needs no JS, and a sidebar "ask the AI about this page" widget can be a single hydrated island. Astro routinely tops Core Web Vitals and SEO benchmarks for content sites precisely because it ships crawlable HTML with almost no JavaScript (Vero Scale, Astro/Svelte benchmarks).

Framework comparison (2026)

Two ecosystem shifts deserve attention because they affect long-term framework risk:

1. Remix merged into React Router. Remix v2 had become a thin wrapper over React Router, so the projects merged: "Remix" features now live in React Router v7 "Framework Mode" (loaders, actions, SSR, Vite compiler, type safety) (remix.run, Merging Remix and React Router). If you want the Remix DX with React, you choose React Router 7.

2. Remix 3 abandons React entirely. Announced May 2025, with a first stable release targeted for early 2026, Remix 3 is built on a fork of Preact, runs on Fetch API Request/Response primitives, favors "runtime over build steps," and explicitly optimizes its abstractions and docs for LLMs as a design principle (InfoQ; Appwrite, Remix 3). There is no migration path from Remix 2 (byteiota). This makes Remix 3 intriguing for an AI-native project philosophically, but bleeding-edge — not a safe production default in 2026.

Handling 1,000+ static pages without build-time pain

This is where many CMS front-ends die. A pure SSG build that renders every page at deploy time scales linearly: 1,000 pages might be tolerable, 10,000 painful, 50,000+ a multi-hour ordeal that blocks every editorial change. There are three viable patterns:

Pattern A — ISR with a hot/cold split (Next.js / Nuxt). Pre-render only the "hot" top ~1,000 pages at build time; serve the long tail on first request and cache it; revalidate everything on a TTL or webhook. For 50K+ page sites this is effectively the only practical approach besides truly incremental builders (PkgPulse; Vercel ISR docs). On Vercel, on-demand revalidation propagates across all regions within ~300ms.

// Next.js: pre-render hot pages, ISR for the rest
export async function generateStaticParams() {
  return getTopArticles(1000);          // build only the hot set
}
export const revalidate = 3600;          // background refresh hourly
// + call revalidatePath('/articles/[slug]') from a CMS webhook on publish

Pattern B — Incremental SSG (Eleventy, Astro caching). Eleventy builds only changed files incrementally, making it viable for very large static sites without server compute. Astro added a build cache, but for true publish-time freshness on huge catalogs you still bolt on ISR-like behavior via Cloudflare KV or an SSR adapter (launchfa.st, Astro ISR on Cloudflare KV).

Pattern C — On-demand SSR + aggressive CDN. Render everything server-side but cache responses with stale-while-revalidate headers. Nuxt's SWR route rule does exactly this: serve the cached response instantly, regenerate in the background when the TTL expires; ISR is the same but persists to the CDN on Vercel/Netlify (nuxt.com, Rendering Modes v4).

The decisive design rule for an AI-native CMS: never tie freshness to a full rebuild. Wire the CMS's "publish" event to an on-demand revalidation webhook (revalidatePath/revalidateTag in Next.js, a cache purge on Nuxt/Astro). Builds should be for code changes; content changes flow through revalidation. This is doubly important when an AI agent can publish dozens of pages per hour — a build-per-publish model would never keep up.

Preview, draft & visual editing modes

Editors must see unpublished content rendered with full styling before it goes live — and for an AI-CMS, a human reviewing AI-generated drafts is often the core workflow (the human-in-the-loop gate).

• Next.js Draft Mode is the reference implementation. A Route Handler calls draftMode().enable(), which sets a cookie; subsequent requests with that cookie bypass the static/ISR cache and switch to dynamic rendering, fetching the latest (draft) content from the CMS at request time (nextjs.org, Draft Mode). Headless CMSs — DatoCMS, Storyblok, Sanity, Optimizely — ship official integrations; Storyblok's Visual Editor appends _storyblok URL params and combines its SDK with draft mode for live, click-to-edit preview.

• Astro's gap. Because Astro is SSG-first, it historically had no clean draft-preview story — previewing draft content requires switching to SSR mode at runtime, which Astro doesn't do as gracefully as Next.js or Nuxt (withastro/roadmap discussion #564). The practical workaround is a separate SSR-mode preview deployment, or using server islands to fetch draft content dynamically. This is a real, often-overlooked cost of choosing Astro for an editor-heavy CMS.

• Nuxt supports preview via runtime config and the usePreviewMode composable plus routeRules to force SSR on preview routes.

For the AI angle specifically, the preview surface is where you expose provenance and confidence: render AI-drafted sections with a visible "AI-generated, unreviewed" badge in draft mode that disappears on publish, and consider a side-by-side diff of the AI draft vs. the human-edited version. The rendering layer is the natural place to enforce these editorial guardrails.

Rendering for AI consumers, not just browsers

A 2026 CMS front-end must render for three audiences: humans, search crawlers, and LLM crawlers / agents. This reframes the SSG-vs-SSR debate:

• Server-rendered HTML wins for AI discoverability. LLM crawlers and RAG pipelines parse HTML far more reliably than client-rendered React shells. SSG/SSR/islands all produce crawlable HTML; pure client-side SPA rendering is a discoverability liability.
• llms.txt — the emerging convention (a Markdown manifest at /llms.txt listing your key pages for LLM consumption) — is something your rendering layer should generate as a build artifact alongside sitemap.xml.
• Structured data (schema.org JSON-LD for Article, FAQPage, Product) should be emitted server-side in the document <head>; both Google and LLM extractors rely on it.
• Clean, semantic HTML from islands/SSG is easier for an agent to extract than deeply nested hydration markup — another quiet point in Astro's favor for content sites.

Key Takeaways

• Rendering is now a component-level decision, not a page-level one — Next.js PPR, Astro server islands, and Nuxt routeRules all let one page mix static, edge, and dynamic regions.
• PPR is stable in Next.js 16 (cacheComponents: true, "use cache") and is Vercel's recommended default; it collapses the historical SSG-vs-SSR tradeoff but is React-specific.
• Astro is the strongest choice for content-heavy, low-interactivity sites (zero-JS default, server islands, Content Layer), but has a genuine weak spot in draft/preview that matters for editor-driven CMS workflows.
• For 1,000+ pages, never rebuild on publish — pre-render the hot set, serve the long tail via ISR/SWR, and trigger on-demand revalidation from a CMS webhook (~300ms global purge on Vercel).
• Next.js Draft Mode is the reference preview pattern (cookie → bypass cache → dynamic draft render) with first-class headless-CMS integrations; Astro and Nuxt require more setup.
• The ecosystem split is real: Remix merged into React Router 7 (Framework Mode) for React users; Remix 3 drops React for a Preact fork (early-2026, no migration path, LLM-optimized — promising but bleeding-edge).
• SvelteKit ships the smallest bundles (15–30KB/route) with the cleanest mental model but lacks first-class ISR; Qwik eliminates hydration via resumability for near-zero startup JS at the cost of ecosystem maturity.
• Render for AI consumers too: server-rendered semantic HTML, JSON-LD, and an llms.txt build artifact make AI-generated content discoverable by the agents and crawlers that increasingly mediate readership.

Key References

• Next.js Team. Guides: Draft Mode. 2026. https://nextjs.org/docs/app/guides/draft-mode — Canonical implementation of cookie-based draft preview that bypasses ISR cache.
• Next.js Team. PPR / Cache Components. 2026. https://nextjs.org/docs/app/guides/ppr-platform-guide — PPR graduating to stable via cacheComponents in Next.js 16.
• Astro. Astro 5.0 release. 2025. https://astro.build/blog/astro-5/ — Content Layer API and stable server islands with per-island cache headers and encrypted props.
• Astro Docs. Islands architecture. 2026. https://docs.astro.build/en/concepts/islands/ — Definitions of client vs. server islands and partial hydration.
• Remix Team. Merging Remix and React Router. 2024. https://remix.run/blog/merging-remix-and-react-router — Why Remix v2 features moved into React Router v7 Framework Mode.
• InfoQ. Remix Reimagined: V3 Will Drop React for a Fork of Preact. 2025. https://www.infoq.com/news/2025/08/remix-run-v3-drops-react/ — Remix 3's Preact fork, Fetch-API-first, LLM-optimized design.
• Nuxt. Rendering Modes (v4). 2026. https://nuxt.com/docs/4.x/guide/concepts/rendering — routeRules for hybrid SSR/SSG/ISR/SWR and edge rendering via Nitro.
• Vercel. Incremental Static Regeneration. 2026. https://vercel.com/docs/incremental-static-regeneration — On-demand + time-based revalidation, ~300ms global cache purge.
• PkgPulse. Best Static Site Generators 2026. 2026. https://www.pkgpulse.com/guides/best-static-site-generators-2026 — Hot/cold split and which tools survive at 50K+ pages.
• samcheek.com. Partial Prerendering (PPR) in Production: Architecture Patterns (2026 Edition). 2026. https://samcheek.com/blog/nextjs-partial-prerendering-production-2026 — Production PPR patterns and the static-shell/dynamic-stream model.
• patterns.dev. Islands Architecture. 2025. https://www.patterns.dev/vanilla/islands-architecture/ — Islands vs. resumability (Qwik) vs. partial hydration distinctions.
• launchfa.st. Implementing ISR in Astro with Cloudflare KV. 2025. https://www.launchfa.st/blog/astro-incremental-static-regeneration-cloudflare-kv — Bolting ISR-like freshness onto Astro's SSG model.
• withastro/roadmap. Preview draft content from CMSs in static sites — Discussion #564. https://github.com/withastro/roadmap/discussions/564 — Documents Astro's structural draft-preview limitation.
• Storyblok. Enable Draft Mode in Next.js for the Visual Editor. 2025. https://www.storyblok.com/tp/nextjs-draft-mode-visual-editor — Visual editing / live preview pattern combining draft mode with a headless CMS SDK.
• Vero Scale. Astro/Svelte performance benchmarks. 2026. https://veroscale.au/insights/astro-svelte-performance-benchmarks/ — Bundle-size and Core Web Vitals comparison across frameworks.