A CDN edge cache is the part of a content delivery network that actually does the heavy lifting. While the broader concept of a CDN is to distribute your content geographically, the edge cache is the specific mechanism that stores files at each network node, so visitors retrieve data from a server nearby rather than one on the other side of the planet. If you've ever noticed an overseas website load almost as fast as a local one, you've seen edge caching in action.
What "edge" actually means in networking
In networking, the "edge" refers to the outermost point of a network, closest to the end user. An edge server sits at the boundary between the wider internet and the user's local connection. Rather than routing every request back to a central origin server, an edge cache intercepts it locally, checks whether it already holds a fresh copy of the requested file, and serves it directly if it does. That saved round trip is measured in milliseconds, but across thousands of simultaneous users, those milliseconds add up to something significant.
Edge nodes are placed in cities and internet exchange points worldwide. A major CDN provider like Cloudflare operates hundreds of these locations. When a user in Perth requests an image hosted on a server in Virginia, the request hits the nearest edge node first. If that node holds a cached copy of the image, it responds immediately. The Virginia server never sees the request.
How the cache actually stores and retrieves files
When a file arrives at an edge node for the first time, the node fetches it from the origin server and stores a copy locally. Every subsequent request for that file gets served from the edge copy. This is called a cache hit. A cache miss happens when the edge node doesn't hold the file yet, forcing it to fetch from the origin and then cache the result for next time.
Each cached file carries metadata that tells the edge node how long to keep it. This is controlled primarily through HTTP headers, specifically the Cache-Control header. A value like max-age=86400 tells the edge cache to serve its stored copy for up to 24 hours before checking the origin for a fresher version. When that time expires, the cached file is considered stale. The node either revalidates it (asking the origin "has anything changed?") or fetches a new copy outright.
The revalidation process uses a mechanism called an ETag or a Last-Modified timestamp. If the origin confirms nothing has changed, it returns a 304 Not Modified response, the edge node updates its timer, and no full file transfer happens. It's a small but efficient shortcut.
Cache invalidation: the hard part
Getting content into a cache is straightforward. Getting outdated content out is where things get complicated. Cache invalidation is the process of telling edge nodes to discard or refresh a stored copy before its natural expiry. Without it, users could see old versions of your website for hours or days after you've updated it.
CDN providers offer purge APIs for this reason. A developer or deployment system sends a purge request specifying a URL, a tag, or an entire path prefix, and the CDN signals its edge nodes to drop the matching cached copies. The next request for that content forces a fresh fetch from origin. Some platforms automate this step, triggering a cache purge automatically on each deployment.
Getting invalidation wrong is one of the most common CDN configuration mistakes. Cache TTLs set too high mean stale content lingers. TTLs set too low eliminate most of the caching benefit and push excessive load back to the origin server. The right setting depends on how frequently the content changes.
Edge caching versus browser caching
These two mechanisms are often confused. Browser caching stores files on the user's own device, so repeated visits to the same site skip the network entirely for already-downloaded assets. Edge caching stores files at a network node between the user and the origin, benefiting every user in that region, not just returning visitors.
Both use similar HTTP headers to control their behaviour, which adds to the confusion. But they serve different purposes. Browser caching helps individuals on return visits. Edge caching helps everyone on first and subsequent visits. A well-configured system uses both layers together.
This distinction connects closely to how a CDN works at the broader level. The CDN as a whole handles routing and distribution across its network; edge caching is the storage layer that makes that distribution useful.
What kinds of content get cached at the edge
Static assets are the natural fit: images, CSS files, JavaScript bundles, fonts, PDFs, and video segments. These files don't change per user, so a single cached copy serves every visitor equally well.
Dynamic content is trickier. A personalised dashboard or a shopping cart page changes per user, so caching it at the edge would serve the wrong data. Most CDN setups exclude dynamic pages by default or use short TTLs for semi-dynamic content like news feeds. Some advanced configurations cache dynamic responses at the edge using Vary headers, which instruct the cache to store separate copies based on request characteristics like the Accept-Language header or a logged-in cookie.
Understanding this boundary matters when you're diagnosing why some parts of a site feel fast and others don't. The slow sections are usually the ones that can't be served from cache. Improving those requires a different approach, often involving load balancing and origin-side optimisation rather than caching alone.
Why edge cache hit rate matters
A CDN's effectiveness is measured by its cache hit ratio: the percentage of requests served directly from the edge without touching the origin. A ratio of 90% means 9 out of 10 requests never reach your server. That cuts bandwidth costs, reduces origin load, and speeds up response times for the vast majority of users.
A low hit ratio usually points to one of a few problems: content is changing too frequently relative to its TTL, URLs contain query strings that prevent the cache from recognising identical resources, or the CDN configuration is excluding content that could safely be cached. Reviewing cache headers and CDN logs is the standard way to diagnose and improve the ratio.
Edge caching is not a set-and-forget configuration. It rewards ongoing attention to expiry policies, purge strategies, and what actually gets cached versus what hits the origin on every request.