CDN Optimization Playbook [2026]

Installing a CDN is only step one. What actually decides how fast your site is comes afterward — cache strategy, compression, transport protocol, and edge settings. The same CDN, tuned well versus poorly, can differ several-fold in load time.

This guide is about how to tune a CDN for speed — not which one to pick, and not what it costs. If you are still choosing or comparing bills, read these first:

• Which provider, how nodes and features compare → Complete CDN Comparison
• How each provider bills and how to save → Complete CDN Pricing Guide
• A step-by-step configuration checklist → CDN Configuration Tutorial

This article focuses on the "why" and the tuning decisions: why each optimization lever works, how to judge whether to use it, and what breaks when it is misconfigured.

Before Optimizing: Establish Your Baseline

The most common mistake is tuning before measuring. Set a baseline first, so every change afterward can be judged.

Three metrics to check first:

• Cache Hit Ratio: the share of requests served straight from edge nodes without hitting the origin. This is the overall score of CDN optimization.
• TTFB (Time to First Byte): time from request to first byte received — reflects edge and origin responsiveness.
• LCP (Largest Contentful Paint): a core Google Core Web Vitals metric, directly tied to user perception and search ranking.

Use PageSpeed Insights, WebPageTest, or GTmetrix, plus your CDN dashboard's Analytics for hit ratio. Record the pre-optimization numbers, then re-test after each change.

1. Cache Strategy: Hit Ratio Is Everything

Higher cache hit ratio means fewer origin fetches — faster and cheaper. The core is using Cache-Control to tell the CDN how long to cache each type of resource.

Layered Cache-Control

Different resource types need very different strategies:

# Static assets (with hashed filenames): long-term cache + immutable
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|webp|avif)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# HTML: short-term or no cache (content changes often)
location ~* \.html$ {
    add_header Cache-Control "no-cache, must-revalidate";
}

# API: typically no cache
location /api/ {
    add_header Cache-Control "no-store";
}

What the key directives mean:

• max-age: seconds the resource may be cached (31536000 = one year).
• immutable: tells the browser the file will not change within its lifetime, skipping even revalidation — most effective when paired with build-time hashed filenames (e.g. app.9f3c.js).
• public: allows shared caches (CDN, proxies) to store it.
• s-maxage: a TTL specifically for CDN/shared caches, set separately from the browser's max-age — let the edge cache longer while the browser caches less.

Practical Ways to Raise Hit Ratio

When hit ratio won't climb, it is usually one of these:

• Query strings busting the cache: many CDNs treat URLs with different query strings as different resources by default. Tracking params (?utm_source=…) turn one image into countless copies and tank hit ratio. Configure the CDN to ignore non-essential query strings.
• Over-using Vary: Vary: User-Agent stores a separate copy per browser, crushing hit ratio. Use it only for genuine content negotiation (e.g. Vary: Accept-Encoding).
• Never caching HTML: logged-out pages can actually be cached — segment traffic by cookie so anonymous visitors also hit the edge cache.

Purge Strategy

