Why RenderCache Is Called RenderCache

The name is the design, in two words.

Render. A JavaScript app sends a crawler an almost empty page and expects a browser to build the rest. Most AI crawlers never do that part, so they read the shell. RenderCache does it for them: it opens the page in a real Chrome, waits until the app says it’s ready, and takes the finished HTML. No guessing at what the page would have looked like. The browser actually ran it.

Cache. Rendering a page costs seconds and a browser process. Doing that while a crawler waits is the wrong trade, so RenderCache renders ahead of time, from the sitemap, and keeps the result on disk. A crawler gets the saved copy at once. When the copy gets old it’s still served while a fresh one renders in the background, and if the refresh fails the old copy stays.

Put the two together and you have the product. Most of the hard work sits in the gap between the words: what counts as a public page that may be cached at all, what happens on the very first request before anything is saved, and what to do when the origin falls over. A page that sets a cookie or needs a login is never cached. The first request goes straight to the origin and queues a render instead of making anyone wait. A failed refresh never throws away a good copy.

A cleverer name would need a sentence of explanation. This one doesn’t: if you run a JavaScript site and want crawlers to see what people see, RenderCache says what it does. See the difference on a real page, or run it yourself.