Créer des sites multi-régions qui fonctionnent vraiment
Your server is in Virginia. Your fastest-growing market is in Singapore. The physics of network routing means every request from Singapore travels 15,000 km to Virginia and 15,000 km back — adding 250-400ms of pure latency before your server even starts processing the request. At the margins, that latency gap costs you rankings, conversions, and patience.
Multi-region architecture solves this by serving content from locations physically close to your visitors. It's not the same as adding language translations or setting hreflang tags. Those are content concerns. Multi-region is an infrastructure concern — and it's the difference between a 50ms response in Paris and a 400ms response from the same server when accessed from Tokyo.
Why Multi-Region Is Different from Multi-Language
Multi-language means your website has content in French, German, Japanese. The infrastructure can be a single server in one location — every visitor hits the same machine, just seeing different text. You add hreflang tags for SEO, build a locale switcher, and you're done.
Multi-region means your website's infrastructure is distributed across geographic locations. The French visitor hits a server in Paris. The Japanese visitor hits a server in Tokyo. The content might be identical (in English) or localized — that's a separate concern.
You can have multi-language without multi-region (single server, translated content). You can have multi-region without multi-language (distributed servers, English only). Most international businesses need both, but they're different problems requiring different solutions.
| Concern | Multi-Language | Multi-Region |
|---|---|---|
| What changes | Content (text, images, currency) | Infrastructure (servers, CDN, databases) |
| Who benefits | Visitors who speak different languages | All visitors (faster load times) |
| Primary tool | i18n framework, translation files | CDN, edge computing, distributed databases |
| SEO impact | hreflang tags, locale-specific URLs | Core Web Vitals, TTFB improvement |
| Complexity | Content management | Infrastructure and data consistency |
The question isn't "should we go multi-region?" The question is "where are our visitors, and is the latency from our current server acceptable?" If 90% of your traffic is within 2,000 km of your server, a CDN handles the rest. If you have significant traffic across three or more continents, you need a multi-region strategy.
CDN-First Architecture
The simplest and most cost-effective multi-region approach is to let a CDN handle geographic distribution while keeping your origin server in one location.
A Content Delivery Network caches your pages at edge nodes around the world. When a visitor in Tokyo requests your page, the Tokyo edge node serves the cached copy — the request never reaches your origin server in Virginia. TTFB drops from 400ms to 30-50ms.
For static and ISR pages, CDN-first is trivially simple: build your pages, deploy to a CDN, and the edge handles everything. Vercel, Netlify, and Cloudflare Pages do this by default.
For dynamic pages (SSR), the architecture requires more thought:
Edge functions run your server-side code at CDN edge nodes rather than a single origin. Vercel Edge Functions, Cloudflare Workers, and Netlify Edge Functions execute JavaScript at 200+ locations worldwide. The code runs in the visitor's region, eliminating the round trip to your origin. The constraint: edge functions have limited runtime (typically V8 isolates, no Node.js APIs) and can't maintain persistent connections to databases.
Stale-while-revalidate caching at the edge keeps a cached copy of SSR pages and serves them instantly while refreshing the cache in the background. Configuration example for Cloudflare:
Cache-Control: public, s-maxage=60, stale-while-revalidate=300
This tells the CDN: serve the cached version for up to 60 seconds. After 60 seconds, still serve the stale version while fetching a fresh one. Only after 300 seconds of staleness should the visitor wait for a fresh response.
Cache invalidation is the hard part. When content changes, stale cached copies exist at dozens of edge nodes. Options: short TTL (60-300 seconds) that accepts some staleness, instant purge via CDN API (Cloudflare and Fastly support instant global purge), or tag-based invalidation (purge all pages tagged "product-123" when that product updates).
The CDN-first architecture covers 80% of multi-region needs at near-zero additional cost. Cloudflare's free tier includes CDN with edge caching. Vercel's free tier deploys to their global edge network. You only need more infrastructure if you have data-heavy operations that can't be cached.
Data Residency and Compliance
The legal landscape for data storage has become more complex since GDPR, and it directly affects multi-region architecture decisions.
GDPR (EU). Personal data of EU residents must be processed with a legal basis, and transfers outside the EU require specific safeguards (Standard Contractual Clauses or adequacy decisions). Practically, this means: if you collect form submissions, user data, or analytics from EU visitors, that data should be stored on servers within the EU or in an approved jurisdiction. US-only hosting is technically compliant with proper SCCs, but many EU clients and enterprise buyers require EU data residency as a procurement condition.
CCPA/CPRA (California). Less restrictive on data location but requires disclosure of data collection and selling practices. If you serve California residents, you need a privacy policy that complies with CCPA regardless of where your servers are.
Data sovereignty laws in Brazil (LGPD), China (PIPL), Russia (data localization law), and India (DPDP Act) each have their own requirements. China and Russia explicitly require local data storage for their citizens' data.
For most B2B websites, the practical approach is:
- Host your website on a global CDN (no data residency issue — HTML, CSS, and JS aren't personal data).
- Store form submissions and user data in the region of your primary market. EU server for EU customers. US server for US customers.
- Use privacy-respecting analytics (Plausible, Fathom, or self-hosted Matomo) that don't transfer personal data across borders.
- Document your data processing activities with a compliant privacy policy and data processing agreements.
If you serve multiple regions with strict residency requirements, you'll need per-region database instances — which is where multi-region gets genuinely complex.
Latency Optimization Strategies
Beyond CDN caching, several techniques reduce latency for global audiences:
DNS-level routing (GeoDNS). Your DNS provider returns different IP addresses based on the visitor's location. EU visitors get directed to your EU server. US visitors get directed to your US server. AWS Route 53, Cloudflare DNS, and NS1 all support geographic routing. This works for both origin servers and CDN edge nodes.
Anycast networking. A single IP address is advertised from multiple locations worldwide. The internet's BGP routing automatically sends each visitor to the nearest location. This is how Cloudflare's CDN works — their IP addresses are anycast, so your DNS doesn't need geo-routing because the network layer handles it. All major CDN providers use anycast.
Edge databases. Traditional databases live in one region. Distributed databases like PlanetScale (MySQL-compatible), CockroachDB (PostgreSQL-compatible), and Turso (SQLite at the edge) replicate data across regions with configurable read/write regions. Read replicas in each region serve local reads in under 10ms. Writes go to the primary region and replicate outward.
The latency budget for sub-200ms TTFB globally:
| Component | Target Latency | How to Achieve |
|---|---|---|
| DNS resolution | < 20ms | Anycast DNS provider (Cloudflare) |
| TCP + TLS handshake | < 50ms | Edge server in visitor's region |
| Server processing | < 50ms | Cached response or edge function |
| Data fetching | < 80ms | Edge database or CDN-cached data |
| Total TTFB | < 200ms | CDN + edge compute + edge data |
The most common mistake: optimizing server processing time while ignoring network latency. A server that generates HTML in 5ms but is 300ms away from the visitor still has a 305ms TTFB. Geographic proximity to the visitor matters more than server speed.
Prefetching for perceived performance. Even with global infrastructure, some requests will be slower than ideal. Prefetch the next likely page while the visitor reads the current one:
<link rel="prefetch" href="/services" />
Modern frameworks like Next.js prefetch linked pages automatically on viewport entry. By the time the visitor clicks a link, the next page is already cached in the browser.
FAQ
How much does multi-region hosting cost compared to single-region? CDN-first with a single origin: $0-20/month additional (Cloudflare free CDN + existing hosting). Full multi-region with distributed databases: $200-1,000/month depending on regions and traffic. The CDN-first approach handles 90% of latency concerns at minimal cost. Only invest in full multi-region if you have data-heavy operations requiring sub-100ms database access from multiple continents.
How do I handle failover between regions? CDN providers handle failover automatically for cached content — if one edge node fails, traffic routes to the next nearest. For origin failover, you need health checks and automatic DNS failover. Cloudflare Load Balancing ($5/month) monitors origin health and routes traffic away from failed servers. AWS Route 53 offers similar functionality. Test your failover by deliberately taking down a server during a maintenance window.
What about database replication lag? When you write to a primary database in US-East and read from a replica in EU-West, there's a delay between the write completing and the replica receiving the update. For PlanetScale, this is typically 50-200ms. For CockroachDB, it's 100-300ms. This means a user in Europe who submits a form might not see their submission immediately if the read goes to the local replica before the write has replicated. Solutions: route reads-after-writes to the primary region, or accept the staleness for non-critical data.
How do I test multi-region performance locally?
Use Chrome DevTools network throttling to simulate different connection speeds. Use WebPageTest with test locations in different regions to measure real TTFB from each continent. Cloudflare's diagnostic tools (curl -svo /dev/null https://yoursite.com 2>&1 | grep cf-ray) show which edge node served the response. For DNS testing, use dig from different locations via services like DNS Checker.
Is multi-region necessary for a B2B site with a primarily domestic audience? No. If 80%+ of your traffic is in one country and your server is in that country, a CDN for static assets is sufficient. Multi-region infrastructure is justified when you have significant international traffic (20%+ from other continents) or when your target markets have strict data residency requirements. Don't over-engineer infrastructure for traffic you don't have yet.