CDN Cache Miss Troubleshooting: Why Assets Keep Hitting Origin

Overview

A recurring cdn cache miss is one of the most common performance problems on otherwise well-built sites. Teams enable a CDN, point DNS at it, and assume images, CSS, JavaScript, and other public assets will be cached automatically. In practice, many assets remain effectively uncacheable because the origin sends the wrong headers, the CDN rule set is too narrow, or each request looks unique enough that the edge treats it as a separate object.

When that happens, you get a familiar set of symptoms: origin bandwidth stays high, Time to First Byte does not improve much, cache analytics look weak, and traffic spikes still stress the application. In ecommerce and dynamic publishing workflows, repeated origin fetches can also create noisy performance variation that makes diagnostics harder than they need to be.

Before fixing anything, it helps to define the problem precisely. A cache miss is not always bad. The first request to a new edge location will often be a miss. A recently purged asset may miss until it is repopulated. A low-traffic file might age out naturally. The real issue is persistent or avoidable misses for assets that should be highly cacheable, such as versioned CSS, JavaScript bundles, product thumbnails, fonts, and media files.

Think of troubleshooting in layers:

• Is the CDN allowed to cache the response? Check response status, headers, methods, and provider rules.
• Is the cache key too fragmented? Query strings, cookies, hostnames, device variation, and headers can create needless variants.
• Is the object being evicted or purged too often? Small TTLs, aggressive deploys, and broad invalidations can keep the cache cold.
• Is the origin making the response look dynamic? Set-Cookie, no-store, private, and inconsistent headers often block caching.

If you want a broader metrics foundation, pair this guide with How to Measure Cache Hit Ratio and Why It Matters for Website Performance and TTFB Troubleshooting Checklist: Is Caching the Bottleneck or the Fix. Those are useful for separating edge cache issues from origin or application latency.

Core framework

Use the framework below in order. It is designed to help you move from symptom to root cause without guessing.

1. Confirm what is actually missing

Start with a specific URL and test it repeatedly. Do not begin with analytics alone. Pick a representative static asset and inspect the response headers with your browser dev tools or a command-line request. You are looking for provider-specific cache indicators, the HTTP status code, and the effective cache-control behavior.

Questions to answer:

• Is the response served through the CDN hostname you expect?
• Does the response include a cache status header such as HIT, MISS, BYPASS, EXPIRED, or REVALIDATED?
• Is the status code cacheable? A healthy 200 is the simplest case, but some redirects and 304 validation flows may behave differently.
• Do repeated requests from the same region eventually become hits?

If every request is a MISS or BYPASS, focus on eligibility. If the second or third request becomes a HIT, the CDN probably works but your TTL, purge policy, or traffic pattern may be the issue.

2. Inspect origin cache headers first

For most cdn cache troubleshooting, the origin headers tell the story quickly. Common blockers include:

• Cache-Control: no-store
• Cache-Control: private
• Cache-Control: max-age=0 without sensible shared-cache behavior
• Pragma: no-cache on legacy setups
• Set-Cookie on assets that should be public
• Missing or inconsistent Cache-Control across file types

For public static assets, the most CDN-friendly pattern is usually a long-lived cache policy combined with filename versioning or hashed filenames. That reduces both origin hit problem frequency and purge pressure. If your CSS and JavaScript are deployed with unique file names on each build, the CDN can safely keep them for much longer.

For a deeper look at client-side retention, see Browser Caching Best Practices for Images, Fonts, CSS, and JavaScript. Browser and CDN policies should complement each other rather than conflict.

3. Check whether cookies are poisoning cacheability

A common reason assets bypassing cdn cache appears in production is that the same cookie-heavy behavior intended for dynamic pages leaks onto static file paths. Some stacks attach cookies to every response by default. Others vary cache behavior if a request merely contains cookies, even when the asset itself is public.

Look for:

• Session cookies being sent on /wp-content/, /static/, /assets/, or media paths
• Origin applications adding Set-Cookie to image, CSS, or font responses
• CDN rules that bypass cache whenever any cookie is present

