Fix Slow Website Loading From Specific Countries

You're sitting in Chicago, and your site loads in under a second. But a friend in São Paulo reports 8-second loads. Someone from Tokyo gives up after a minute. This isn't random—it's a classic sign that your content delivery network (CDN) isn't serving those regions, or your DNS isn't routing them to the nearest server. I've seen this exact pattern with clients running Node.js apps on a single AWS EC2 instance, or WordPress sites hosted in a Frankfurt data center.

Why This Happens

The root cause is almost always one of three things:

CDN misconfiguration — Your CDN (CloudFront, Fastly, Cloudflare, etc.) might not have edge nodes in South America or Southeast Asia. Or you've set up a custom origin that bypasses the CDN for certain file types.
DNS geolocation failures — Your DNS provider (Route53, Cloudflare DNS, etc.) might not be returning the nearest edge IP to users far away. Some DNS providers return a single IP regardless of the user's location.
Single-region hosting — If your origin server sits in one data center (like us-east-1), users on the other side of the planet suffer from high latency and packet loss. A CDN should mask this, but if static assets aren't cached, every request hits that distant server.

There's also a subtle one: TCP slow start and packet loss on long-haul routes. If your web server's TCP stack isn't tuned (e.g., default Linux TCP window), connections from far away take more round trips to ramp up.

Step-by-Step Fix

Step 1: Verify the CDN Is Actually Serving Those Regions

Use curl from different geographic endpoints. If you don't have servers there, use a tool like Geopeeker or Check-host.net. Run this from multiple locations:

curl -I -w "%{http_code} %{remote_ip}\n" https://yoursite.com

If the returned IP is your origin server (not a CDN edge IP), your CDN is misconfigured. Check your DNS: your domain's A or CNAME record should point to the CDN's CNAME, not directly to your server.

Step 2: Check DNS Response Latency

Run a dig from multiple resolvers. For example:

dig @8.8.8.8 yoursite.com +short
 dig @1.1.1.1 yoursite.com +short

If the returned IPs differ based on the resolver, your DNS uses geo-routing—good. If they're all the same, you likely have a problem. Switch to a DNS provider that supports latency-based routing or geolocation routing (AWS Route53 does this well).

Step 3: Review CDN Edge List

Not all CDNs cover every country equally. For example, CloudFront has limited edge presence in South America (only a few in Brazil and Colombia). If your traffic is heavy from Argentina, you might need to enable additional regions in your CDN settings or switch to a provider with better coverage there (like Fastly or Akamai).

Step 4: Tune TCP for High-Latency Routes

On your origin server (Linux), increase the TCP receive window and enable BBR congestion control:

sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'
sudo sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'

This helps connections from far away ramp up faster. You'll also want to enable HTTP/2 (multiplexing reduces round trips) and enable TLS 1.3 (reduces handshake to one round trip).

Step 5: Static Asset Caching Headers

Make sure your server sends proper cache headers. Many slow-loading issues happen because the CDN doesn't cache CSS/JS. Add these to your web server config (example for Nginx):

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

Then purge the CDN cache and test again from a slow region.

Step 6: Use a Global Load Balancer

If the problem persists for dynamic content (API calls, login pages), consider deploying your app in multiple regions and using a global load balancer (AWS Global Accelerator or Cloudflare's Argo Smart Routing). Global Accelerator uses Anycast to route users to the nearest healthy endpoint, reducing latency by 30-60% for faraway users.

What to Check If It Still Fails

Check for ISP peering issues. Use mtr or traceroute from a user's location to your server. If you see high packet loss at a specific hop, it's an ISP problem—not yours. You can't fix that, but you can move to a different cloud provider that peers better in that region.
Check if the country is blocked by your firewall. Some WAFs (like ModSecurity or Cloudflare) block traffic from certain countries by default. Verify your security rules.
Check DNS propagation. If you recently changed DNS, some users might still hit old, slow servers. Wait 24-48 hours or flush your CDN's DNS cache.
Check for large uncompressible assets. If you're serving raw 5MB images without compression, no CDN will save you. Compress them.

I've seen teams spend weeks chasing this and it turns out they forgot to enable the CDN's South America edge region. So start there. Fix the CDN first, then the DNS, then the TCP stack. You'll get that Tokyo user back under a second.