CDN Optimization for Static Sites: Cache, TTLs, and Edge Rules

February 26, 2026 · DevOps, Performance, CDN

Static sites are fast by default, but real-world performance depends on your CDN. A good CDN configuration can cut time-to-first-byte (TTFB) to under 50 ms for global users, reduce origin traffic by 80–95%, and prevent cache stampedes during traffic spikes. This guide focuses on practical, repeatable CDN optimizations you can apply to any static site in 2026.

What “CDN optimization” means for static sites

Static sites (HTML, CSS, JS, images) are ideal for CDN delivery. Optimization is mostly about cache behavior, header correctness, compression, and asset naming. When done right, the CDN becomes your primary serving layer and your origin is hit rarely. When done wrong, users get stale content or your origin gets hammered.

• Cache-control strategy for HTML vs. static assets
• Immutable asset naming (content-hashed files)
• Edge rules for overrides and exceptions
• Compression and image formats
• Monitoring and validation

Cache headers: the foundation

CDNs respect HTTP caching headers. For static sites, you should treat HTML differently from versioned assets.

Recommended headers (HTML)

HTML changes often and should revalidate quickly.

Cache-Control: public, max-age=0, must-revalidate

This tells the CDN and browser to store the HTML but revalidate on each request. If you prefer a short TTL, use:

Cache-Control: public, max-age=60, s-maxage=300

max-age applies to the browser (60s), while s-maxage applies to the CDN (5 minutes). This reduces origin traffic while keeping updates responsive.

Recommended headers (versioned assets)

For assets with content hashes in the filename (e.g., app.3f1c2d9.js), you can cache for a year:

Cache-Control: public, max-age=31536000, immutable

immutable tells browsers the file will never change at that URL. That’s the point of content hashing.

Example server config (Netlify headers)

# netlify.toml
[[headers]]
  for = "/*.html"
  [headers.values]
    Cache-Control = "public, max-age=0, must-revalidate"

[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

Asset naming: content hashes or bust

If you don’t use content hashes, long cache lifetimes become dangerous. Modern build tools do this automatically:

• Vite: assets/[name].[hash].js
• Webpack: [contenthash]
• Next.js static exports: /_next/static/ content-hashed

Make sure your pipeline preserves hashed filenames during deploy. If you have custom scripts that rewrite filenames, verify them using the Regex Tester to ensure your pattern matches hashed assets correctly (e.g., \.([a-f0-9]{8,})\.).

CDN edge rules: override when needed

Sometimes you need exceptions: a sitemap, robots.txt, or a JSON feed. CDN edge rules can override headers without changing the origin.

Example edge rule logic (pseudo)

if path == "/sitemap.xml" or path == "/robots.txt":
  Cache-Control = "public, max-age=3600"

if path starts_with "/api/":
  Cache-Control = "no-store"

If you have a JSON feed or config file, verify that your caching doesn’t break update cadence. Use a short TTL and revalidation for dynamic JSON. When editing JSON payloads, validate them with the JSON Formatter before deploying to avoid CDN-cached errors.

Compression: Brotli first, gzip fallback

Static sites benefit massively from compression. Most CDNs support Brotli (br) for HTTPS and gzip for compatibility. Aim for:

• br for HTML/CSS/JS
• gzip fallback for older clients

Check your CDN settings to ensure both are enabled. You should see Content-Encoding: br for modern browsers. Compression can reduce JS payloads by 20–30% compared to gzip and 30–40% compared to raw.

Image optimization: modern formats at the edge

Serve WebP or AVIF whenever possible. Many CDNs can auto-convert images based on the Accept header. If you can’t auto-convert, build-time conversion still works well.

• AVIF can reduce image size by 30–50% vs JPEG
• WebP provides wide support and good compression

Don’t forget long cache headers for image assets with hashed filenames.

Cache invalidation: prefer versioning over purges

Purging CDN cache is slow and error-prone. With content-hashed assets, you almost never need to purge. For HTML, use a short TTL or revalidation. If you must purge, limit it to HTML or a specific path.

Rule of thumb:

• Versioned assets: never purge
• HTML: TTL 0–300 seconds
• Feeds or JSON: TTL 300–900 seconds

HTTP/2 and HTTP/3: keep them enabled

Most CDNs enable HTTP/2 by default. HTTP/3 (QUIC) is now stable and should be enabled if available. It improves latency and resilience on lossy networks. Keep an eye on compatibility, but in 2026, HTTP/3 is a clear win for global static sites.

Edge redirects and URL normalization

Redirects belong at the edge. Normalizing trailing slashes, forcing HTTPS, and canonical domains at the CDN reduces origin traffic and ensures consistent caching. Example rules:

• Redirect http → https
• Redirect non-www → www (or vice versa)
• Normalize trailing slash for directories

If you’re handling URL parameters, make sure cache keys ignore irrelevant query strings. To safely encode or normalize query strings in scripts, use the URL Encoder/Decoder and confirm outputs match your cache rules.

Security headers without killing cache

Security headers (CSP, HSTS, X-Content-Type-Options) should be served via CDN or origin, but don’t impact caching. Use edge rules to ensure they’re present on all HTML responses.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Validate cache behavior with curl

Always test with headers. You should see cache hits after the first request.

# First request (likely MISS)
curl -I https://example.com/

# Repeat request (should be HIT)
curl -I https://example.com/

Look for CDN-specific headers like CF-Cache-Status, X-Cache, or Age. If HTML isn’t cached or revalidated correctly, check your headers and edge rules.

Practical build pipeline checklist

• Content hashing for assets
• Short TTL for HTML with revalidation
• Long TTL for hashed assets (1 year)
• Brotli + gzip enabled
• Image formats AVIF/WebP
• Edge redirects for canonical URLs
• Minimal purges

Example: cache headers for a static export (Nginx)

server {
  location / {
    try_files $uri $uri/ /index.html;
    add_header Cache-Control "public, max-age=0, must-revalidate";
  }

  location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }
}

Edge caching for JSON config files

If your static site loads a JSON config file (e.g., /config.json), give it a short CDN TTL with revalidation. If you generate it as part of the build, a 5–15 minute TTL is a practical default. Validate JSON before deployment to avoid caching broken config; the JSON Formatter makes quick checks easy.

Debugging common CDN issues

• Stale HTML → HTML cached too long; use revalidation
• Assets not updating → missing content hash or immutable caching without versioning
• High origin traffic → HTML not cached; missing s-maxage
• Inconsistent responses → cache key includes random query params

CDN optimization ROI for static sites

Real-world wins are measurable. With correct caching and compression, you should expect:

• 70–95% fewer origin requests
• 20–40% smaller JS/CSS payloads with Brotli
• 30–50% smaller images with AVIF
• Global TTFB under 50–100 ms from edge

Final recommendations

CDN optimization is about discipline: correct headers, versioned assets, edge rules, and consistent validation. If you can do only three things, do these:

• Use content hashes for every static asset
• Set immutable + 1-year cache for hashed assets
• Set short or revalidated cache for HTML

That alone gets you most of the benefit. Everything else is incremental polish that can make your site feel instant anywhere in the world.

FAQ

Need to generate unique cache-busting IDs during builds? You can use a UUID as part of a build pipeline step with the UUID Generator, but for CDN caching, content hashes remain the best option.