This is especially relevant on WordPress and ecommerce sites. Personalized pages may need bypass logic, but static theme assets usually do not. If you run WordPress, review whether your caching stack is split appropriately between page cache, object cache, and CDN-delivered static files. Related reading: LiteSpeed Cache vs WP Rocket: Which Is Better for Your WordPress Stack.

4. Normalize the cache key

The CDN cannot reuse an object if each request generates a distinct cache key. This is one of the quietest causes of poor cache efficiency because the asset appears cacheable in theory, but every request variation creates a separate entry.

Typical cache key fragmenters include:

• Query strings used for tracking, such as utm_* parameters
• Version parameters that change too often or inconsistently
• Request headers like Accept-Encoding, User-Agent, or language variations
• Multiple hostnames serving the same asset
• Device-specific edge logic when not actually needed

Decide which parts of the request should truly vary the response. Everything else should be ignored, normalized, or stripped. This is where provider rule engines matter. If you use a rule-based edge platform, tighten the cache key so that irrelevant query strings do not produce cache misses. If your deployment relies on query-string versioning, make sure those values only change when asset content changes.

For rule-based setups, Cloudflare Cache Rules Explained: Recommended Setups by Site Type is a useful companion.

5. Verify TTL and revalidation behavior

Sometimes the CDN is caching, but not long enough to help. Low TTL settings can keep the edge in a constant cycle of expiration and revalidation. Depending on your provider and headers, that may still reduce transfer size, but it will not reduce origin requests as much as expected.

Review:

• Edge TTL or shared cache TTL
• Browser TTL versus CDN TTL
• Revalidation headers such as ETag and Last-Modified
• Whether the provider honors origin headers or overrides them

For static, versioned assets, short TTLs are often unnecessary. For HTML, more conservative behavior may be appropriate. The key is to distinguish content types instead of applying one policy everywhere.

6. Audit purge patterns and deployment behavior

If your team purges broadly on every deploy, your cache may never warm. This is a hidden source of repeated MISS patterns, especially in CI/CD environments where frontend assets are rebuilt often.

Good questions to ask:

• Are you purging all content when only a few files changed?
• Are filenames content-hashed, making most purges unnecessary?
• Do cache tags, surrogate keys, or path-based purges exist but go unused?
• Does your CMS trigger full-site invalidation for small edits?

If you cannot avoid frequent content churn, at least narrow the invalidation scope. Broad purges convert a healthy cache into an expensive pass-through layer.

7. Separate CDN misses from origin-side cache misses

A request can miss at the CDN but still be served quickly by a reverse proxy or server cache at origin. That is better than a full application render, but still not the same as a proper edge hit. If you are troubleshooting performance end to end, trace the entire path.

Check whether origin responses are backed by:

• Nginx FastCGI Cache
• Varnish cache
• Redis object cache for application queries
• Hosting-level full-page caching on managed WordPress platforms

These layers are not substitutes for CDN caching, but they can explain why performance is only moderately degraded rather than catastrophic. Related resources: Varnish vs Nginx FastCGI Cache: Which Reverse Proxy Cache Should You Use, Nginx FastCGI Cache Setup Guide for WordPress and PHP Sites, and Managed WordPress Hosting for Speed: Which Hosts Handle Caching Best.

Practical examples

These examples show how the framework works in common real-world cases.

Example 1: CSS files always MISS after deploy

Symptoms: CSS is cacheable, but every release causes several hours of origin traffic spikes.

Likely cause: The deployment process purges the entire CDN zone, even though CSS files use content-hashed names.

Fix: Stop full-zone purges for static build assets. Let old files expire naturally and let new hashed file names populate as users request them.

Example 2: Product images bypass cache on an ecommerce store

Symptoms: Image URLs look static, but the CDN reports BYPASS or MISS, and origin image traffic stays high.

Likely cause: Session cookies are attached to all requests, and the CDN is configured to bypass cache when cookies exist.

