Caching and Performance

Cache-Control Headers

The Cache-Control header tells browsers and CDNs how to handle a response. It's the single most important header for performance, and getting it wrong means either stale content or unnecessary origin fetches.

Key directives you'll encounter:

• max-age=3600 — Cache this response for 3600 seconds (1 hour). After that, revalidate.
• s-maxage=86400 — CDN-specific: cache at the edge for 86400 seconds (1 day), even if the browser max-age is shorter.
• public — Any cache (including shared CDN caches) can store this response.
• private — Only the user's browser should cache this. Don't store it on shared/CDN caches.
• no-cache — Cache it, but revalidate with the server before using the cached copy.
• no-store — Don't cache this at all. Used for sensitive or highly dynamic content.
• immutable — This content will never change. Used for fingerprinted assets (e.g., app.a3f2c1.js).

For deeper technical reference on these directives, the Cloudflare Cache-Control documentation provides authoritative coverage of how each directive behaves at the CDN edge layer.

CDN Edge Caching

A CDN (Content Delivery Network) maintains copies of your content at edge locations around the world. When a user in Tokyo requests your page, the CDN serves it from a nearby edge node instead of routing the request to an origin server in Virginia.

For static-generated sites like CryptoSoul (built with Nuxt and deployed to Cloudflare Pages), every page is a pre-built HTML file. The CDN caches these files aggressively because they don't change between deployments. When you deploy an update, the CDN invalidates its cache and serves the new files.

This means:

• Time to First Byte (TTFB) is typically under 50ms for cached content
• No server-side computation per request — the HTML is already built
• Global performance is consistent regardless of user location

Static Asset Strategy

Different asset types need different caching rules. The goal: cache aggressively where safe, revalidate where freshness matters.

Browser Cache Behavior

Browsers maintain their own cache independently of the CDN. When you visit a page, the browser checks its local cache first. If it has a valid cached copy (based on Cache-Control headers), it uses that copy without making any network request at all.

This creates the fastest possible experience for returning visitors: zero network requests for cached assets. But it also means stale content can persist if cache headers are too aggressive for content that changes frequently.

The solution for static sites: use content-hashed filenames for JS and CSS (e.g., main.8f3a2c.js). When the content changes, the filename changes, and the browser fetches the new file automatically. The old file stays cached harmlessly — it's never referenced again.

Performance Measurement

Metrics that matter for real-user experience:

• Largest Contentful Paint (LCP): When the largest visible element finishes loading. Target: under 2.5 seconds.
• First Input Delay (FID): How long before the page responds to user interaction. Target: under 100ms.
• Cumulative Layout Shift (CLS): How much the page layout shifts during loading. Target: under 0.1.
• Time to First Byte (TTFB): How fast the server responds. For CDN-cached static pages, this should be well under 200ms.

Practical Checklist for Static Sites

• Set Cache-Control: public, max-age=31536000, immutable for fingerprinted assets
• Set reasonable TTLs for HTML pages (cache at CDN edge, revalidate on deploy)
• Compress all text-based assets with gzip or brotli
• Use responsive images with proper width/height attributes to prevent layout shift
• Lazy-load images below the fold
• Minimize JavaScript bundle size — every kilobyte counts on mobile connections
• Test with real-world network conditions, not just fast office WiFi