A New Pattern For The Jamstack: Segmented Rendering — Smashing Magazine

Static Rendering For Paywalled Content

Static rendering, done once at build time, is generally the fastest way to deliver a page. The catch has always been personalization: content that depends on who is asking usually forces you into either client-side rendering or per-request server work. There is a middle path. Segmented Rendering treats different audiences as separate static pages, then uses lightweight server logic to pick the right one for each visitor.

Consider a blog where premium subscribers see an extra section inside every article. The requirements are simple: paying readers get the full HTML immediately, free users see a trimmed version, and nobody waits on a loader or a server round-trip.

Why Usual Rendering Patterns Fall Short For Paywalled Content

Modern JavaScript frameworks typically offer three rendering strategies, each with tradeoffs.

Client-Side Rendering: Loaders And Extra Round Trips

Rendering in the browser means fetching the premium content after the initial page load and injecting it into the DOM. This approach adds an ugly loading state, depends on JavaScript executing correctly, and multiplies the number of requests each visitor makes to your internal services. Script failures or slow mobile networks degrade the experience even for paying customers. ### Per-Request Server Rendering: Compute On Every Visit

Server-Side Rendering (SSR) can produce a tailored page for each visitor at request time. But doing that work on every hit increases Time To First Byte, since the server must finish rendering before the browser receives the first bytes. Caching strategies like stale-while-revalidate can mitigate that cost, but they fail for content gated by user status: one URL can only cache one version of the page, without accounting for cookies or security checks.

The net effect is that the users you most want to reward — paid subscribers — often get the slowest experience. That is the dilemma worth solving.

Static Rendering: Fast But Inflexible

Static Site Generation (SSG) renders each URL once at build time, and serves pure HTML that is identical for every visitor. That is the most performant option, and a core reason for the Jamstack movement's popularity. But the common implementation assumes one URL equals one page version. Once you need a paid and a free variant of the same article on the same URL, the pattern breaks down — you simply cannot tailor output. Segmented Rendering modifies that assumption by pre-rendering multiple variations of the same URL, each targeting a distinct audience segment.

How Segmented Rendering Works

The shift in thinking is to decouple the URL from the page variation. The first step is to enumerate the segments that matter — for instance, paid users versus free users, or visitors in different regions. Then you render one static page per segment, each exposed at its own URL.

In Next.js terms, you might generate:

• /with-jokes/how-to-fix-a-screen for premium users
• /bland/how-to-fix-a-screen for everyone else

Each variant is statically rendered, so the performance benefits remain intact. Next, you set up a tiny redirection layer that inspects the incoming request — typically cookies — and forwards the user to the correct variant URL. This logic sits at the edge, in servers close to the end-user.

Managing The Redirection Layer

Static hosting services, like GitHub Pages, hide the server entirely. That is fine for a personal site but insufficient for any logic that varies the response based on request data. Even in the so-called Jamstack, there is always a server; "static hosting" only means you cannot program it. To implement Segmented Rendering with clean URLs, take a bit of control back.

The required server code is minimal: check cookies or headers, then choose whether to show the premium or free version. No database calls, no per-request rendering. You can live without a cloud proxy if you use a host like Vercel or Netlify, both of which support Edge Handlers. Next.js exposes these as middlewares, coded in JavaScript via the standard fetch API. The "edge" placement means loading remains fast because the logic runs near the user, which is especially relevant when the personalization depends on location.

The cleanest setup uses URL rewrites instead of redirects. Rewrites point to the correct static file internally while leaving the public URL unchanged. Instead of showing /with-jokes/my-article, the visitor sees the standard /my-article, and the right content is selected based on their cookie.

Summary: Implementing The Pattern

1. Define your segments for a page. For example: paid users versus free users, or visitors from company A versus company B.
2. Render static variations for each segment, each at its own URL, like /with-jokes/my-article and /bland/my-article.
3. Set up a minimal redirection server that reads the HTTP request (such as cookies) and sends each user to the matching variation.

This approach reuses the same infrastructure and is applicable well beyond paywalled jokes — for internationalization, A/B tests, theming, or any other versioning that depends on the visitor. You gain the speed of static content without losing the behavior of a tailored experience.

Scaling Past Static Limits

Segmented Rendering removes the hard ceiling on static variations. You can now have as many versions of a page as you need—solving the paid-user problem without abandoning pre-rendered performance. But what happens when the parameter space explodes? Consider 5 parameters with 10 values each: 100,000 combinations. Build-time rendering of every permutation becomes impractical, and realistically, some variations won't even apply—no paid users in France on the light theme in A/B bucket B, for instance.

Modern frameworks offer an escape hatch. Intermediate patterns like Incremental Static Regeneration (Next.js) or Deferred Static Generation (Gatsby) let you render each variation only when a request actually arrives. This on-demand generation keeps build times sane while still delivering the right content to the right segment.

Personalization is a perennial hot topic, but it's often at odds with speed and energy efficiency. Segmented Rendering sidesteps that trade-off: it lets you statically render content for any audience—public or narrowly segmented—while preserving the benefits of the Jamstack architecture.

Where To Go From Here

The pattern has spawned a rich ecosystem of implementations and adjacent techniques. If you want to explore deeper, the following resources trace the idea from theory to production:

• Foundations: "Let’s Bring The Jamstack To SaaS: Introducing Rainbow Rendering" by Eric Burel covers the generic architecture behind Segmented Rendering. His follow-ups—"Treat Your Users Right With Http Cache And Segmented Rendering" (Next.js middleware implementation) and "Render Anything Statically With Next.js And The Megaparam" (HTTP-cache-only approach for Remix)—show practical variants.
• Origin Story: The GitHub discussion "Incremental Static Generation For Multiple Rendering Paths" on the Next.js repo is where the approach was first sketched out.
• Theoretical Proof: Burel's draft paper "Theoretical Foundations For Server-side Rendering And Static-rendering" describes the math behind SSR and argues that Segmented Rendering achieves the optimal number of renders in any scenario.
• Real-world Use: Two articles from Plasmic—"High Performance Personalization With Next.js Middleware" and "A/B Testing With Next.js Middleware"—demonstrate the pattern in action.
• Alternative Implementations: The Eleventy Edge blog shows a deep integration with Netlify Edge Handlers for personalization; the Vercel Platforms example applies segmented rendering to multi-tenant setups.
• Adjacent Best Practices: Sergio Xalambrí's "Avoid Waterfalls Of Queries In Remix Loaders" covers parallelizing data fetching, a common bottleneck when delivering segmented experiences.

For broader context on rendering patterns in modern web development, Smashing Magazine has covered the evolution of Jamstack rendering, state management in Next.js, the shifting role of CMSs in the Jamstack, and a full guide to Incremental Static Regeneration.