Cache rules decide which content edge nodes cache and for how long. With them configured well, static assets are served straight from the edge at a high hit rate, while dynamic content always fetches from the origin — fast and correct.
What cache rules do
By default, not every response is suitable for caching. Images, CSS and JS rarely change and are good candidates for long caching; logged-in pages, checkout endpoints and other dynamic content must fetch from the origin every time. Cache rules distinguish the two and assign each a different policy.
Match by suffix and path
Add a rule under "Cache configuration" on the site detail page, matching by file suffix or URL path:
- By suffix: such as
jpg png css js woff2, covering a class of static assets at once. - By path: such as the
/static/prefix, bringing a whole directory under one policy. - Put more specific rules higher up so they aren't pre-empted by broader ones.
Cache key and parameters
The cache key decides "which requests count as the same cached copy". By default it's the full URL. If your URLs carry query parameters that don't affect content (such as analytics utm_*), you can configure them to be ignored so they share one cached copy, raising the hit rate.
What not to cache
For content that must be real-time, set it explicitly to not cache — for example endpoints carrying personal data, or admin paths. Such a rule passes matching requests straight to the origin and keeps nothing at the edge. Note that "not cached" and "cached for 0 seconds" are not the same: to truly avoid caching, choose the no-cache policy rather than entering 0 as the cache time.
Rule order and effect
Rules match top to bottom and stop at the first hit. After reordering and saving, the new policy is pushed to edge nodes quickly. Following a change, we recommend purging the affected URLs once to clear caches produced under the old rules, so the new policy takes effect immediately.