Website Performance Across Regions: Hosting, CDN, Images, and Scripts

The short version #

Three seconds in Shanghai, ten seconds in Berlin, won't load at all in São Paulo. That's the most common "global site is slow" ticket we get. The cause is rarely bad code. It's usually the wrong hosting region, no CDN, unoptimized hero images, and a pile of third-party scripts. The diagnosis order is fixed. Run WebPageTest from three or four target regions first, isolate whether the bottleneck is TTFB, post-byte transfer, or render blocking, then fix that layer. Hosting and CDN are the skeleton; if those are wrong, nothing downstream saves you. Images and scripts come after, once the skeleton is right. WordPress and custom builds need different tactics. WordPress fixes go through plugins and cache. Custom builds go through build configuration and edge deployment. The checklist at the end is the version you can hand to your dev team or external contractor.

We inherited a site last year that ran on a Hangzhou IDC. Domestic colleagues thought it was fast. Then a German prospect emailed: "Your site won't open." We ran WebPageTest from Frankfurt and got TTFB 4.2 seconds, LCP 12 seconds. Moved the site to a Vultr node in Frankfurt with Cloudflare in front, TTFB dropped to 380 ms, LCP to 2.8 seconds. One day of work. Three months of marketing already wasted.

Cross-region performance is not mysterious. It's a stack of engineering problems you can diagnose layer by layer and fix in order.

1. Why it's slow #

When a domestic-China host serves an overseas user, three sources of latency stack up:

• Physical distance: Shanghai to Frankfurt is at least 150 ms one-way over fiber, and during peak hours cross-border congestion pushes RTT past 300 ms. Every TCP handshake and every resource request gets multiplied by that number.
• Cross-border jitter: International egress packet loss spikes during evening hours in China. Even if your host is in Singapore, if egress routes through Chinese carriers your overseas users still feel it.
• DNS resolution path: Chinese DNS providers have few overseas nodes, so first-time resolution can take 200–500 ms. If your domain is parked on a domestic DNS, overseas resolution sometimes just times out.

Which means "it loads fine for me in Beijing" is not evidence that your overseas site works. The minimum validation: run WebPageTest or PageSpeed Insights from three or four target markets (Frankfurt, New York, Singapore, São Paulo) and check TTFB, LCP, and CLS before drawing any conclusions.

2. Diagnosis order #

Don't start by compressing images. Diagnose bottom-up:

1. DNS: run dig +trace yourdomain.com @8.8.8.8 against an overseas resolver. Anything over 100 ms means your DNS host is wrong.
2. TTFB (time to first byte): open DevTools → Network → look at the Waiting (TTFB) column. Target overseas TTFB under 600 ms. If it's 4 seconds, no amount of front-end work will save you.
3. Above-the-fold transfer: how long after TTFB before CSS, fonts, and the hero image finish loading. Target overseas LCP under 2.5 s.
4. Render blocking: how much main-thread time JavaScript and third-party scripts (Analytics, live chat, heatmap) consume before paint.

Pin the layer first, then act. Cutting third-party scripts is the easiest optimization, but if your TTFB is already 4 seconds, trimming scripts only takes you from 12 s to 11 s, which is not the win you need.

3. Hosting #

Hosting region sets the ceiling on TTFB. The decision rule is simple:

• Buyers in Europe: Frankfurt (AWS, Vultr, and Hetzner all have nodes there), covering Germany, France, Benelux, and the Nordics. Add London if the UK is a major market.
• Buyers in North America: Virginia (East Coast) or Oregon (West Coast). Pick based on where most buyers sit.
• Southeast Asia: Singapore, covering SG, MY, ID, TH, VN.
• Latin America: São Paulo (AWS has a node there).
• Multiple markets at once: one primary region plus a global CDN. Don't deploy three backends in three regions until business volume actually justifies the operational cost.

Don't keep an overseas site on a Chinese IDC. This is the single most common pattern we've seen over the past three years. If domestic access also has to be fast, route mainland traffic through a separate ICP-filed CDN edge or a dedicated mainland mirror, rather than pulling the global site back into China.

For WordPress-specific host selection, see WordPress Overseas Website Architecture.

4. CDN #

A CDN caches static assets (HTML, CSS, JS, images) at edge nodes worldwide so requests get served from the nearest one. Running an overseas site without a CDN in 2026 is hard to justify.

• Cloudflare: the free tier covers most small-to-mid exporters. Turn on Auto Minify, Brotli, HTTP/3, and Early Hints. Pro adds Argo Smart Routing, which is genuinely effective for cross-border paths.
• Fastly: better raw performance, more configuration overhead. Worth it for in-house engineering teams.
• AWS CloudFront: easiest fit if your origin is already on AWS.

Two traps we see all the time. First, cache rules misconfigured so dynamic pages get cached and logged-in users see each other's sessions. Second, the origin server isn't locked behind the CDN, so attackers hit it directly and the CDN protection is theatrical. Fix with Cloudflare Origin Rules plus a firewall allowlist on the origin host.

5. DNS #

DNS is the layer everyone forgets. Common issues:

• Domain parked on a Chinese DNS provider, slow or timing out from overseas.
• DNSSEC disabled, which doesn't directly affect speed but hurts trust scoring.
• TTL set too low (60 s), so CDN nodes re-resolve constantly.

