Spache features
Spache prepares and serves rendered pages for your existing browser-rendered app. Here is what the product currently helps you do, from previewing a site to understanding its traffic and render health.
| Area | Feature | What it does |
|---|---|---|
| Keep your existing app | Works with browser-rendered SPAs | Keep your existing client-side app and framework. Spache renders it in a browser; you do not need to build a server-rendered version. |
| Rendered HTML for visitors and crawlers | Serve prepared route HTML on the normal request path, so useful content can arrive before the app bundle finishes starting. | |
| Preview domains | Try a site on a Spache preview URL before changing your public DNS. | |
| Custom domains and HTTPS | Connect your own domains, follow the DNS setup guidance, and use managed TLS certificates. | |
| Routes and application data | Route discovery and rendering | Spache follows discoverable app links and renders routes so they can be tracked, cached, and served directly. |
| Captured API responses | Eligible JSON GET responses are captured automatically and can be replayed to the app during startup. | |
| Configurable request capture | Add capture rules for requests such as POSTs, matching by URL, method, and—where configured—request body. | |
| Authentication-aware replay | Replay matches use the request method, URL, and body—not secret header values. If a request includes a non-empty Authorization or Cookie header, Spache skips the shared captured response and sends the request to the origin, so user-specific data stays live. | |
| Live visitor-specific behavior | The app still runs in each visitor’s browser. Personal carts, accounts, and later interactions remain live requests, not shared cached sessions. | |
| Cache control and freshness | Configurable render waits | Set minimum and quiet wait times so Spache captures pages after their important startup content appears. |
| Cache lifetime and validation | Choose how long cached pages remain valid; Spache can validate cached content and refresh it when monitored dependencies change. | |
| Whole-site invalidation | Use a generated secret webhook to invalidate the site after a deployment or broad content update. | |
| Route-level invalidation | Invalidate one route from its controls or through the cache webhook when only that page changes. | |
| Route-specific cache settings | Control route behavior, including query parameters that should be ignored or retained as meaningful. | |
| Compressed cached HTML | Serve compressed cached HTML to reduce transfer size when the client supports compression. | |
| Screenshots and diagnostics | Rendered-page screenshots | Inspect a mobile-sized screenshot of a route’s latest render. |
| Optional public route screenshots | Expose a route screenshot at a stable URL when you choose to make it public. | |
| Site and route health | See route render failures on the site overview and open the affected route for details. | |
| Traffic and cache analytics | Review page hits, proxied requests, data transfer, cache hits and misses, and stale responses. | |
| Render and validation analytics | Review render counts, render time, validation activity, and worker compute usage across sites and routes. | |
| Operations and billing | Deployment and content webhooks | Trigger site-wide or route-specific cache invalidation from deployment workflows or a CMS. |
| Usage and cost breakdowns | See account and per-site usage, included allowances, and estimated charges for requests, data, and render work. | |
| Free and paid account modes | Use available free allowances, or enable paid billing for connected sites and usage beyond included limits. |
Feature availability can depend on account mode and site configuration. Start with putting your site in Spache or read how Spache works.