CDN, Caching, and Edge: Speeding Up Global B2B Sites

Your buyers in Singapore, Frankfurt, and São Paulo are not getting the same site your team sees in the office. When the origin server lives in one region, every request from the other side of the planet pays a round-trip tax that no amount of clever frontend code can refund. For a B2B marketing or RevOps leader, that tax shows up as slower demos, lower form completion, and field data that quietly drags down your search rankings. Getting cdn caching edge strategy right is how you close that gap without rebuilding the application.

This is not a deep networking lecture. It’s a practical guide to deciding what to cache, where to serve it from, and how to keep your marketing site fast for a genuinely global audience.

Why Distance Is the Hidden Performance Tax

Latency is governed by physics. A request from Sydney to a server in Virginia travels thousands of miles, gets processed, and travels back. Even on a fast connection, that round trip can add hundreds of milliseconds, and a typical page makes dozens of requests. The compounding effect is what makes far-away visitors feel like they’re on a slow connection even when they aren’t.

Two levers reduce this tax:

• Distance: serve content from a location physically near the visitor.
• Round trips: avoid asking the origin server at all when you can answer from a cache.

A content delivery network (CDN) addresses both. It maintains points of presence (PoPs) around the world and serves cached copies of your content from the PoP closest to each visitor. Edge computing goes a step further, running logic at those same locations instead of routing everything back to a single origin.

The fastest request is the one your origin never sees. Every layer of caching you add between the visitor and the origin is a layer of speed and resilience.

If your architecture itself is working against you, no CDN will fully save you. We cover the structural side in The B2B Website Architecture That Converts, and the two efforts reinforce each other.

Building a CDN Caching Edge Strategy That Holds Up

A CDN only helps with what it’s allowed to cache. The most common mistake we see is a CDN sitting in front of a site that tells it, through cache headers, to cache almost nothing. The result is a global network of expensive proxies that still phone home for every request.

Start by classifying your content into three buckets.

1. Static assets

Images, fonts, CSS, JavaScript bundles, and downloadable PDFs rarely change between deploys. These should be cached aggressively and for a long time. The standard technique is content hashing: name the file after a hash of its contents, like main.a1b2c3.js, then set a long cache lifetime. When the file changes, the name changes, so the browser and CDN fetch the new version automatically. There is no cache-invalidation guessing.

2. HTML pages

Marketing pages, blog posts, and landing pages change occasionally but are read constantly. For most B2B sites these are the highest-leverage thing to cache at the edge. Two approaches dominate:

• Static generation: pre-build the HTML at deploy time and push it to the CDN. Nothing is computed per request. This is why we lean on static-first frameworks for marketing sites, as we explain in Why We Build B2B Sites on Astro.
• Edge caching of dynamic HTML: let the origin render a page once, then cache the result at the edge for a defined window so subsequent visitors are served instantly.

3. Personalized or authenticated content

Logged-in dashboards, account-specific pricing, and anything tied to a session must not be cached in a shared layer, or you risk serving one user’s data to another. Mark these explicitly as private and route them past the shared cache.

The discipline here is simple to state and easy to skip: every response should have an intentional caching policy. Decide it deliberately rather than inheriting whatever your framework’s defaults happen to be.

Cache Headers: The Controls You Actually Set

Caching behavior is driven by HTTP headers. You don’t need to memorize the spec, but a working leader should recognize the handful that matter.

• Cache-Control: the primary control. max-age sets how long a browser may reuse a response; s-maxage sets how long a shared cache like a CDN may. Use public for cacheable shared content and private for per-user content.
• Stale-while-revalidate: serve a slightly stale cached copy instantly while fetching a fresh one in the background. Visitors get speed; the cache stays current. This is one of the highest-value, lowest-risk settings for marketing content.
• ETag and Last-Modified: let a browser ask “has this changed?” and receive a tiny “no” instead of re-downloading the whole asset.

A practical pattern for a B2B marketing site:

1. Hashed static assets: cache for a year, both in the browser and the CDN.
2. HTML pages: short or zero browser cache, a meaningful shared cache window, plus stale-while-revalidate so the edge serves instantly and refreshes quietly.
3. API and personalized routes: private, no-store unless you have a specific, audited reason to cache.

When you ship new content, trigger a purge for the affected pages so the edge picks up changes immediately rather than waiting for the window to expire. Most CDNs support targeted purges by URL or tag, which is far safer than flushing the entire cache on every deploy.

When to Reach for the Edge, Not Just the CDN

A CDN caches responses. Edge computing runs your code at the PoP. The distinction matters once you need logic that varies by visitor but still must be fast everywhere.

Good candidates for edge logic on a B2B site:

• Geolocation and redirects: route a visitor to the right regional page or language without a slow origin round trip.
• A/B testing and personalization: decide which variant to serve at the edge so the test doesn’t introduce a client-side flash or a trip back to the origin.
• Lightweight authentication checks: validate a token at the edge and block or allow access before the request ever reaches your application.
• Header and security policy injection: apply consistent security headers and rules across every route from one place.

The caution: edge functions run in a constrained runtime and bill per invocation. Pushing heavy database calls or large dependencies to the edge can cost more and perform worse than a well-cached origin. Use the edge for fast, stateless decisions. Keep heavy lifting where it belongs, and cache its output.

Reach for the edge when the decision is small and the audience is global. Keep it at the origin when the work is heavy and the data lives there.

Measuring Whether Any of This Worked

Synthetic tests from a single fast location will lie to you. They’ll tell you the site is quick while a buyer in another region waits. Measure from where your audience actually is.

Two complementary sources:

• Field data (real-user measurement) captures the experience of actual visitors across regions and networks. This is the data search engines weigh, and it’s the truth that matters for revenue.
• Lab data lets you reproduce and debug specific problems under controlled conditions.

Watch metrics that reflect global delivery: time to first byte, which exposes origin and routing latency; largest contentful paint, which reflects how fast the main content lands; and your CDN’s cache hit ratio. A low hit ratio means the edge is doing little real work, and it’s usually the first thing to fix. For the full optimization loop, our Core Web Vitals optimization playbook walks through diagnosing and improving these metrics in order.

In our engagements, the biggest, fastest wins typically come from raising the cache hit ratio on HTML, not from micro-optimizing assets that were already cached well.

A Rollout Checklist for Global B2B Sites

If you’re putting this into practice, work in this order:

1. Audit current cache headers. Find every route that’s accidentally uncacheable. This alone often surfaces the largest opportunity.
2. Hash and long-cache static assets. Lowest risk, immediate improvement.
3. Cache HTML at the edge with stale-while-revalidate, and wire content publishes to targeted purges.
4. Confirm personalized routes are private. Audit this carefully; a cache leak here is a security incident, not a performance bug.
5. Move only the right logic to the edge. Geolocation, variant selection, and auth checks first.
6. Measure with field data by region and track cache hit ratio as an ongoing health metric, not a one-time check.

Each step is independently valuable, so you can ship incrementally and watch the field data respond rather than betting on one large change.

Make Your Site Fast Everywhere Your Buyers Are

Global performance isn’t a single setting; it’s a deliberate strategy about what gets cached, where it’s served, and which decisions happen at the edge. Done well, it makes your site feel local to every buyer, holds up under traffic spikes, and feeds the field data that supports your search visibility.

If you want a partner to audit your caching, design an edge strategy, and implement it without disrupting your marketing motion, that’s the kind of work we do every day. Explore our services or get in touch and we’ll take a look at how your site performs for the audiences that matter most.