Fix: Exclude media paths from cookie-based bypass logic, or configure the edge to ignore cookies for known static directories. Be careful with account-specific or signed media URLs.

Example 3: Query strings destroy hit ratio

Symptoms: The same JavaScript file is requested with many marketing parameters, and each one misses separately.

Likely cause: The cache key includes all query parameters by default.

Fix: Ignore known tracking parameters in the cache key. If query strings are used for versioning, only retain the version parameter that actually maps to content changes.

Example 4: HTML remains dynamic, but assets should not

Symptoms: Teams ask, "why is cdn not caching," because page responses stay dynamic, then assume the whole setup is broken.

Likely cause: They are testing logged-in HTML pages rather than static assets. Personalized HTML may correctly bypass cache while CSS, JS, and images remain eligible.

Fix: Test representative asset URLs separately. Build cache rules by content type and path, not by broad assumptions about the whole site.

Example 5: Fonts keep revalidating

Symptoms: Fonts load reliably but generate repeated conditional requests to origin.

Likely cause: Very short max-age with validators enabled.

Fix: Increase TTL for versioned font files. Revalidation is cheaper than a full response, but long-lived immutable assets should not need constant origin checks.

Common mistakes

Most persistent cdn cache miss issues come from a few repeatable errors.

Treating all content the same

HTML, API responses, images, JS, fonts, and user-specific pages should not all share one cache rule. Mixed content types require different TTLs, bypass logic, and invalidation strategies.

Assuming DNS cutover equals effective caching

Moving traffic behind a CDN does not guarantee proper edge caching. DNS performance and edge routing matter, but header policy and cache rules still decide whether objects are reused. If you are reviewing DNS behavior as part of the stack, DNS TTL Best Practices for Websites, Email, and Migrations is a useful reference.

Ignoring the effect of cookies and auth

Authentication logic often expands into places it does not belong. Static asset paths should be deliberately tested for cookie handling.

Overusing purges

Purges are necessary, but they should be targeted. A CDN with a constant full-cache purge pattern behaves more like a proxy than a cache.

Confusing browser cache with CDN cache

They work together, but they are different layers with different controls. An asset may be cached in the browser and still miss at the CDN for first-time visitors, or vice versa.

Skipping repeated tests

A single request tells you almost nothing. Test the same URL several times, from the same conditions, and then with controlled variations. You are trying to discover which input changes the cache result.

Testing only through the application UI

Use direct requests to the asset URL. A homepage waterfall can hint at problems, but direct header inspection is usually faster and more precise.

When to revisit

Cache miss troubleshooting is not a one-time task. Revisit your CDN rules and diagnostics whenever one of these changes occurs:

• You change CDN providers or enable new edge features
• You redesign asset paths, hostnames, or build pipelines
• You move to managed WordPress hosting or a different web hosting stack
• You add personalization, ecommerce features, or login-heavy behavior
• You see unexplained origin load increases after releases
• You adopt new cache-control patterns, such as immutable assets or provider-specific edge overrides

A simple operating checklist helps keep things healthy:

1. Pick 5 to 10 representative asset URLs.
2. Record current headers, cache status, and repeat-request behavior.
3. Review cache key inputs: query strings, cookies, hostnames, and headers.
4. Check TTLs and purge frequency after each deployment change.
5. Compare CDN misses with origin cache performance so you know where requests are really landing.
6. Track cache hit ratio trends over time, not just one-off tests.

If you are also evaluating providers, keep your requirements grounded in diagnostics rather than marketing. Your best CDN is the one that lets you define cacheability clearly, inspect cache status easily, and avoid accidental origin dependency. For broader platform decisions, see Best CDN for Small Business Websites: Pricing, Performance, and Ease of Use.

The practical takeaway is this: when assets keep hitting origin, start with headers, then move to cache key design, then purge and deployment behavior. Most issues are not mysterious. They are usually a mismatch between what your origin emits, what your CDN is allowed to cache, and how many request variations your edge sees. Once those three areas are aligned, cdn caching becomes much more predictable, and origin traffic falls for the right reasons rather than by accident.