RenderCache.com

Warm before the crawler arrives

Fri, 16 Oct 2026 18:00:00 +0300

The difficult request is the first one. If a crawler reaches a JavaScript page before a snapshot exists, starting Chrome at that moment adds work to an already waiting client. RenderCache’s alpha takes a different starting point: discover the public URLs from the sitemap, then render them before requests need the saved HTML.

The worker queue is bounded. Missing pages get priority, refreshes are scheduled, and repeated work for a page is deduplicated. That does not make coverage automatic: an empty sitemap, a failed browser or a wrong readiness selector can leave pages without useful snapshots. The status page therefore shows what is discovered, cached, missing, queued and failing, with request-added pages reported separately.

Know which response left your server

Fri, 16 Oct 2026 18:00:00 +0300

A cache hit does not necessarily mean a page body was delivered. A HEAD request can use a saved response and write zero HTML bytes. A conditional request can return 304. Redirects and removals preserve their own status, and a partial write can stop before the saved document is complete.

RenderCache records response receipts after handling a recognized crawler claim. Cached response availability and full snapshot HTML are separate fields, alongside the method, actual status, cache outcome and body bytes accepted by the writer. Private and API bypasses are also visible when their traffic passes through the Go service. Selective edge routing can narrow that visibility, so the deployment topology matters.

The alpha you can run today

Fri, 16 Oct 2026 18:00:00 +0300

The first RenderCache alpha is available as a Linux amd64 archive with SHA-256 checksums and matching engine source. It keeps the runtime small in one specific sense: one Go service executable manages the reverse proxy, disk store, warm queue, receipts and protected admin app. Chrome is still a separate process and dependency. The Dockerfile installs Chromium for container deployments.

The release pipeline checked the actual rendering path, rather than stopping at compilation. Race-enabled tests use real Chrome. The container check warms a page under a non-root user with restricted resources and filesystems, using an explicit sandbox opt-out inside an isolated test network. The nginx example is exercised against the executable, and the archive is rebuilt deterministically before its extracted binary is tested.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

For questions, support and project enquiries, email info@rendercache.com.

You can also report reproducible bugs, request features or share deployment feedback through the RenderCache engine issue tracker. Include the RenderCache version, operating system, browser version and the response you expected. Remove tokens, cookies, authorization headers and private content before sharing logs or configuration.

Deployment choices

Mon, 01 Jan 0001 00:00:00 +0000

The alpha supports a full reverse-proxy setup and selective crawler routing behind an existing edge. In both cases, the renderer needs a fixed route to the original application. It must not render its own frontend. This project website is static Hugo output and does not host a render backend.

Standalone reverse proxy

Put TLS termination in front of RenderCache’s public listener, configure the original app and public site root, and let Go classify document requests. Matching crawler claims can use the saved copy; humans and private/API requests continue to the origin. This gives the delivery log visibility into crawler bypasses as well as snapshot responses. Keep the separate admin listener on a private interface or secure tunnel.

Download the alpha

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache v0.1.0-alpha.1 is available for Linux amd64. It is an evaluation alpha. The standalone executable needs a separately installed, maintained Chrome or Chromium; the repository’s Dockerfile installs Chromium in its runtime image.

Linux amd64 archive SHA256SUMS

Release notes and matching source tag are on GitHub. The engine is licensed under Apache 2.0. Its binary archive includes dependency notices, a sample configuration, and deployment instructions.

Verify before extracting

Download the archive and checksum file into the same directory, then run:

How RenderCache works

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache sits between crawler requests and a fixed origin. A normal visitor receives the original application. A matching crawler request can receive an eligible saved response from disk. User agents are configurable routing claims; they are not authenticated bot identities.

Start with the sitemap

The service discovers pages from your sitemap and schedules missing or expired snapshots through a bounded queue. Chrome loads each page on the configured origin, waits for a readiness selector or a settling delay, and captures the rendered document. The snapshot preserves structured data while removing executable scripts and inline event handlers. Chrome is an external process; the Go executable does not contain a browser.

Questions about RenderCache

Mon, 01 Jan 0001 00:00:00 +0000

Do all AI crawlers fail to run JavaScript?

Crawler capabilities differ and can change. RenderCache addresses requests that need useful HTML without executing your application. Its editable user-agent patterns are routing hints, not a universal claim about every crawler or a way to verify identity. Test the responses that matter for your own public pages.

Will this guarantee search ranking or AI citations?

No. It can make rendered content available in a response and record what the server wrote. A receipt does not prove a crawler read the body, indexed it or used it in an answer. Reachability, robots rules, canonical metadata, content quality and each service’s policies still matter.

Run RenderCache

Mon, 01 Jan 0001 00:00:00 +0000

Start on Linux amd64 with a maintained Chrome or Chromium installation. Download and verify the alpha, then run it as an unprivileged user with its own writable data directory. Use a public origin whose pages do not require a login. The Chrome sandbox is enabled by default.

Point it at the app

Replace the sample addresses, browser path, and readiness selector with values for your application. origin must reach the original app directly; pointing it back at the RenderCache frontend would create a loop. The selector should appear when the page’s useful content is actually ready.

Status and roadmap

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache v0.1.0-alpha.1 is a working Linux amd64 evaluation release. It includes the Go reverse proxy, Chrome rendering, atomic disk snapshots, sitemap warming, stale-while-revalidate serving, private-response withdrawal, authenticated purge, shell diagnostics, rotating delivery receipts, and one protected status/comparison page. Storage quotas, explicit prune, directory locking and resource controls are included.

The release gates exercised real Chrome with race-enabled Go tests, a constrained non-root Chromium container, nginx routing, Cloudflare request logic, deterministic archives, checksum validation and the extracted executable. Sandbox operation on your host still needs verification. The browser-only website example is separate from the real admin comparison.

What the bot sees

Mon, 01 Jan 0001 00:00:00 +0000

The example below starts with the same JavaScript fixture used by the project: its original page has an empty app container, and JavaScript fetches the article text. The bundled before-and-after capture comes from RenderCache v0.1.0-alpha.1. Words absent from the extracted raw text are highlighted in the rendered text.

This is an interactive illustration. Cache-state controls and generated receipts run in your browser; they do not query a server, run Chrome, change a cache, or show visits by real crawlers. The site has no public arbitrary-URL rendering endpoint.