Updates need to invalidate old cache, but frequent full-site purges are slow and can cost money (e.g. CloudFront's first 1,000 invalidations/month are free, then billed per request). Better approaches:

• Versioned filenames: rename on change (style.v2.css) so no purge is needed at all.
• Targeted purge: only clear the paths that changed, not the whole site.
• Soft Purge: on CDNs that support it (e.g. Fastly), mark as stale and re-fetch in the background, avoiding a sudden mass of origin fetches.

2. Compression: Brotli and gzip

Compression is the best return on effort — set it once and every text asset shrinks.

• gzip: broadest compatibility, supported by virtually every browser — the safe baseline.
• Brotli: a newer algorithm from Google that compresses text content (HTML/CSS/JS) better. Per Cloudflare's docs, Brotli is roughly 20% smaller than gzip for text (actual results vary by content).

On Cloudflare, the default compression differs by plan: Free defaults to Zstandard, Pro/Business default to Brotli, and Enterprise defaults to gzip (source below).

Watch out for:

• Only compress text-based assets. JPEG, PNG, WebP, AVIF, video, and .zip are already compressed — re-compressing barely helps and just wastes CPU.
• Cache-Control: no-transform: when the origin sends this header, it asks the CDN not to alter compression. If you want the CDN to compress for you, make sure the origin does not accidentally send it; conversely, add it when you want to preserve the origin's own compression. This directive can only be set by the origin — a client request cannot add it.

3. Image Optimization

Images are usually the heaviest, most worthwhile part of a page to optimize.

Pick the Right Format

Format	Characteristics	Recommended Use
WebP	Fully supported by major browsers, clearly smaller than JPEG at equal quality	Universal default
AVIF	Higher compression, broadly supported by modern browsers	New projects, smallest size
JPEG	100% compatibility	Legacy fallback
PNG	Lossless, supports transparency	Transparency or sharp edges

Use <picture> so the browser picks the best format, with JPEG as fallback:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description" loading="lazy">
</picture>

Other essentials:

• loading="lazy": defers below-the-fold images, improving LCP.
• Responsive images: use srcset to serve multiple sizes so phones don't download desktop-sized images.
• Built-in CDN image optimization: most CDNs offer on-the-fly conversion/resizing (e.g. Cloudflare Images, Polish) that auto-converts to WebP/AVIF and adapts size per device, saving you from maintaining multiple files. Exact features and pricing are per each provider's official page.

4. HTTP/3 and QUIC

HTTP/3 runs over the QUIC protocol (UDP-based). Compared to HTTP/2:

• Faster connection setup: supports 0-RTT, so return connections have almost no handshake delay.
• Eliminates head-of-line blocking: a single lost packet no longer stalls other streams — especially noticeable on lossy networks.
• Connection migration: connections survive a phone switching from Wi-Fi to cellular, for a smoother mobile experience.

Most major CDNs already support HTTP/3 (for example, all Cloudflare plans, including Free, include HTTP/2 and HTTP/3 + QUIC). Make sure it is turned on in your CDN dashboard — many sites simply haven't enabled it and miss out.

5. Preload and Resource Hints

Beyond the CDN itself, browser Resource Hints further shorten the time to fetch critical resources:

• preconnect: complete DNS, TCP, and TLS handshakes to a critical domain (like your CDN domain) ahead of time, saving round trips when you actually fetch.

  <link rel="preconnect" href="https://cdn.example.com" crossorigin>
  

• dns-prefetch: DNS resolution only — lighter than preconnect, good for secondary third-party domains.
• preload: declares "this resource will definitely be needed soon, fetch it early" — common for above-the-fold fonts, critical CSS, and the LCP image.

  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
  

• Early Hints (103): some CDNs can send 103 Early Hints while the origin is still working, letting the browser start preconnect/preload sooner. Support and setup are per each CDN's official docs.

Principle: only preload the few truly critical resources. Preloading everything makes them compete for bandwidth and slows the first paint instead.

6. Edge Computing and Edge Functions

Edge computing lets you run code directly on CDN nodes — close to users, without going back to origin each time — to cut latency and origin load.

Common use cases:

• Geo-based redirects: route to the right regional version right at the edge.
• A/B testing: split traffic at the edge, avoiding the latency of origin-side decisions.
• Authentication and authorization: verify tokens and block unauthorized requests at the edge, keeping traffic off the origin.
• Dynamic content assembly: stitch personalized fragments at the edge, balancing caching and customization.

Each provider's edge platform:

• Cloudflare Workers: general-purpose edge compute with near-zero cold starts.
• AWS Lambda@Edge: deeply integrated with AWS, suited to AWS-based architectures.
• CloudFront Functions: lightweight, built for short tasks like header rewrites.
• Fastly Compute (formerly Compute@Edge): runs edge code compiled to WebAssembly.

Execution models, cold-start behavior, and pricing differ significantly — check official docs before choosing. This article omits specific figures to avoid going stale.

7. Common Misconfigurations

"Installed a CDN but it's no faster" is a configuration problem nine times out of ten. Check these first:

1. The CDN isn't actually active: in DevTools → Network, look for response headers like cf-cache-status or x-cache. If they're absent, requests aren't going through the CDN at all.
2. Cache hit ratio too low: usually Cache-Control set to no-cache/no-store, query strings busting the cache, or misconfigured Page Rules/cache rules, so most requests still hit the origin.
3. Compression disabled: forgetting to enable Brotli/gzip means text assets ship at full size, wasting bandwidth and time.
4. All HTML set to no-cache: setting every page to no-store forfeits edge caching — anonymous pages can in fact be cached.
5. Cache fragmentation from Vary or query strings: the same content split into countless cache variants means hit ratio never climbs no matter how you tune.
6. Wrong Price Class / node scope: users are all in Asia, yet you use a global scope including South America and Africa — no faster and more expensive.
7. The origin itself is slow: a CDN only accelerates the cacheable part; first-fetch and dynamic content still depend on the origin. If hit ratio is high but it's still slow, go optimize the origin.

8. Monitoring and Continuous Tuning

Optimization is not one-and-done. After launch, keep watching these metrics and investigate anomalies:

Metric	Rule-of-Thumb Target	Warning Threshold
Cache Hit Ratio	>90%	<80%
Origin Latency	<200ms	>500ms
Error Rate	<0.1%	>1%
TTFB	<100ms	>300ms

These are rule-of-thumb targets for a general site; adjust to your content type (static-heavy can go higher, dynamic e-commerce a bit lower) and business needs.

Pair this with your CDN dashboard Analytics and alerts (Billing Alerts, traffic/error-rate alerts) so problems are caught before users notice.

FAQ

I installed a CDN but it's not faster — how do I debug it?

First confirm the CDN is actually active (check response headers in DevTools), then look at cache hit ratio. If it's low, work through "Common Misconfigurations": overly conservative Cache-Control, cache-busting query strings, and disabled compression are the top three. If hit ratio is already high but it's still slow, the problem is usually the origin itself.

What cache hit ratio is healthy, and how do I improve it?

For static-heavy sites, 90%+ is healthy; 80%+ for general sites and 70%+ for e-commerce is acceptable. To improve it: set a long max-age + immutable on static assets, ignore non-essential query strings, use Vary sparingly, and cache anonymous HTML too.

Can dynamic or member pages be accelerated by a CDN?

Yes, with a different strategy. Dynamic pages themselves are mostly uncached, but you can: still edge-cache static assets (images, CSS, JS); use edge computing to handle auth and redirects at the node; and cache logged-out pages by segmenting on cookie. Combined with HTTP/3 and compression, dynamic sites can get noticeably faster.

Does a CDN help SEO?

Yes, mainly through speed as a ranking factor. A CDN improves LCP, TTFB, and other Core Web Vitals, and site speed is an explicit Google ranking signal. But a CDN is only one factor — content quality and links matter just as much, and speed can't rescue weak content.

---

Your CDN is live, but not sure it's tuned to its best?

CloudInsight offers:

• Cache strategy review and hit-ratio tuning
• Compression, HTTP/3, image, and preload optimization
• Edge computing application design
• Performance monitoring and continuous optimization

Book a Free Consultation and let us squeeze the most out of your existing CDN.

---

References

• Cloudflare Content Compression (Brotli / gzip / Zstandard defaults by plan)
• Fastly Compute Product Docs
• AWS CloudFront Caching and Cost Optimization Best Practices
• Google Web.dev: Image and Loading Performance Best Practices