CDN and Edge Caching: Complete Guide to Optimal Response Times in 2026
Content distribution speed has become a primary competitive differentiator in 2026. Users expect sub-100-millisecond response times, and search engines impose measurable ranking penalties on sites with elevated Time to First Byte (TTFB) values. In this environment of extreme performance expectations, Content Delivery Networks (CDN) and edge caching strategies form the technical bedrock of every high-performance web architecture.
Yet configuring a CDN extends far beyond placing a cache in front of your origin server. The architectural decisions surrounding cache layers, expiration policies, and edge-executed logic directly determine user experience quality, data freshness, and the system's capacity to absorb massive traffic spikes without degradation. A flawed understanding of these mechanisms routinely leads to stale content served to visitors, premature cache purges that overwhelm the origin server, or contradictory header configurations that neutralize the entire caching strategy.
This engineering guide dissects the inner workings of modern CDNs and edge caching architectures. From the fundamental theory of Points of Presence to advanced tag-based invalidation strategies and the multi-layered cache architecture specific to Next.js, the goal is to equip engineering teams with the knowledge required to build a distribution infrastructure that is both extremely fast and fully under control.
CDN fundamentals
What is a CDN and why it matters
A Content Delivery Network is a geographically distributed network of servers whose mission is to physically bring content closer to the end user. Without a CDN, every request from a visitor in Tokyo to a site hosted in Virginia must traverse the full breadth of the global internet, accumulating latency proportional to the distance traveled. Physics imposes a hard lower bound: light in fiber optic cable travels at roughly 200,000 kilometers per second, meaning a round trip from Virginia to Tokyo adds at minimum 70 milliseconds of pure network latency before the origin server even begins processing.
A CDN solves this fundamental problem by replicating content across hundreds of servers called Points of Presence (PoPs) strategically positioned across every continent. When a user makes a request, the CDN automatically routes that request to the geographically nearest PoP, reducing transit latency to single-digit milliseconds. The origin server is shielded from the majority of traffic, and users worldwide receive consistently fast responses regardless of their physical location.
Anycast, PoPs, and intelligent routing
The technology enabling a CDN to direct each request to the correct edge server is called Anycast. In traditional routing (Unicast), a single IP address maps to a single physical server. Anycast allows hundreds of servers distributed worldwide to announce the identical IP address. The Border Gateway Protocol (BGP) that underpins internet routing then automatically directs each packet to the nearest instance in terms of network hops.
This mechanism delivers two significant advantages. First, routing is entirely transparent to the client: no complex DNS configuration is necessary, and failover between PoPs in case of outage is automatic and near-instantaneous. Second, this architecture naturally distributes load across network nodes, providing native resilience against Distributed Denial of Service (DDoS) attacks. A massive flood of malicious requests is automatically spread across dozens of PoPs rather than converging on a single point of failure.
Push CDN vs Pull CDN
Two fundamental models govern how content arrives on CDN edge servers.
The Pull model is the most prevalent in modern web architectures. Under this model, the CDN stores nothing proactively. When a user requests a resource for the first time, the nearest PoP does not have the file cached and must "pull" it from the origin server. This initial request incurs the full origin latency. The PoP then stores the response in local cache and serves all subsequent requests directly from memory, without contacting the origin. This model is ideal for dynamic websites where content changes regularly, as cache management is fully automated through HTTP headers.
The Push model works in reverse: the content owner proactively pushes files to CDN servers before any user requests them. This model is relevant for distributing large files (software updates, video catalogs) where first-request latency is unacceptable. However, it requires heavier manual management and consumes more storage across the entire network.
Edge caching vs origin caching
Cache layers explained
A performant caching architecture never relies on a single level. It is organized in successive layers, each serving as a safety net for the next, all working together to minimize the number of requests that actually reach the origin server.
The first layer is the browser cache. When a user visits a page, their browser stores static resources locally (images, CSS, JavaScript, fonts) according to Cache-Control header directives. On subsequent visits, these resources are served directly from the client's local disk with zero network requests. This is the fastest layer, with access times measured in microseconds.
The second layer is the edge cache hosted on CDN PoPs. When the browser cache does not contain the resource or it has expired, the request reaches the CDN. If the PoP holds a valid cached copy, it returns it instantly with single-digit millisecond latency. This layer eliminates the bulk of geographic latency and absorbs the majority of public traffic.
The third layer is the origin cache, sometimes called an Origin Shield. Some CDN providers offer a single intermediary node that buffers between PoPs and the origin server. Instead of each PoP individually contacting the origin on a cache miss, they first query the shield. This mechanism drastically reduces origin load and protects against request storms that occur when popular content expires simultaneously across multiple PoPs.
TTL and expiration policies
Time to Live (TTL) is the duration for which a cached resource is considered valid. Setting the right TTL is a balancing act between performance (longer TTL maximizes cache hits) and freshness (shorter TTL ensures updates propagate quickly).
For immutable static resources (JavaScript and CSS files with content hashes in the filename, optimized images), a one-year TTL is standard practice. The hash embedded in the filename (main.a1b2c3.js) guarantees that a new version generates a new file, naturally bypassing the cache without requiring a purge.
For HTML documents and API responses, the TTL depends on content nature. A published blog post can tolerate a TTL of several hours or even days. A dynamic search results page will need a much shorter TTL, potentially a few seconds, paired with a revalidation strategy.
Stale-while-revalidate: freshness without latency
The stale-while-revalidate directive is one of the most effective tools in the HTTP caching arsenal. Its operation follows a simple but elegant principle: serve the cached version immediately (even if it has just expired) while triggering an asynchronous background request to the origin for a fresh version.
Cache-Control: public, max-age=60, stale-while-revalidate=3600In this example, the resource is considered perfectly fresh for 60 seconds. Between 60 and 3,660 seconds (60 + 3,600), the CDN will serve the expired version instantly to the user while requesting the origin in the background. The next request will receive the updated version. Beyond 3,660 seconds, the cache is considered fully invalid, and the next request must wait for the origin response.
Cache-Control headers deep dive
max-age and s-maxage
The Cache-Control header is the central mechanism for HTTP cache management. Its max-age directive defines cache validity duration in seconds, applicable to both browser caches and intermediary caches.
The s-maxage (shared max-age) directive is designed specifically for shared caches such as CDNs and reverse proxies. When present, it overrides max-age for shared caches while allowing max-age to govern browser cache behavior independently.
Cache-Control: public, max-age=0, s-maxage=86400, stale-while-revalidate=43200This configuration is a classic production pattern: the browser never caches the HTML document locally (max-age=0), ensuring it always contacts the CDN. The CDN, however, retains the page in cache for 24 hours (s-maxage=86400) and accepts serving a stale version for an additional 12 hours while revalidating in the background. The user always receives an ultra-fast response from the CDN, and the origin server is contacted at most once per day per PoP.
no-cache vs no-store
The confusion between no-cache and no-store is one of the most common and costly configuration errors in web performance.
no-cache does not mean "do not cache." This directive permits caching but mandates obligatory revalidation with the origin server before each use. The cache retains the resource and sends a conditional request (using an If-None-Match or If-Modified-Since header). If the server confirms the resource has not changed, it responds with a 304 Not Modified status (without a response body), and the cache serves its local copy. This approach is excellent for HTML documents of dynamic pages where freshness matters.
no-store is the most restrictive directive. It completely forbids storing the response in any cache -- browser, CDN, or intermediary. Every request must reach the origin and download the full response. This directive is reserved for sensitive data (user account pages, banking information, authentication tokens) that must never persist on shared disk or memory.
# Mandatory revalidation (good for dynamic HTML)
Cache-Control: no-cache
# No caching at all (reserved for sensitive data)
Cache-Control: no-store
# Common mistake: combining both is redundant
# no-store already implies no-cache behavior
Cache-Control: no-cache, no-storeprivate vs public
The private directive indicates that the response is intended for a single user and must only be stored in the local browser cache. Shared caches (CDNs, reverse proxies) must not store it. This is the appropriate directive for personalized responses: user dashboards, shopping carts, personalized feeds.
The public directive explicitly authorizes storage by any intermediary, including shared caches. It is generally implicit when s-maxage is present, but specifying it explicitly is considered a best practice for configuration readability.
# Personalized page (cart, profile)
Cache-Control: private, no-cache
# Public page (article, product page)
Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400
# Immutable static asset (CSS/JS with hash)
Cache-Control: public, max-age=31536000, immutableThe immutable directive deserves particular attention. It tells the browser that the resource will never change during its cache lifetime. The browser will send no conditional revalidation requests, even when the user performs a hard reload. This directive is perfectly suited for files whose names contain a content hash.
CDN providers comparison
Vercel Edge Network
Vercel's edge network is deeply integrated with the Next.js ecosystem, making it the natural choice for applications built on this framework. The integration is seamless: deploying through the Vercel platform automatically activates CDN distribution with no additional configuration. Static assets are served with optimal cache headers, and statically generated pages (SSG) are delivered directly from edge cache.
Vercel's primary strength lies in its native handling of Incremental Static Regeneration (ISR) and on-demand revalidation. Revalidation functions triggered by webhooks or content mutations propagate instantly across the entire network without manual purges. The pricing model is consumption-based (bandwidth, function executions), making it predictable for moderate-traffic projects but potentially expensive at scale.
Cloudflare
Cloudflare operates one of the most extensive networks globally with over 300 PoPs covering virtually every country. Beyond traditional CDN services, Cloudflare provides a comprehensive suite of security (DDoS protection, WAF, Bot Management) and performance (Brotli compression, image optimization, automatic minification) features integrated directly at the network edge.
Cloudflare's CDN offering is distinguished by its economic model: the free plan includes unlimited CDN bandwidth, making it accessible to projects at any stage of growth. Advanced caching features (Cache Rules, Tiered Cache with Origin Shield) are available on paid plans. Cloudflare's architecture is particularly well-suited for high-traffic sites requiring robust network protection.
AWS CloudFront
Amazon CloudFront is the CDN within the Amazon Web Services ecosystem. Its native integration with other AWS services (S3 for storage, Lambda@Edge for edge compute, WAF for security) makes it a logical choice for organizations already invested in the AWS infrastructure.
CloudFront offers granular control over cache behavior through its "Cache Policies" and "Origin Request Policies," allowing precise definition of which headers, cookies, and query parameters influence the cache key. This granularity is a significant advantage for complex applications serving personalized content. However, the learning curve and configuration complexity are substantially higher than Cloudflare or Vercel.
Fastly
Fastly positions itself as the CDN built for engineers. Its VCL (Varnish Configuration Language) technology and native Compute@Edge support offer an unmatched level of cache behavior customization. Instant purge (global propagation in under 150 milliseconds) is Fastly's key differentiator, making it particularly suited for news publications and e-commerce platforms where content freshness is the absolute priority.
Edge computing and edge functions
From passive cache to active compute
The most significant evolution of CDNs in recent years is their transformation from passive content caches into active compute platforms. Historically, a PoP simply stored and returned files. Today, edge servers are capable of executing code, opening the door to an entirely new category of applications: edge functions.
An edge function is a serverless compute unit executed directly on a CDN PoP, as close to the user as physically possible. Unlike traditional serverless functions (AWS Lambda, Google Cloud Functions) deployed in a specific region, an edge function is deployed instantly across hundreds of PoPs simultaneously. Cold start time is typically under 5 milliseconds, compared to several hundred milliseconds for a conventional serverless function.
Middleware and Vercel Edge Functions
In the Next.js ecosystem deployed on Vercel, Middleware is the primary mechanism for executing logic at the edge. The middleware.ts file placed at the project root intercepts every incoming request before it reaches the application logic. This interception runs on the Vercel Edge Runtime, delivering ultra-fast execution times.
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
// Geolocation detection via CDN headers
const country = request.geo?.country || 'US';
const pathname = request.nextUrl.pathname;
// Geographic redirect to the appropriate locale
if (pathname === '/' && country === 'DE') {
return NextResponse.redirect(new URL('/de', request.url));
}
// Add custom cache headers
const response = NextResponse.next();
response.headers.set('X-Edge-Location', country);
response.headers.set('Cache-Control', 'public, s-maxage=3600, stale-while-revalidate=86400');
return response;
}
export const config = {
matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'],
};This middleware executes in under 5 milliseconds on every PoP and enables routing decisions, personalization, or security enforcement without adding perceptible latency to the response time.
Cloudflare Workers
Cloudflare Workers are JavaScript functions executed across Cloudflare's global network. They run on the V8 runtime (the same engine powering Chrome) and provide full access to HTTP request and response manipulation APIs. Their cold start time is under one millisecond, making them suitable for any real-time transformation logic.
// Cloudflare Worker: conditional caching by geolocation
export default {
async fetch(request, env) {
const url = new URL(request.url);
const country = request.cf?.country || 'US';
// Build a cache key that includes the country
const cacheKey = new Request(`${url.origin}${url.pathname}?country=${country}`, request);
const cache = caches.default;
// Check the edge cache
let response = await cache.match(cacheKey);
if (response) {
return response;
}
// Cache miss: fetch from origin
response = await fetch(request);
response = new Response(response.body, response);
response.headers.set('Cache-Control', 'public, s-maxage=3600');
// Store in edge cache
await cache.put(cacheKey, response.clone());
return response;
}
};Cache invalidation strategies
The fundamental invalidation problem
Phil Karlton famously stated that there are only two hard problems in computer science: naming things and cache invalidation. In the context of a CDN distributed across hundreds of PoPs, this problem takes on a particular dimension. When content changes at the origin, how do you ensure all edge nodes serve the updated version within an acceptable timeframe without sacrificing the performance benefits of caching?
A brute-force global purge (deleting the entire cache across all PoPs) is the simplest method but also the most destructive. After a complete purge, every subsequent request triggers a cache miss and hits the origin directly. If the site receives significant traffic volume, this request storm can overwhelm the origin server and cause service degradation or complete outage. The art of invalidation lies in purging surgically -- only what has changed -- while minimizing impact on the overall cache hit ratio.
Path-based invalidation
The most straightforward strategy is purging the cache for a specific URL when the corresponding content is modified. If a blog post is updated, you invalidate only the path /blog/my-article and potentially the listing page /blog.
# Purge a specific path via the Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
--data '{"files":["https://example.com/blog/my-article","https://example.com/blog"]}'This method works well for predictable, isolated changes. However, it reaches its limits when content dependencies are complex. Updating a product listing might impact the product page, the category page, the sitemap, internal search results, and the RSS feed. Manually identifying and purging all dependent URLs is tedious and prone to omissions.
Tag-based invalidation
Tag-based invalidation (or cache tags) solves the limitations of path-based approaches. The principle is to associate semantic labels with cached responses. When rendering a product page, you tag it with identifiers like product:123, category:electronics, brand:samsung. The category page is tagged with category:electronics and listing:page-1.
When product 123 is modified, you simply purge the tag product:123. The CDN automatically identifies all resources associated with that tag across all its PoPs and invalidates them. No need to know specific URLs; propagation is automatic and exhaustive.
# Response header associating tags with cache
Cache-Tag: product:123, category:electronics, brand:samsung, currency:usd# Tag-based purge via the Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
--data '{"tags":["product:123"]}'On-demand revalidation
In the Next.js ecosystem, on-demand revalidation is the native cache invalidation mechanism. Rather than purging URLs or tags at the CDN level, the framework exposes an API that allows triggering the regeneration of a specific page or a set of pages associated with a tag.
// app/api/revalidate/route.ts
import { revalidateTag, revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';
export async function POST(request: NextRequest) {
const { tag, path, secret } = await request.json();
// Verify secret to secure the endpoint
if (secret !== process.env.REVALIDATION_SECRET) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}
if (tag) {
// Invalidate all pages using this cache tag
revalidateTag(tag);
return NextResponse.json({ revalidated: true, tag });
}
if (path) {
// Invalidate a specific page
revalidatePath(path);
return NextResponse.json({ revalidated: true, path });
}
return NextResponse.json({ error: 'Missing tag or path' }, { status: 400 });
}This endpoint is typically called by a webhook from your headless CMS when content is published or modified. The affected page is regenerated in the background and the cache is updated, all without manual intervention.
Next.js caching architecture
Data Cache
The Next.js Data Cache is a server-side persistence layer dedicated to the results of data calls made via fetch() in Server Components and Route Handlers. When a server component makes an API call to a headless CMS, the response is stored in the Data Cache and reused for subsequent requests without re-calling the external API.
// The result of this fetch is automatically cached
const posts = await fetch('https://api.cms.com/posts', {
next: { tags: ['blog-posts'], revalidate: 3600 }
});The revalidate: 3600 configuration indicates that the cache will be considered valid for one hour. After this period, the next request will trigger a background regeneration following the stale-while-revalidate pattern. The blog-posts tag enables targeted invalidation via revalidateTag('blog-posts').
Full Route Cache
The Full Route Cache (previously known as the Static Cache) stores the complete HTML output of a rendered route. For pages statically generated at build time (SSG), this cache is populated during compilation. For pages using ISR, it is populated on the first request and revalidated according to the defined rules.
The distinction between Data Cache and Full Route Cache is subtle but fundamental. The Data Cache stores raw data (JSON API responses). The Full Route Cache stores the final product (the HTML document generated from that data). Invalidating the Data Cache automatically triggers invalidation of the associated Full Route Cache, but the reverse is not true.
// app/blog/[slug]/page.tsx
// Generate static paths at build time
export async function generateStaticParams() {
const posts = await fetch('https://api.cms.com/posts').then(r => r.json());
return posts.map((post: { slug: string }) => ({ slug: post.slug }));
}
// This component is rendered once then stored in the Full Route Cache
export default async function BlogPost({ params }: { params: { slug: string } }) {
const post = await fetch(`https://api.cms.com/posts/${params.slug}`, {
next: { tags: [`post:${params.slug}`] }
}).then(r => r.json());
return (
<article>
<h1>{post.title}</h1>
<div>{post.content}</div>
</article>
);
}Router Cache (client-side cache)
The Router Cache is a cache layer that operates entirely within the user's browser. As a visitor navigates between pages of a Next.js application, the framework prefetches routes visible in the viewport and stores RSC (React Server Components) payloads in memory. Subsequent navigations to those pages are instant because the content is already present in the browser's in-memory cache.
This client cache has a limited lifespan: 30 seconds for dynamic routes and 5 minutes for static routes (default values in Next.js 15). These durations can be adjusted through the staleTimes configuration in next.config.js.
// next.config.js
module.exports = {
experimental: {
staleTimes: {
dynamic: 30, // seconds
static: 300, // seconds
},
},
};Dynamic content at the edge
Personalization via geolocation
One of the major challenges with CDNs is handling personalized content. By definition, a personalized page differs for each user, which appears fundamentally incompatible with caching. Geolocation offers a performant compromise: content varies not per individual user but per geographic region, allowing a high cache hit ratio while still delivering an adapted experience.
Modern CDNs automatically inject geolocation headers into every request (cf-ipcountry on Cloudflare, x-vercel-ip-country on Vercel). The application can use this information to adapt the displayed currency, the default language, or product availability, while serving a cached version segmented by country or region.
// app/page.tsx - Country-based personalization via headers
import { headers } from 'next/headers';
export default async function HomePage() {
const headersList = await headers();
const country = headersList.get('x-vercel-ip-country') || 'US';
// Country-specific business logic
const currency = country === 'US' ? 'USD' : country === 'GB' ? 'GBP' : 'EUR';
const products = await fetch(`https://api.store.com/products?currency=${currency}`, {
next: { tags: [`products:${country}`], revalidate: 600 }
}).then(r => r.json());
return <ProductGrid products={products} currency={currency} />;
}A/B testing at the edge
Traditional A/B testing relies on client-side JavaScript that modifies the DOM after initial load, causing visual flashes (FOUC) and layout shifts (CLS). Running variant assignment logic directly at the edge eliminates these issues by serving the correct version of the page from the start.
The middleware intercepts the request, checks whether the user already has a variant assignment cookie, and assigns one if needed. The request is then routed to the page corresponding to the variant, and the response is cached separately for each variant.
// middleware.ts - A/B testing at the edge
import { NextRequest, NextResponse } from 'next/server';
const EXPERIMENT_COOKIE = 'ab-pricing-v2';
const VARIANTS = ['control', 'variant-a', 'variant-b'];
export function middleware(request: NextRequest) {
const pathname = request.nextUrl.pathname;
if (pathname !== '/pricing') return NextResponse.next();
// Check if the user already has an assigned variant
let variant = request.cookies.get(EXPERIMENT_COOKIE)?.value;
if (!variant || !VARIANTS.includes(variant)) {
// Weighted random assignment
const random = Math.random();
variant = random < 0.34 ? 'control' : random < 0.67 ? 'variant-a' : 'variant-b';
}
// Rewrite to the variant page (without changing the visible URL)
const url = request.nextUrl.clone();
url.pathname = `/pricing/${variant}`;
const response = NextResponse.rewrite(url);
// Persist the variant in a cookie
response.cookies.set(EXPERIMENT_COOKIE, variant, {
maxAge: 60 * 60 * 24 * 30, // 30 days
path: '/',
});
return response;
}Feature flags and progressive rollouts
The edge is also the ideal execution point for feature flags and canary deployments. Rather than embedding feature flag logic in the client JavaScript bundle (which increases bundle size and exposes configuration), the middleware can evaluate flags at the edge and serve the appropriate page version.
This approach enables progressive rollout of a new feature to an increasing percentage of users, controlling exposure from the edge without deploying new code. If an issue is detected, rollback is instantaneous: modifying the flag configuration immediately redirects all traffic to the stable version.
Monitoring and debugging cache behavior
Reading response headers
The first step in debugging a caching problem is inspecting HTTP response headers. Every CDN adds specific headers that reveal cache behavior for each request.
# Inspect cache headers for a URL
curl -I https://example.com/blog/my-articleHTTP/2 200
cache-control: public, s-maxage=3600, stale-while-revalidate=86400
x-cache: HIT
x-cache-age: 1842
cf-cache-status: HIT
age: 1842
x-vercel-cache: HITThe headers to monitor:
x-cacheorcf-cache-statusorx-vercel-cache: indicates whether the response came from cache (HIT), from the origin (MISS), or was revalidated (STALE,REVALIDATED).age: the number of seconds since the response was stored in cache. A highagevalue confirms the resource is genuinely being served from cache.cache-control: the directives governing cache behavior. Verifying these values match the expected configuration is the first step in any diagnostic process.
Cache hit rates and miss analysis
The cache hit ratio is the single most important metric for evaluating your caching strategy's effectiveness. It represents the percentage of requests served directly from edge cache without contacting the origin. A hit ratio above 90% is considered excellent for a content site. A ratio below 70% typically indicates a configuration problem.
The most common causes of insufficient hit ratios:
- Excessive cache key variation: if the CDN includes query strings, cookies, or variable headers in the cache key, every unique combination generates a distinct cache entry. For example, a UTM parameter (
?utm_source=google) creates a separate entry from the URL without the parameter, even though the content is identical. - TTL values set too low: a TTL of a few seconds does not give requests enough time to benefit from cache, particularly on low-traffic pages.
- Excessive cookies: some CDNs automatically exclude requests containing cookies from cache. A session cookie sent on every request can neutralize your entire caching strategy.
# Check if query strings affect the cache
curl -I "https://example.com/page"
curl -I "https://example.com/page?utm_source=newsletter"
# If both return x-cache: MISS, the CDN treats query strings
# as part of the cache key -- fix in CDN configurationDiagnostic tools
CDN providers offer integrated monitoring dashboards. Cloudflare Analytics displays real-time cache hit ratios, geographic request distribution, and bandwidth savings. Vercel Analytics provides similar metrics with direct Web Vitals integration.
For in-depth diagnostics, command-line tools remain indispensable:
curl -Ito inspect headers for a specific URLcurl -H "Cache-Control: no-cache"to force a cache miss and test origin behavior- WebPageTest to visualize the full network waterfall and identify uncached requests
- Chrome DevTools (Network tab) to analyze browser cache behavior and verify headers in real context
Implementation checklist
Before deploying to production, validate each point on this list to ensure a coherent and performant caching strategy.
Header configuration
- Immutable static assets (CSS/JS with hash) use
Cache-Control: public, max-age=31536000, immutable - Public HTML documents use
s-maxagewithstale-while-revalidatefor the CDN andmax-age=0for the browser - Personalized pages use
Cache-Control: private, no-cache - Sensitive data (authentication endpoints, profiles) uses
Cache-Control: no-store - No public static resource uses
no-storeby mistake
CDN architecture
- CDN is configured in Pull mode with Origin Shield enabled
- Non-relevant query strings (UTM, fbclid, gclid) are excluded from the cache key
- Non-essential cookies are excluded from the cache key
- Brotli or Gzip compression is enabled at the CDN level
- HTTP/2 or HTTP/3 is enabled between CDN and client
Invalidation
- An on-demand revalidation mechanism is in place (CMS webhook to revalidation endpoint)
- The revalidation endpoint is protected by a shared secret
- Cache tags are semantically defined for each content type
- An emergency purge procedure is documented and tested
Monitoring
- Cache hit ratio is monitored with an alert configured below the 85% threshold
- Cache headers are verified after every deployment
- Field Data TTFB metrics are tracked via a RUM tool
- A periodic cache key audit is scheduled to detect unintended variations
Next.js specific
- Data Cache is properly configured with tags for each external data source
- Eligible pages are statically pre-rendered (SSG) at build time
- The
next/imagecomponent usespriorityfor LCP images - Router Cache
staleTimesdurations are adapted to freshness requirements
Mastering CDN and edge caching strategies is not an engineering luxury: it is the technical foundation upon which the user experience of every ambitious web application rests in 2026. From granular Cache-Control header configuration to orchestrating tag-based invalidations, every architectural decision directly influences TTFB, cache hit ratios, and ultimately visitor satisfaction. Organizations that invest in deeply understanding these mechanisms and methodically integrating them into their deployment pipelines secure an infrastructure that is resilient, fast, and capable of serving millions of requests without degradation. Performance is not a one-time objective; it is a continuous discipline that, when properly applied, transforms speed into a lasting competitive advantage.
