<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on RenderCache.com</title>
    <link>https://rendercache.com/posts/</link>
    <description>Recent content in Posts on RenderCache.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 16 Oct 2026 18:00:00 +0300</lastBuildDate>
    <atom:link href="https://rendercache.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Warm before the crawler arrives</title>
      <link>https://rendercache.com/warm-before-the-crawler/</link>
      <pubDate>Fri, 16 Oct 2026 18:00:00 +0300</pubDate>
      <guid>https://rendercache.com/warm-before-the-crawler/</guid>
      <description>&lt;p&gt;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&amp;rsquo;s alpha takes a different starting point: discover the public URLs from the sitemap, then render them before requests need the saved HTML.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Know which response left your server</title>
      <link>https://rendercache.com/response-receipts/</link>
      <pubDate>Fri, 16 Oct 2026 18:00:00 +0300</pubDate>
      <guid>https://rendercache.com/response-receipts/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The alpha you can run today</title>
      <link>https://rendercache.com/alpha-release/</link>
      <pubDate>Fri, 16 Oct 2026 18:00:00 +0300</pubDate>
      <guid>https://rendercache.com/alpha-release/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
