Cache Management

Cache Settings

How fast.site decides what to cache, and how to influence it from your origin.

How the defaults are set

When you add a domain, fast.site detects your platform (WordPress, Drupal, Magento, and so on) and applies a tuned cache template. That template covers most cases out of the box. Your origin's Cache-Control headers always win if you want to override.

Origin Cache-Control headers

Default: respected

If your origin server sends Cache-Control headers, fast.site respects them. If not, the platform template's defaults apply.

Browser cache

Default: enabled

fast.site sends cache headers downstream to browsers so returning visitors load even faster from their local cache.

Query string caching

Default: included

URLs with different query strings are cached as separate entries (e.g. <code class="bg-white/50 px-1 rounded">?v=1</code> and <code class="bg-white/50 px-1 rounded">?v=2</code> are distinct).

Influencing cache behavior from your origin

You can fine-tune what gets cached and for how long by setting Cache-Control headers on your origin:

# Cache for 1 hour

Cache-Control: public, max-age=3600

# Cache for 1 year (versioned assets)

Cache-Control: public, max-age=31536000, immutable

# Don't cache (dynamic pages)

Cache-Control: private, no-store

Paths the template excludes by default

Your platform template already bypasses cache for the paths that need to stay dynamic (admin areas, cart, checkout, account, login). Examples for WordPress:

/admin/*
/wp-admin/*
/cart/*
/checkout/*
/my-account/*
/api/*

Need additional paths bypassed for your specific setup? Reach out and we'll configure it on our side.

Best practice

Use versioned filenames for CSS and JS (e.g. app.v2.js) and set long cache times. You get aggressive edge caching while still being able to ship updates without manual purges.

Back to Support