Cache
Store public responses at the edge and control when they expire.
Cache eligibility
Choose which responses can enter the shared edge cache:
| Setting | Eligible content |
|---|---|
| Origin-controlled public responses | Responses explicitly marked public with a positive freshness lifetime. |
| Static assets | Eligible images, fonts, scripts, and other static responses. |
| Static assets and HTML pages | Eligible static assets and HTML responses. |
Enable Require origin cache instructions if your origin must set the freshness lifetime. The edge lifetime limit caps how long a response can remain stored.
Private content
Responses with private cache instructions or Set-Cookie bypass shared storage, as do authenticated requests and requests with bodies.
Configuring Zero Trust, tunnel routes, or a tunnel origin bypasses shared caching for the whole website. Zero Trust responses use Cache-Control: private, no-store.
Cache status
Inspect the X-Loclix-Cache response header:
| Value | Meaning |
|---|---|
| HIT | Served from the cache. |
| MISS | Not served from a stored response; eligibility determines whether it can be stored. |
| BYPASS | Shared caching was skipped. |
| STALE | Served an expired cached response under the stale-response policy. |
Purges
Use the website's cache controls to remove stored responses. Saving route changes also invalidates the website cache.
Browser freshness
Edge storage and browser storage have separate rules. CSS, JavaScript, HTML, PNG, and JPEG responses require browser revalidation before reuse, even when served from the edge cache. Browser lifetime overrides cannot extend their freshness.
Private and no-store directives still apply. Other asset types use their configured browser policy. See Response optimization for stylesheet versioning and compatibility requirements.