On this page

RSC Caching

Rebask caches server-rendered React Server Components (RSC) payloads separately from page HTML. These payloads power navigations, prefetches, and page updates, while the client uses them to update or populate its route segment cache.

How RSC caching works

RSC caching lets Rebask reuse a rendered server component payload instead of rendering it again for every cacheable RSC request. The cache serves page and layout payloads for navigations, prefetches, and page updates, separately from page HTML.

RSC requests
GET /products/42
Page payload
GET /_rebask/1
Root layout payload
GET /_rebask/1/products
Products layout payload
Server RSC cache
pr:<deployment-id>:<pathname>
HIT
Reuse the cached payload
STALE
Serve it and refresh in background
MISS
Render, then cache if eligible
Segment Cache
Populate client cache

An RSC response can contain the full payload or a complete or partial shell. A partial shell is the static prefix of the payload and the tail is the dynamic rest. A complete shell contains the whole payload.

Full payload
Full RSC payload
single response
Partial shell
Static prefix
Dynamic tail
tail fetched later
Complete shell
Complete shell
no tail

RSC shells

Full payloads use the cache key pr:<deployment-id>:<pathname>. Shells use separate keys:

  • Shared: ps:<deployment-id>:<route-file>, reused across parameter values.
  • Individual page: ps:<deployment-id>:<route-file>:<pathname>, tied to one pathname.

Shells have their own cache lifetimes and tags.

When the client has a partial shell, Rebask re-renders the segment for the tail and checks that the static prefix still matches. If it does not, Rebask returns the full payload instead. The tail response is rendered for each request and is not added to the RSC cache.

Unlike the HTML page shells in Page Caching, RSC shells fill the client segment cache and supply tails for navigations rather than resuming a document. See Segment Caching for how the client stores and reuses them.

RSC cache lifetimes and invalidation

Rebask looks up an RSC entry before rendering a payload. A fresh entry returns HIT, a stale entry can be served as STALE and Rebask schedules a background revalidation. On a MISS, Rebask renders the payload and writes it to the cache when the render is cacheable.

Uncacheable renders, including those that read request I/O, are still returned to the client but are not written to the server RSC cache.

See Cache Lifetimes for the concepts and APIs.

See Cache Handler to configure a custom server cache storage implementation.