Skip to content 
CDN configuration sounds like a quick solution, but incorrect rules, SSL handshake overhead and weak origin resources can increase the loading time unnoticed. I'll show you how small configuration details can create big brakes and how you can mitigate these traps measurably and permanently.
Key points
- Cache rules determine whether edge servers deliver content or constantly load the Origin.
- SSL/TLS and protocol selection increase round trips if handshakes and reuse do not fit.
- Origin resources and I/O limit throughput despite global edges.
- DNS/Routing generate latency when anycast and peering are unfavorable.
- TTL/Purging control freshness, consistency and load peaks after changes.
Why CDNs can slow you down
I often see that a Edge is particularly effective when it delivers as many objects as possible from a clean cache and only rarely queries the origin. If there is no clear separation between static and dynamic assets, the CDN generates countless bypasses to Origin and dilutes the advantage. Every additional DNS resolution, every new TCP handshake and every missed keep-alive costs milliseconds. If the data path runs via distant PoPs, latency accumulates over several hops. The user notices these sums as slowness during start rendering and time to first byte.
Hidden stumbling blocks in cache and routing
Wrong Cache control-headers, cookie settings for actually static files or query strings without relevance force Edges to origin-fetch. I first check whether cookies, authorization headers or changing query parameters for CSS/JS/images are really necessary. If the Vary rules are correct, the cache hit rate increases noticeably. If you want to go deeper, take a look at brief examples HTTP cache header on. Equally important: routing policies that inadvertently direct requests to overloaded PoPs and thus waste fractions of a second. Latency add.
SSL/TLS: Using handshakes and protocols correctly
An additional TLS handshake costs two round trips and multiplies the noticeable Delay. If the simple RTT between client and edge is 95 ms, then a fresh handshake adds almost 200 ms before the first byte flows. I rely on TLS 1.3, session resumption and 0-RTT so that revisitors do not start any expensive rebuilds. HTTP/2 bundles streams on a single connection, HTTP/3/QUIC reduces head-of-line blocking on shaky networks; this results in more visible Stability in throughput without using the forbidden word. Connection reuse between Edge and Origin remains important, otherwise the backend handshake eats up the entire gain.
Origin server as a bottleneck
A weak Origin limits any CDN advantage because misses and revalidations are pending there. If there is not enough CPU, PHP or node processes back up and timeouts accumulate. If there is a lack of RAM and IOPS, the database slows down and every cache warm phase ends in a noticeable queue. I check metrics such as CPU steal, iowait and open connections before I tweak the CDN. Only when the origin responds with high performance does the CDN pick up the large Profits from the edge.
Network, latency and DNS design
I measure the RTT between user, Edge and Origin separately, otherwise I chase phantom causes. I also monitor DNS resolution times and connection reuse rates. Unfavorable peering between the CDN backbone and the origin's data center makes every miss more expensive. Anycast often helps, but in individual cases it leads to an overcrowded PoP; an analysis on Anycast DNS. I therefore test from target regions with real traces before I create a global Distribution calculate.
Cache purging and TTL strategies that work
Without clean TTL-logic, edges deliver content that is too old or bombard the source with unnecessary revalidations. I use s-maxage for proxies, age headers for measurability and ETags only where If-None-Match really makes sense. I fire purges specifically by tag or path, never as a full purge during peak traffic times. Diff-based purges after deployments save resources and prevent cold shocks in the cache. The following table gives a quick Guideline for start values:
| content type | Recommended TTL | Purge trigger | Risk if TTL is too high/low | CDN rule note |
|---|---|---|---|---|
| CSS/JS versioned (e.g. app.v123.js) | 7-30 days | New version | Too high: hardly any risk; too low: frequent misses | Cache key without cookies, query ignore |
| Images/Fonts unchanged | 30-365 days | Asset swap | Too high: outdated asset; too low: origin load | Set Immutable, check Gzip/Brotli |
| HTML static (marketing pages) | 15-120 minutes | Content update | Too high: old content; too low: revalidations | s-maxage, Stale-While-Revalidate |
| HTML dynamic (store, login) | 0-1 minute | User event | Too high: incorrect personalization; too low: misses | BYPASS per Cookie/Authorization |
| APIs (GET) | 30-300 seconds | Data change | Too high: outdated data; too low: thundering stove | Stale-If-Error, Negative Caching |
Static vs. dynamic - the surprising effect
Web servers deliver static Files extremely fast, often orders of magnitude faster than dynamic pages. However, if a plugin sets cookies for images or CSS, the CDN marks these assets as private and bypasses the cache. Edge and the browser then keep returning to the source - with correspondingly long chains. I therefore check cookie flags for all static routes and separate static domains so that no session cookies are included. This keeps the Hit rate high and the origin has room for real logic.
Warm up and use prefetch wisely
Kill cold caches Performance after releases, because all hits become misses and the Origin glows. I specifically preheat important paths, prioritize start pages, bestsellers and critical API endpoints. Prefetch and preload headers prepare follow-up assets and significantly reduce the launch phase. If you set this up methodically, you will find compact how-tos on the CDN warmup useful impulses. Combined with Stale-While-Revalidate, edges remain deliverable, even if the origin is short. stutters.
Configuration checklist step by step
I start with the Cache key: no cookies, no unnecessary query parameters for static objects. Then I verify Cache-Control, s-maxage, Stale-While-Revalidate and Stale-If-Error directly in the header. Thirdly, I check the cookie policy and authorization for dynamic paths so that personalization remains correct. Fourthly, I measure latency, DNS times and TLS handshakes separately for Client→Edge and Edge→Origin from target regions. Fifthly, I check purge automation after deployments so that fresh content is quickly available on all Edges lie.
Typical anti-patterns and how I avoid them
I do without global Full-Purges at peak times, because then all users hit a miss. I don't store very low TTLs for images just to „play it safe“. I don't create excessive Vary rules that cause the number of objects in the cache to explode. I don't run cookies on static domains, even if it seems „convenient“. And I don't use aggressive revalidate on HTML when stale-while-revalidate gives the same fresh impression with far less Load achieved.
Architecture decisions: Multi-CDN, Regional Peering
A Multi-CDN with latency-controlled routing distributes requests to where the route is currently fastest. I use origin shield or tiered caching to keep the origin protected in case of miss storms. Regional peering with large ISPs often reduces RTT and packet loss more than any code tweak. Negative caching for 404/410 limits repeated misses that only return errors. With clean health checks, failover works without visible Dropout for users.
Edge functions: Workers, ESI and fragmented caching
Many CDNs offer Edge computesmall functions that rewrite headers, decide routes or dynamically assemble HTML. I use this to encapsulate personalization at the edge and keep most of the HTML cacheable (fragment/ESI approach). Pitfalls: cold starts of slow functions, too generous CPU/time limits and states that are not reproducible. I keep functions deterministic, measure their p95 runtime and explicitly log whether they enable or prevent a cache hit.
Clean control of images, formats and compression
Breadstick for text (HTML, CSS, JS) provides measurably better compression than Gzip, but must not be used twice. I deactivate origin compression if the Edge already compresses cleanly and pay attention to content length/transfer encoding. WebP/AVIF variants are worthwhile for images - but only with controlled compression. Vary-strategy. I normalize Accept headers to avoid creating a cache explosion and keep versioning via file names, not query strings.
Cache key normalization and parameter whitelists
Unnecessary Query parameters such as UTM/Campaign generate low-fact variants. I only whitelist a few parameters that really change rendering or data and ignore everything else in the cache key. For static assets, I consistently remove cookies from the key. In addition, I smooth out headers that are rarely relevant (e.g. Accept-Language), thus reducing the variety of objects without losing function. This often increases the hit rate by double digits.
Authentication, signatures and private content
Personalized areas need protection, but do not have to be completely uncacheable. I separate private User data (BYPASS) from public fragments (cacheable) and use signed URLs or cookies for downloadable objects with a short TTL. Security flags such as Authorization/Cookie must not be inadvertently cached at the edge; I therefore explicitly check which headers influence the cache key. For APIs, I only set „public, s-maxage“ for GET and only if responses are truly idempotent.
Prioritization, Early Hints and Preconnect
HTTP/2 prioritization only works if the Edge does not blindly reorder. I define priorities for Crit paths (CSS before images) and use 103 Early Hints to send preload links before the actual HTML. Preconnect helps with domains that are sure to follow; excessive dns prefetch, on the other hand, creates idle work. I measure whether these hints really change the download order - if not, I correct the priorities or save superfluous hints.
Timeouts, retries and protection of the origin
Too aggressive Retries for misses multiply origin load and extend TTFB if many workers are waiting for the same resource at the same time. I set short timeouts, exponential backoff and collapse revalidations („request collapsing“) so that only one fetch reaches the origin. A circuit breaker, which is activated for error rates of stale-if-error will receive the delivery instead of hitting users with 5xx. Important: Keep alive and connection pools between Edge and Origin stable, otherwise rebuilding will eat up any advantage.
WAF, bot traffic and rate limits
WAF rules often check every request synchronously and can significantly increase latency. I run static paths past the WAF where it's safe to do so and set rules to log-only before arming them. For error-friendly bots or scrapers, I limit rate limits on the edge and use negative caching for known 404 routes. This keeps the edge nimble, the origin protected and legitimate traffic undisturbed.
Metrics, logs and tracing that really help
Being blind without upper percentiles is the biggest mistake. I track p95/p99 TTFB, edge hit rate, reuse rates, TLS handshake times and origin fetch duration separately. Response headers with cache status (HIT/MISS/STALE/BYPASS), age and serving PoP end up in logs and correlate with trace IDs from the application. This allows me to see whether an outlier originates from routing, TLS, CPU wait or WAF. I also sample RUM data by region and device in order to recognize mobile edges separately.
Rollout, testing and versioning of the rules
CDN rules are Production. I seal changes behind feature flags, roll them out by region/percentage and compare metrics against a control group. Each rule gets a version, a ticket and measurable targets (e.g. +8 % hit rate, -40 ms p95 TTFB). Rollbacks are prepared and automated. Synthetic tests check in advance whether cache headers, cookies and Vary work as planned before real traffic hits the change.
Using streaming and range requests correctly
Video, large downloads and PDFs benefit from Range requests and 206 responses. I make sure that the edge is allowed to cache sub-ranges, segments are named consistently and the origin servers deliver byte ranges efficiently. Prefetch of subsequent segments smoothes bitrate changes, stale if error keeps streams running in the event of a brief origin failure. Important: no unthrottled parallel range requests, otherwise the bandwidth will become a bottleneck.
Briefly summarized: Your next steps
Start with an honest Measurement from user regions and separate Client→Edge from Edge→Origin. Increase the cache hit rate with clean headers, cookie diet and appropriate TTLs. Relieve the load on the origin with preheating, stale strategies and a sparse purge plan. Optimize TLS, HTTP/2/3 and connection reuse so handshakes don't dominate the stopwatch. Check peering, anycast mapping and PoP utilization before tweaking code or hardware, and ensure success with persistent Monitoring.
