Spache

The origin is a JavaScript app, not a finished page

Ask the origin for a route and you get the small document that starts the app. The meaningful page content is created after JavaScript runs in a browser. A visitor can do that; a crawler that only reads the initial response may have little or nothing useful to index.

That is exactly the kind of site Spache.online is. We use our own site as the example because this page is being delivered through Spache too.

The problem is the same; the rendering model is different

A browser-only SPA starts with an app shell and builds the page after JavaScript runs. To send useful HTML in the first response, teams usually choose one of a few approaches.

• Generate static HTML at build time. A build renders pages into files that can be served directly from a CDN. This is very fast and works well when routes and content can be prepared ahead of time. The trade-off is keeping every generated route fresh: content changes need a rebuild or revalidation, and large or frequently changing route sets add work to the build and publishing pipeline. Adapting an existing SPA to generate all that HTML can also mean changing how the app is built.
• Render on a server. A framework such as Next.js can generate HTML at build time or render a page for a request when it needs current request-time data. It is a capable way to build dynamic pages, but adopting server rendering means learning and maintaining its rendering conventions, data-loading boundaries, caching and revalidation behaviour, and deployment/runtime setup. For a team with an existing SPA, that can turn “make the page available as HTML” into a broader app migration—and pull development time and agent context away from the product itself.
• Render the existing SPA outside the app. Spache opens the deployed app in a browser, saves its rendered HTML, and serves that through a shared cache. Your SPA and origin stay as they are; Spache takes responsibility for producing and refreshing the rendered copy.

You can take on the rendering model, build pipeline, and runtime yourself—or keep the SPA you already have and let Spache produce and serve its rendered copy. Spend that engineering time and agent context on the product, not on making another rendering stack work.

Spache runs the app and captures the finished page

A Spache render worker opens the site in a real browser, lets the app start, and records the resulting HTML. If configured, it also captures the API responses the app uses while starting. Spache stores the rendered result so the next request does not need to rebuild that first view.

This is the live screenshot for Spache.online’s home route, and it always reflects the latest render. It is a visual check of the result; crawlers receive the corresponding HTML, not this screenshot image.

Spache checks for a ready-to-serve render

When someone requests a connected domain, that request reaches Spache first. Spache identifies the site and route, then looks for a current cached render. On a cache hit, the rendered HTML is returned instead of making the visitor wait while the app constructs the initial page.

On a cache miss, normal visitors can receive the origin response while Spache renders in the background. Recognised crawlers wait for a render on a miss, so they can receive the rendered content.

The page can appear before the app bundle finishes

The response already contains the page content. The browser can parse and display it while it downloads the app bundle and other resources. The app still starts normally in the browser and takes over; Spache does not remove your frontend or turn it into a different framework.

That means visitors do not have to wait for the app’s startup network requests just to see the initial page. The content is already there, ready to paint.

Captured API responses can skip the startup round trip

For configured API calls made during rendering, Spache can store the response and include replay code with the cached page. When the app makes a matching request as it starts, Spache can return that captured response locally instead of waiting for the origin API again. For POST requests, the request body is part of the match, so distinct queries are kept distinct.

It is not a promise that every request is eliminated: uncaptured calls, personalised data, and later user actions still use the network as usual. It means the initial page and its captured startup data can be ready together.