Recommended: move DNS to Cloudflare (free, global anycast) or your host's managed DNS. TTL at 3600 s or longer. Verify before launch with dnschecker.org across multiple regions.

6. Images #

Images usually account for 60–80% of above-the-fold transfer. The pattern is:

• Format: ship WebP or AVIF, 30–50% smaller than JPEG at the same quality. WordPress: ShortPixel or Smush. Custom build: sharp or imagemin in the build pipeline.
• Sizing: don't drop a 4000 px source into an 800 px container. Use srcset so each device gets the size it needs.
• Lazy loading: hero gets loading="eager" plus fetchpriority="high"; everything below the fold gets loading="lazy".
• Edge transform: Cloudflare Polish, Cloudinary, or Imgix can transcode and compress at the edge so you don't have to touch the origin.

The worst case we've seen: a case study page with eight 4 MB site photos, 35 MB above the fold. Converted to WebP and resized properly, total transfer dropped to 1.8 MB. LCP went from 11 s to 2.4 s.

7. Fonts and scripts #

Fonts and third-party scripts are the two big render-blocking sources:

• Fonts: self-host. Don't load Google Fonts remotely (completely unavailable in mainland China and 200 ms slower than self-hosting overseas). Preload the subset used above the fold with <link rel="preload" as="font"> and font-display: swap.
• Third-party scripts: every analytics, chat, and heatmap script adds 100–300 ms. Before launch, list every script and answer: which conversion does this directly serve? If the answer is fuzzy, cut it.
• Loading strategy: non-critical scripts get defer or async. Live-chat widgets can be lazy-initialized on click instead of on page load.
• GTM container: route all third-party tags through Google Tag Manager so you can flip them on and off without redeploying.

For the mobile-side rescue actions, see Mobile Website Speed Rescue Plan.

8. WordPress tactics #

WordPress speed problems cluster in three places: too many plugins, bloated themes, slow PHP rendering. Tactics:

• Plugin audit: install Query Monitor and look at per-plugin DB queries and load time. Delete anything you haven't used in three months.
• Cache: WP Rocket or LiteSpeed Cache, page cache plus object cache (Redis). This step alone usually halves TTFB.
• Theme choice: avoid kitchen-sink page-builder themes (Avada, Divi). They load dozens of JS and CSS files by default. GeneratePress, Astra, and Kadence are lighter.
• Database hygiene: clean revisions, transients, and spam comments on a schedule. WP-Optimize handles it.

9. Custom-build tactics #

For Next.js or Nuxt with a headless CMS, performance lives in build and deploy:

• Static first: prefer SSG to SSR wherever possible. SSR TTFB is always worse than SSG by a measurable margin.
• Image pipeline: next/image or nuxt/image wired to Cloudinary or Imgix for edge transcoding.
• Code splitting: route-level chunks, lazy components below the fold.
• Edge deploy: Vercel, Cloudflare Pages, and Netlify all run on global edge networks. Deploy the site to the edge directly and skip the separate CDN configuration.

10. Page priority #

You'll never have time to optimize everything. Order:

1. Homepage: 80% of overseas buyers land here from Google or AI search. LCP under 2.5 s is the floor, not a stretch goal.
2. Service / product pages: the decision pages. Every extra second of latency costs 7–10% conversion.
3. Contact page: forms have to be fast or buyers abandon mid-fill.
4. Blog / case studies: can be slightly slower, but the hero image still has to be compressed.
5. About / team page: lowest priority.

Monitoring #

If you don't monitor after launch, you're guessing. Set up three things:

• Search Console Core Web Vitals report: real-user LCP, INP, and CLS broken down by URL.
• GA4 with Web Vitals custom events: per-page LCP segmented by country and device.
• Monthly WebPageTest pass: fixed cadence, four target regions, compare against last month.

For the technical SEO baseline that pairs with this, see Technical SEO Baseline for a New or Rebuilt Website. The full overseas launch checklist sits at Overseas Website Launch Checklist for Chinese Companies.

References: Google Search Central — localized versions and hreflang, SEO Starter Guide.

Pre-launch table #

FAQ #

Can I keep my Chinese host and just add a CDN? #

Short term, it helps. Long term, no. The CDN caches static assets, but dynamic requests like form submits, search, and login still hit the origin in China and pay the 300 ms+ cross-border penalty. The right fix is moving the origin to a node near your target market.

Is the Cloudflare free tier enough? #

For 90% of small-to-mid B2B exporters, yes. Auto Minify, Brotli, HTTP/3, and Early Hints get you most of the gain. Move to Pro for Argo and image optimization once traffic justifies it.

Should each language live on its own deployment? #

Almost never. One .com with /en/, /de/ paths and a global CDN is the cheapest correct architecture. Configuration details in Multilingual Site Structure and Hreflang.

Can I keep using Google Fonts? #

Not recommended. Google Fonts is fully blocked in mainland China and 100–300 ms slower than self-hosting elsewhere. Download the font files, serve them from your own CDN, set font-display: swap. More predictable.

Get a diagnosis #

If your overseas site is live but buyers say it's slow, or you're about to launch and aren't sure how to size hosting and CDN, bring your domain, target markets, and current architecture. We'll run this exact diagnosis order from four target regions in a free initial review under our overseas website build and SEO/GEO support service, and tell you which layer is the real bottleneck, which fixes are P0, and what can wait until next quarter.