Caching

Static files

Files from your build are served with validators, so repeat requests are answered with 304 Not Modified. Fingerprinted assets (a hash in the file name) are marked immutable so browsers keep them. Each deployment has its own files, so a new deployment never serves stale ones.

Server responses

Responses from server-rendered routes are cached at the edge following the standard HTTP caching rules (RFC 9111), and only if the application opts in. A response is stored when it is marked shareable and freshness is given. Anything personal is left alone: responses that set cookies, or that are marked private or no-store, are never stored.

Controlling it with headers

# cache at the edge for 60 seconds, then serve stale for up to 5 minutes
# while refreshing in the background
Cache-Control: public, s-maxage=60, stale-while-revalidate=300

# never cache
Cache-Control: private, no-store

The cache is keyed by deployment, host, path, query string and any headers named in Vary. A new deployment starts with an empty cache.

Freshness and stale content

• An edge-cached response is considered fresh for at most 60 seconds, even if you ask for longer.
• stale-while-revalidate lets the edge answer immediately from an expired copy while it fetches a new one.
• stale-if-error lets it keep answering from an expired copy if your server is failing.
• Many simultaneous requests for the same uncached page cause one request to your server, not many.

Purging

You can remove cached responses for a project by project, by tag or by path. Purges reach every edge within a few seconds. Use the project's caching controls in the dashboard, or the API with an access token that can write deployments; see Account and tokens.

Checking what happened

Cached responses carry Cache-Status and Age headers:

$ curl -sI https://project.vtrex.app/page | grep -i -E "cache-status|age"

The Cache view charts hit rates over time.