CDN Strategy for Global Marketing Sites
Why Geography Still Dominates Latency
Even with modern networks, physical distance from origin server to visitor adds real round-trip time — roughly 20-30ms per 1,000km, before you even factor in TLS handshakes and server processing. A marketing site serving global traffic from a single origin in, say, us-east-1 will show visibly worse TTFB for visitors in Singapore or São Paulo than for visitors in Virginia. A Content Delivery Network (CDN) solves this by caching and serving content from edge nodes geographically close to the visitor, often cutting latency by 50-80% for international traffic.
What a CDN Actually Caches on a Marketing Site
Static assets — images, fonts, CSS, JS bundles — are the easy case; virtually every CDN caches these well by default based on Cache-Control headers. The harder and more valuable case for marketing sites is caching full HTML pages at the edge. Platforms like Vercel, Netlify, and Cloudflare support edge-cached HTML for statically generated or ISR (Incremental Static Regeneration) pages, meaning the full landing page — not just its assets — is served from the nearest edge node without hitting origin at all, unless it's stale and needs revalidation.
// Example Next.js config setting explicit cache headers for a CDN
// to respect on static marketing assets and ISR pages.
const nextConfig = {
async headers() {
return [
{
source: "/_next/static/:path*",
headers: [
{ key: "Cache-Control", value: "public, max-age=31536000, immutable" },
],
},
{
source: "/landing/:slug*",
headers: [
// Edge caches the page for 60s, serves stale for up to 1hr while revalidating
{ key: "Cache-Control", value: "public, s-maxage=60, stale-while-revalidate=3600" },
],
},
];
},
};
module.exports = nextConfig;CDN Choice Is Also a Personalization Constraint
Choosing a CDN/Edge Platform
For marketing sites specifically, the relevant comparison points aren't just raw node count:
- Vercel/Netlify: tightly integrated with Next.js/Jamstack frameworks, excellent DX, built-in ISR and edge middleware, good default for most modern marketing sites.
- Cloudflare: largest edge network by PoP count, strong at the network layer (DDoS, WAF) and Workers for compute-at-edge, less opinionated about framework.
- Fastly/Akamai: enterprise-grade, used by large-scale commerce and media sites needing granular cache invalidation (purge-by-surrogate-key) and SLA guarantees, usually overkill for a standard marketing site under enterprise contracts already in place.
Cache Invalidation Is the Hard Part, Not Caching
Caching content is easy; invalidating it correctly when a marketer publishes a change is where most CDN strategies break down. Common patterns:
- Time-based (TTL): simplest, but means published changes take up to the TTL duration to appear everywhere — unacceptable for time-sensitive promos.
- Purge-on-publish: the CMS webhook triggers an explicit CDN purge for the specific path when content changes. Requires wiring the CMS's publish event to the CDN's purge API.
- Surrogate keys/cache tags: tag cached responses with identifiers (e.g., promo-banner, author-jane) so a single content change purges only the affected pages, not the entire cache — critical at scale to avoid a full cache-cold stampede on every edit.
A Global CDN Doesn't Fix a Slow Origin for Dynamic Content
What's Next?
With delivery infrastructure covered, the next layer up the stack is the platform actually producing these pages — and how CMS choice shapes everything from caching to personalization capability.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.