From your office in Pune or Kolkata the site feels quick. Then a buyer in London says the product pages take forever, or a partner in Texas sends a screenshot of a half-loaded home page. Or it is the other way round: you run a business in Manchester on hosting you bought years ago, and your new customers in Bengaluru say the site is sluggish while it feels fine to you.
If you find your website slow in other countries, the people telling you so are not imagining it, and the site is not necessarily at fault either. The page is the same everywhere. What changes is how far every request has to travel and how many times it has to make the trip. Distance hurts more than most people expect, but it can be measured, and a good part of it can be worked around.
Why distance costs more than one delay
Data across the internet is quick, but it is not instant, and a long route between continents adds a noticeable delay to each round trip. The catch is that a page load is not one round trip. It is many.
Before the browser receives the first byte of your page, it has to look up the domain, open a connection and set up encryption, and each of those steps involves messages going back and forth. Then the page refers to styles, scripts, fonts and images, and the browser requests those too. Some can be fetched in parallel, but plenty depend on each other: the browser cannot ask for a font until it has read the stylesheet that mentions it.
So a delay that seems small on its own gets multiplied by every round trip in the chain. A visitor near your server barely notices. A visitor on the other side of the world feels every one of those trips added together, before the server has done any work at all.
What has to come from your server, and what does not
This is the most useful distinction for overseas speed.
- Static files such as images, stylesheets, scripts and fonts are the same for everyone. They can be copied to servers around the world and handed out from the nearest one.
- The page itself (the HTML) is usually built by your server for each request, unless it is cached. If it is built at your origin server, an overseas visitor waits for the long trip there and back before anything else can start.
- Personal and live requests such as the cart, checkout, account pages, search and form submissions always need your server.
That is why “add a CDN” is the standard advice and also why it sometimes disappoints. A CDN that only serves static files helps with the second half of the load, but the first request, the one everything else waits on, still crosses the ocean. If you need the basics of how a CDN works, our post on what a CDN is and what it can fix covers that; here we are concerned with what it means for buyers abroad.
Is your website slow in other countries? Test from there
You cannot judge this from your own desk. You need tests that run from where your customers are.
- Choose the test location deliberately. Several speed tools let you choose where the test runs from. WebPageTest has a wide choice of locations, browsers and connection types; the walkthrough in using WebPageTest step by step shows how to set them.
- Test the same page from two places. One near your server, one near your overseas customers. Same device setting, same connection profile, three runs each.
- Compare the server wait first. Look at the time to first byte for each location. If it is much longer from abroad, the distance to the origin is a large part of the problem.
- Then compare the rest of the load. If static files are also slow from abroad, they are not being served from anywhere near the visitor.
- Look at other domains. Fonts, maps, chat and analytics come from their own servers. Most big providers have servers worldwide, but some smaller services do not.
If you have customers or friends in the other country, ask them to load a few pages on a phone and tell you roughly how long each takes. It is unscientific, but it reflects real networks in a way that a test server does not.
An India-hosted site with buyers in the US, UK or Europe
This is common for Indian exporters, consultants, tour operators and service firms. The hosting was bought locally, which makes sense for an Indian audience, and then the customers turned out to be abroad.
The order of work we would follow:
- Make sure pages are cached at the origin, so the server answers instantly when the request arrives. Distance plus slow page building is the worst combination.
- Serve static files from a CDN with locations near your buyers. This often makes the biggest visible difference to images and layout.
- Consider caching the HTML at the edge for public pages that are the same for everyone. Cloudflare and similar services can do this, but it needs care so that personal pages are never cached. The post on setting up Cloudflare caching for WordPress covers the cautions.
- Cut the round trips. Fewer redirects, fewer separate domains, and fewer files that depend on each other in a chain.
- Reconsider where the server is if most of your paying customers are now abroad. That is a hosting decision rather than a speed setting, and it affects Indian visitors in the other direction.
A US- or Europe-hosted site with customers in India
The reverse case is just as common. Many hosting companies run their main data centres in the US or Europe, and a business in India may have signed up without noticing where the server was. Indian visitors, often on mobile data, then pay the distance cost on every page.
The same steps apply in reverse. Many hosts let you choose or move to a data centre in or near India; ask whether yours does and what moving involves. Make sure the CDN you use has locations in India. And test from an Indian location, on a mobile connection profile, because that is what your customers are actually using.
Customers in both places
Plenty of small businesses sell to India and abroad at once. There is no server location that is close to everyone, so the usual approach is:
- Put the server nearest to the customers who matter most, often the ones who buy or enquire, which may not be the ones who visit most.
- Cache as much as you safely can, and serve static files from a CDN with good coverage in both regions.
- Keep pages light, because every extra file costs more for the distant group.
- Accept that personal pages like checkout will always be a little slower for the distant group, and make sure those pages carry as little as possible.
When the slowness is not distance
Sometimes a site really is slow for overseas visitors, but the cause is something else. A cookie banner or consent tool that only appears for European visitors and loads heavy scripts. A currency or geolocation plugin that calls an outside service on every page. A payment or shipping widget that is slow from one region. If tests from abroad show a reasonable server wait but a long tail of other requests, look at what loads only for those visitors. The general triage in working out why a website is slow helps here, and the rest of the topics are linked from our full guide to website speed.
Mistakes to avoid
- Testing only from your own city and assuming everyone gets the same experience.
- Adding a CDN for static files and expecting it to fix a slow page build at the origin.
- Caching full pages at the edge without excluding cart, checkout and account pages.
- Moving the server to suit overseas visitors without checking what it does to local ones.
- Forgetting that third-party services have their own server locations.
Frequently asked questions
Should I move my hosting to the country where most of my customers are?
If most of the people who buy or enquire are in one region, hosting near them usually helps their experience. Before moving, check whether caching and a CDN already close most of the gap, because a move takes effort and can slow down visitors in the region you are leaving.
Would a .com domain load faster abroad than a country domain such as .in?
No. The domain ending does not change how fast pages load. What matters is where the server and the DNS provider answer from, and how the page is built. Google does treat country domains as a sign of which country a site targets, but that is a search question, not a speed one.
How can I see what speed visitors in another country are getting?
Use a speed test that lets you choose the test location, and run it from a city near your customers as well as one near your server. Compare the server wait and the full load. Asking a real person in that country to load a few pages on a phone is a useful extra check.
Do I need separate websites for India and for overseas customers?
Not for speed. One site with good caching and a CDN can serve both regions reasonably well. Businesses sometimes run separate sites for reasons such as currency, language, legal terms or different products, but that adds maintenance and is a business decision rather than a performance fix.
Where the gap is mostly distance, the answer tends to be configuration rather than a rebuild: caching, a CDN, fewer round trips. Our website speed optimisation service starts with an audit and a review of server response time, then works through the fixes once you have approved them.
Next in this series: Website Suddenly Slow? A What-Changed Checklist
