A content delivery network (CDN) cache is a temporary store of website or application content located on servers closer to end users. Instead of retrieving the same content from an origin server every time someone requests it, a CDN can keep a cached copy at the network edge and serve it directly.
The result is faster content delivery, fewer requests to origin infrastructure, and greater resilience when traffic spikes or origin systems experience problems.
What is a cache?
A CDN cache stores copies of content at edge locations, also known as points of presence (POPs), distributed across a CDN's network.
When someone visits a website or uses an application, the CDN can check whether the requested content is already available in a nearby cache. If it is, the CDN can return the cached copy instead of making another request to the application's origin server.
CDN caches are commonly associated with static assets like:
Images
JavaScript and CSS files
Fonts
Videos and other media
Software downloads
Modern CDNs can also cache HTML, API responses, and other frequently changing or dynamic content when appropriate caching policies are applied. Cached objects have a defined ‘freshness period’ and may also be evicted by the CDN as it manages its available cache capacity.
How does a CDN cache work?
CDN caching generally follows a request-and-response process:
A user requests content. A browser, mobile app, API client, or another application sends a request for a resource (a webpage, image, video etc).
The CDN receives the request. The request is routed to an appropriate CDN edge location.
The cache looks for the requested object. If a fresh copy is already cached, this is commonly called a cache hit. The CDN can return the object without retrieving it from the origin.
The CDN retrieves missing content. If an eligible object isn't available in cache (called a cache miss) the CDN requests it from the origin or another upstream cache.
The response may be cached. Depending on HTTP caching rules and the CDN's configuration, the response can be stored so subsequent requests can be served from cache.
Cached objects typically have a time to live (TTL) that determines how long they can be considered fresh without consulting the origin. When cached content expires, a CDN may revalidate it with the origin rather than downloading the entire object again.
What is the difference between a CDN cache and a browser cache?
Both store content so it doesn't need to be retrieved repeatedly, but they operate in different places.
A browser cache stores content on an individual user's device. A CDN cache stores content in shared infrastructure at the network edge, where one cached object may be used to fulfill requests from many users.
This distinction is important because website operators have substantially more direct control over CDN cache invalidation. A CDN cannot simply purge an object already stored in an end user's browser cache.
What happens when cached content changes?
Cached content doesn't necessarily have to remain at the edge until its TTL expires.
A CDN can purge or invalidate an object when the source changes. The next request can then retrieve the updated version from the origin and populate the cache again.
This makes invalidation an important part of an effective caching strategy. Instead of setting extremely short TTLs simply because content might change, organizations can cache content for longer and invalidate it when an actual update occurs.
Can dynamic content be cached on a CDN?
Yes. Whether dynamic content should be cached depends on how it is generated, how frequently it changes, and whether the response varies by user or request.
Content like product information, news articles, API responses, or other frequently changing data is suitable for edge caching when paired with appropriate TTLs, cache keys, revalidation, and invalidation.
Fastly specifically supports caching a wider range of content, including dynamic and event-driven content, with rapid purging providing a way to update cached information when necessary.
Why is CDN caching necessary/important?
Without CDN caching, requests may need to travel all the way to an application's origin infrastructure, even when thousands or millions of users are requesting identical content.
Caching helps address several challenges.
Performance: Serving content from a nearby edge location can reduce the network distance and origin processing involved in fulfilling a request, improving response times.
Scalability: A cache can serve the same object repeatedly without generating a corresponding origin request every time. That helps applications accommodate larger audiences and sudden traffic spikes.
Origin offload: Fewer requests reaching origin infrastructure means less computing, networking, and bandwidth demand. Serving more content from cache can consequently reduce infrastructure and origin egress costs.
Reliability and resiliency: Appropriate caching policies can allow some content to remain available even when an origin becomes slow or unavailable.
User experience: Faster and more consistent responses can improve experiences for users who may be geographically far from an application's infrastructure.
What are CDN caching best practices?
There is no single caching policy that works for every application. Effective caching requires balancing performance with content freshness and control. Some useful practices include:
Set explicit caching policies.
Choose TTLs based on how content changes. Long-lived assets like versioned images or JavaScript bundles can often use long TTLs, while rapidly changing information may require shorter freshness periods or active invalidation.
Separate browser and CDN caching when needed. Edge caches can often retain content longer while browsers receive shorter caching instructions, giving application operators more control over updates.
Use targeted invalidation. When content changes, invalidate specific URLs or groups of related objects rather than unnecessarily clearing an entire cache.
Use stale content strategically.
Provide validators. Use of headers allows caches to determine whether stale content has actually changed without always downloading the full object again.
Monitor cache effectiveness. Cache-hit ratios, origin traffic, latency, TTLs, and invalidation patterns can help teams identify content that could be cached more effectively.
Be careful with personalized or sensitive content. Authentication, cookies, authorization headers, and user-specific responses should be incorporated into caching rules so one user's private response isn't unintentionally served to another.
The objective isn't simply to cache as much as possible. It's to cache the right content for the right amount of time while maintaining control over freshness.
Who needs CDN caching?
CDN caching can benefit almost any organization delivering digital content or applications to users, but it becomes particularly valuable at scale.
Ecommerce businesses can cache product assets, category pages, and potentially portions of rapidly changing experiences while retaining control over inventory and pricing updates.
Media and publishing companies can use caching to handle large audiences and traffic surges around breaking stories or popular content.
Streaming and entertainment services can distribute media and related assets closer to audiences.
SaaS and API providers can reduce latency and backend demand by caching eligible application and API responses.
Software and gaming companies can efficiently distribute large files, downloads, patches, and other frequently requested assets.
Global enterprises can provide more consistent application performance to users distributed across different regions.
Even organizations serving primarily dynamic applications may benefit. Modern CDN caching isn't limited to static files: with the right architecture and invalidation strategy, rapidly changing and event-driven content can also be cached at the edge.
What does Fastly offer for CDN caching?/ How can Fastly help
Fastly's Content Delivery Network is designed to give organizations control over what is cached, how long it is cached, and when it is updated.
Fastly's CDN supports caching static as well as dynamic and event-driven content at the edge. Its network architecture uses high-capacity POPs designed to keep more content cached closer to users.
Key caching capabilities include:
Instant Purge™: Fastly enables cached content to be invalidated rapidly when it changes, allowing businesses to cache content for longer without relying exclusively on short TTLs to keep information current. Fastly reports a regional mean purge time of less than 150 milliseconds as of December 31, 2025.
Granular purging: Content can be invalidated by URL or grouped using surrogate keys. Soft purging can mark an object as stale rather than immediately removing it, helping applications continue serving content while refreshing the cache.
Origin Shield: Fastly can use a designated POP as a shield between edge caches and an origin. This can improve cache efficiency and reduce the number of requests reaching origin infrastructure.
Fine-grained cache control: Developers can use standard HTTP caching controls as well as Fastly capabilities to manage CDN caching independently from browser caching.
Stale content and revalidation: Fastly supports ‘stale-while-revalidate’ and ‘stale-if-error’, allowing applications to balance freshness, performance, and resilience.
Programmability and observability: Fastly's CDN provides APIs, configurable delivery logic, and real-time logging and observability, giving development and operations teams greater visibility into and control over content delivery.
By combining edge caching with rapid invalidation and programmable control, Fastly allows organizations to cache more content (including frequently changing content) while retaining control over when users receive updated versions.