Basic client and server cache

[benjaminleonard]

Some RFD site perf improvements. Cached navs are much much faster.

• Skip root revalidation on GET navigations — the RFD list is kept in memory, so document → index is now instant. A background refresh keeps it from going stale: once the data is older than 5 minutes, the next navigation or window focus revalidates without blocking.
• Cache parsed asciidoc server-side, keyed by number:sha. Still sits behind the API's access check. Local mode is never cached. @augustuswm or @notpeter can you sense-check there's no security risk here?
• Stream the access-groups banner instead of blocking the document on fetchGroups (~150–250ms). An invisible placeholder reserves the banner's height so there's no layout shift when it resolves.
• Client-side cache for recently viewed documents — served while the document's content sha still matches the sha in the RFD list. Cleared on logout.

No auth changes: every first fetch of a document or list still goes through the API with the user's own token.

---

Comparison, top is fast cached version:

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
rfd-site	Ready	Preview	Jul 21, 2026 1:10pm

[augustuswm]

Root revalidation and groups seem like good optimizations. I'm not quite sure on the caching though. My initial thoughts:

1. Server caching looks like fine given that we are still asking the server for the document and we are only skipping the transform step. I'm not clear how effective this will be on Vercel though given that from my understanding they are executing this calls as functions that may or may not share state. Definitely recommend that we empirically verify this view a preview deployment as my thinking is we could get more erratic load times, some fast, some slow depending on when Vercel decides to re-use a function's state vs evict it.
2. I don't think a client cache without a user control to evict it is a good idea. Especially in the case that someone is checking to see their update go live. I think we can still find performance wins without introducing this, and should really leave this as a last resort.

[benjaminleonard]

Definitely recommend that we empirically verify this view a preview deployment as my thinking is we could get more erratic load times, some fast, some slow depending on when Vercel decides to re-use a function's state vs evict it.

Good point, I'll try a little test harness that runs this. Harder part might be capturing the intermittent aspect. Though I'd probably take significantly quicker responses on some responses, even at the cost of erratic loading.

I don't think a client cache without a user control to evict it is a good idea

One solution could be to use the client cache first then run a background refresh in the client loader so it's updated after the page is loaded? Just pushed a change. It's a high impact improvement, but I accept it might not be worth the complexity because it's only really working for cases where a user is revisiting an RFD.