International Ecommerce Site Speed: The CDN Edge Strategy That Actually Works

The largest source of variance in international ecommerce performance isn't your code or your image sizes — it's the physical distance between your customer and your origin server. A US-hosted Shopify store loading for a customer in Singapore pays 180–240ms of round-trip network latency on every cacheable miss, and that latency stacks on top of whatever rendering work the page actually does. By the time the customer in Singapore sees first contentful paint, the same store has already finished rendering for a customer in New Jersey.

CDNs solve part of this — but the part they solve and the part they don't is where most ecommerce stores get it wrong. Below is the 7-point CDN edge audit for international ecommerce: what to cache, what to render at the edge, what to leave at origin, and how to measure whether your current setup is helping or hurting.

1. Confirm Your CDN Has Edge Locations in Your Top 5 Markets

The first audit is geographic. Pull your top 5 markets by sessions from analytics, then verify your CDN has PoPs (Points of Presence) within 100ms of each. The major CDNs publish their PoP maps:

• Cloudflare — 330+ cities globally
• Fastly — 90+ edge locations
• CloudFront — 600+ edge locations
• Bunny.net — 100+ PoPs, strong APAC coverage

If a market has no nearby PoP — common for stores using regional CDNs without APAC or LATAM coverage — that market is loading from your origin region. A Shopify store on the default Shopify CDN (which is strong in North America and Europe but limited in LATAM and parts of APAC) may see 300ms+ TTFB for customers in São Paulo, Mexico City, or Manila.

2. Measure TTFB by Region, Not Globally

Aggregate TTFB metrics hide regional problems. A store with 200ms global average TTFB might look fine, but the actual distribution could be 80ms for North America and 450ms for everywhere else. Use real-user monitoring (RUM) tools to segment Core Web Vitals by country:

• Google Chrome User Experience Report (CrUX) — free, segmented by country
• PageSpeed Insights — shows CrUX data per origin
• SpeedCurve, Calibre, Treo — paid RUM with country-level segmentation

The CrUX dashboard at cruxvis.withgoogle.com lets you compare your origin's performance against country baselines. If your TTFB at the 75th percentile in Germany is 600ms but the country baseline is 280ms, your CDN configuration is the variable to investigate.

3. Cache Static Assets at the Edge — Aggressively

The fastest request is the one that never reaches your origin. Static assets — images, CSS, JavaScript bundles, fonts — should be cached at the edge for 1 year minimum, with cache-busting via versioned filenames (e.g., main.a8f3c2.css). The cache headers that matter:

Cache-Control: public, max-age=31536000, immutable
CDN-Cache-Control: public, max-age=31536000

The immutable directive tells browsers and CDNs that the file will never change at this URL — eliminating revalidation requests. Run the Cache Headers Checker on your CSS and JS bundles to confirm they're set correctly. Stores using Shopify, BigCommerce, or modern Next.js setups generally get this right by default; custom builds and older platforms often don't.

4. Cache HTML Selectively at the Edge

HTML caching is where ecommerce stores diverge from media sites. A blog post can cache HTML at the edge for hours — but a product page with personalized pricing, inventory levels, or cart state is a different problem. The pattern that works for ecommerce:

• Cache the HTML shell at the edge — product page layout, hero images, descriptions, schema markup
• Hydrate dynamic data client-side — inventory count, cart contents, "for you" recommendations
• Use ESI or fragment caching — Fastly's Edge Side Includes let you cache different page sections with different TTLs

Shopify's Hydrogen and Next.js with App Router both default to this pattern. WooCommerce and Magento require explicit configuration — and getting it wrong means either stale pricing in caches or no edge caching at all.

5. Route Origin Requests Through the Nearest Edge

For requests that bypass cache and hit origin — API calls, cart updates, checkout — modern CDNs route those requests over their backbone network rather than the public internet. This is called "Argo Smart Routing" at Cloudflare, "Origin Shield" at CloudFront, or "Tier-1 Network" at Fastly.

The latency improvement is typically 30–40% for long-haul connections. A customer in Sydney making a cart-add request that goes through Cloudflare's network to a US origin sees ~180ms RTT; the same request over the public internet may see 250ms+ with higher variance. For checkout flows where every additional 100ms of latency reduces conversion by 1–3% (Akamai's research), this matters.

6. Render Personalization at the Edge When Possible

The newer pattern in international ecommerce: run small amounts of personalization logic at the edge instead of round-tripping to origin. Cloudflare Workers, Fastly Compute@Edge, and Vercel Edge Functions let you make request-level decisions without an origin hit:

• Currency and language detection — determine locale at the edge, serve the correct version of the page
• A/B test bucketing — assign users to test variants at the edge, cache each variant separately
• Bot mitigation — block scrapers and low-value bot traffic at the edge before they hit origin

Shopify's Oxygen and Vercel's Edge Network are built for this pattern. The trade-off: edge compute is more expensive per millisecond than origin compute, so it makes sense for high-value decisions (routing, personalization) but not for general application logic.

7. Audit Third-Party Scripts for Geographic Latency

The last optimization is often the biggest: third-party scripts. A typical ecommerce store loads 20–40 third-party scripts (analytics, marketing pixels, chat widgets, reviews, A/B test platforms). Each of those scripts has its own CDN — and many of them have poor coverage in APAC, LATAM, or Africa.

The audit:

• Run a WebPageTest from the slowest market you serve
• Identify third-party scripts with TTFB > 500ms from that location
• Evaluate whether the script is critical for the experience or can be deferred
• Consider self-hosting critical third-party scripts behind your own CDN (e.g., proxy Google Tag Manager through Stape)

The Third-Party Scripts Checker identifies which scripts are loading and their network impact. The Tracking Pixels Checker specifically audits marketing pixels for redundancy and load order.

The Compounding Effect

Each of these optimizations is incremental in isolation: a 100ms TTFB improvement here, a 200ms script defer there. But the compounding effect across markets is substantial. A store that goes from 750ms TTFB in APAC to 280ms TTFB in APAC typically sees:

• Conversion rate improvement of 5–12% in that market (Akamai/Deloitte data)
• Bounce rate reduction of 10–20% on mobile
• Google search ranking improvements due to Core Web Vitals threshold crossing
• Better quality score on paid search, lowering CPC

The 7-point audit is a one-day investment for stores doing meaningful international revenue (>15% of sessions from outside the origin region). The Web Vitals Checker measures the baseline; the TTFB Checker isolates the network component. Run both from different geographic locations to see whether your CDN edge strategy is working or whether you're paying the global ecommerce latency tax.