CloudFlare Caching Strategies

Practical CloudFlare caching strategies for different types of websites. These examples show how to balance performance, resilience, and freshness using Edge TTLs, Browser TTLs, and cache bypass rules.

---

Strategy 1 — Blog / Documentation / Marketing Site (Mostly Static)

Best for

• Blogs
• Documentation
• Landing pages
• Portfolio or brochure-style sites

Goal

• High availability
• Fast loads
• Freshness is not critical

Cache Rule

IF

• Hostname equals www.example.com
• AND
• URI Path does not start with /api/
• AND
• URI Path does not start with /my-account/

THEN

• Cache eligibility: Eligible for cache
• Cache level: Cache everything
• Edge TTL: 1 day
• Browser TTL: 1 hour
• Serve stale content while revalidating: ON

Notes

• Pages remain available even if the origin server goes offline.
• If content needs to update immediately, purge the affected URLs in CloudFlare.

---

Strategy 2 — News or Frequently Updated Content

Best for

• News sites
• Announcement feeds
• Frequently edited content

Goal

• Faster propagation of updates
• Still benefit from edge caching

Cache Rule

IF

• Hostname equals www.example.com
• AND
• URI Path does not start with /api/

THEN

• Cache eligibility: Eligible for cache
• Cache level: Cache everything
• Edge TTL: 10–15 minutes
• Browser TTL: 2–5 minutes
• Serve stale content while revalidating: ON

Notes

• Users may briefly see older content, but updates propagate quickly.
• Purge cache for urgent updates or corrections.

---

Strategy 3 — Hybrid Website (Public Pages + Logged-in App)

This is one of the most common and safest patterns.

3A — Public Pages (Cached)

Best for

• Homepage
• Blog
• Public documentation

IF

• URI Path does not start with /api/
• AND
• URI Path does not start with /my-account/

THEN

• Cache eligibility: Eligible for cache
• Cache level: Cache everything
• Edge TTL: 1 day
• Browser TTL: 30–60 minutes
• Serve stale content while revalidating: ON

---

3B — Logged-in Area /my-account/ (Never Cache HTML)

Best for

• User dashboards
• Account settings
• Personalized content

IF

• URI Path starts with /my-account/

THEN

• Cache eligibility: Bypass cache

Why

• Prevents serving personalized content to the wrong user.
• Guarantees real-time data and correct authentication state.

Static assets (JS/CSS/images) are still cached normally.

---

Strategy 4 — E-commerce Website

4A — Product Browsing (Light Caching)

Best for

• Product listings
• Category pages
• Search results (if safe)

IF

• URI Path starts with /products/
• OR
• URI Path starts with /category/

THEN

• Cache eligibility: Eligible for cache
• Cache level: Cache everything
• Edge TTL: 10–60 minutes
• Browser TTL: 5–15 minutes
• Serve stale content while revalidating: ON

---

4B — Cart, Checkout, Account (Never Cache)

IF

• URI Path starts with /cart/
• OR
• URI Path starts with /checkout/
• OR
• URI Path starts with /my-account/

THEN

• Cache eligibility: Bypass cache

---

Strategy 5 — SPA / App Shell Cached, Data Dynamic

Best for

• Dashboards
• Internal tools
• Apps where HTML is static but data changes often

5A — Cache the App Shell

IF

• URI Path starts with /app/

THEN

• Cache eligibility: Eligible for cache
• Cache level: Cache everything
• Edge TTL: 1 day
• Browser TTL: 1 hour
• Serve stale content while revalidating: ON

5B — Never Cache APIs or Data

IF

• URI Path starts with /api/
• OR
• URI Path starts with /graphql/
• OR
• URI Path starts with /trpc/

THEN

• Cache eligibility: Bypass cache

---

Strategy 6 — Admin / Backoffice (Never Cache)

Best for

• Admin dashboards
• CMS backends
• Internal tools

IF

• URI Path starts with /admin/

THEN

• Cache eligibility: Bypass cache

Notes

• Admins should always see real-time data.
• Cached HTML here is usually dangerous.

---

Recommended Baseline Rules (Summary)

1. Bypass cache for APIs

   • /api/*

2. Bypass cache for authenticated areas

   • /my-account/*
   • /admin/*

3. Cache public content

   • Blogs, docs, landing pages
   • Edge TTL measured in hours or days
   • Browser TTL measured in minutes or hours

Be careful of NextJS SSR and rendering modes if using Cache as well.

Next.js Rendering Mode	Typical Usage	CloudFlare Cache Strategy	Safe?	Important Notes
Static Generation (SSG)	Blogs, docs, marketing pages	Cache Everything	✅ Yes	Ideal scenario. Fully static HTML, identical for all users, safe to cache for long TTLs.
Incremental Static Regeneration (ISR)	Semi-static content	Cache Everything	⚠️ Mostly	CloudFlare ignores Next.js revalidation timing. Treat as static and purge cache on deploy when freshness matters.
Client-Side Rendering (CSR)	Dashboards, hybrid apps	Cache HTML shell only	✅ Yes	HTML shell is cached; all data is fetched live from uncached APIs. Excellent pattern.
SSR (public, non-personalised)	Public pages built per request	Cache Everything (with care)	⚠️ Careful	Only safe if the HTML is truly identical for all users and contains no cookies, auth, or user data.
SSR (authenticated or personalised)	Account pages, dashboards	Bypass cache	❌ No	Never cache. Risk of showing one user’s data to another.
App Router fetch() caching	Server data fetching	No effect on CF cache	⚠️ Limited	Controls server behaviour only. CloudFlare still caches final HTML if allowed.
API Routes	Data, health checks	Bypass cache	✅ Yes	Always bypass. Use Cache-Control: no-store. Required for /api/is-alive.
Admin / Backoffice pages	CMS, internal tools	Bypass cache	✅ Yes	Admins must always see real-time data.