Creating a cache rule for public static assets

Identify a static directory or exact asset pattern and inspect its response headers. Confirm it does not contain authenticated downloads, user-specific exports or URLs whose extension disguises a dynamic route.

1. Open Rules and create a Cache Rule for the intended zone.
2. Name the rule by its purpose and match the exact hostname plus the public asset path or appropriate condition. Avoid matching all traffic for a narrow asset task.
3. Choose Eligible for cache and use the origin’s deliberate cache policy unless an override is specifically justified.
4. Review the rule’s position against other cache rules, especially private-page bypass rules. Deploy after checking the expression.
5. Request representative files as anonymous and signed-in users, inspect CF-Cache-Status and confirm the content is safe to share across visitors.

Assume static.example.com/assets/ contains only public CSS, JavaScript and images produced by your build. After checking that no authenticated exports or user-specific downloads live there, create a Cache Rule using this narrow expression.

http.host eq "static.example.com" and
starts_with(http.request.uri.path, "/assets/") and
http.request.method in {"GET" "HEAD"}

Choose Eligible for cache and begin with the origin’s deliberate cache policy. For long-lived caching, versioned filenames let the next deployment publish a different URL when bytes change. Eligibility alone does not override every response condition or prove the file was stored.

Expected result: Repeated requests for an intended public asset can use edge cache without changing the main application’s login or checkout policy. A file with private or no-store directives is investigated at its source rather than made public merely to achieve a HIT.

The intended public files should become cacheable without changing private routes. Evaluate multiple requests and locations because the first request at an edge may be a miss.

Eligibility does not guarantee storage: response headers, cookies, status and other controls can still prevent caching. Do not remove private or no-store headers merely to obtain a HIT. Correct the application’s public-asset delivery where appropriate.

Only after a full application-specific design. Login, cart, account and personalised pages can leak or mix data if treated like public files. Start with a clearly public asset scope.

• Bypassing cache for private account and checkout pages
• Interpreting CF-Cache-Status during performance testing
• Diagnosing overlapping Cloudflare rules
• Distinguishing browser cache lifetime from edge cache lifetime

• Cloudflare: Create Dashboard
• Cloudflare: Default Cache Behavior

• Cloudflare cache rules
• Cloudflare rule fields