"Our website is fast — it opens instantly here."
That sentence is usually followed by the other fact: for an overseas buyer it takes five or six seconds. Not an illusion. Two problems stacked: physical distance and configuration.
Check these five, in order.
1. Where is your server, and where is your buyer
Start with the arithmetic. A data packet travels from the buyer to your server and back, and each round trip carries a cost. Cross-border round trips typically start around a hundred milliseconds, and a page loads dozens of resources. Multiply, and a second or two disappears before anything useful appears.
How to check: run PageSpeed Insights on your homepage and compare the server response time against how it feels to you locally.
The practical conclusion: if your buyers are in Europe and North America and your server is in China, that distance is not going away. You need a layer between the visitor and the origin — which is what a CDN is for.
2. Is the CDN cache actually working
Plenty of sites have a CDN turned on and no speed improvement, because nothing is being served from cache — every request still goes back to origin.
A measurement you can do yourself:
On the same site, compare how long it takes to load two kinds of resources — something that must reach the origin (an HTML page) against something already cached at the edge (an image, a stylesheet). The difference approximates the cost of one origin fetch.
On my own site that gap measured around 800 milliseconds. That is what each cache miss costs.
So: cache what can be cached. Pages, images and stylesheets are identical for every visitor and should be served from the edge. The only thing that genuinely cannot be cached is a personalised endpoint like a form submission.
One trap: some free CDN tiers impose a minimum cache duration, and some do not cache HTML by default. After turning the CDN on, go back and verify: what is the hit rate, and did time to first byte actually drop.
3. Images and fonts
The largest share of page weight is usually not code. It is images.
Three concrete moves:
- Convert and compress. Bitmaps to WebP, and a 2 MB product photo down to 200 KB is routine. Visually, almost nobody notices.
- Declare dimensions and lazy-load. Set width and height on images, add
loading="lazy"to everything below the fold, and stop the browser from fetching images nobody can see yet. - Do not pull fonts across the ocean. If your pages use a remote font service, every first visit waits on a long-haul request. Self-hosting the font files is more predictable.
4. Third-party scripts
Analytics, live chat, maps, video players — each one adds a cross-domain request to your first load.
How to check: PageSpeed Insights lists the time attributed to third-party scripts. When one shows up costing several hundred milliseconds, ask whether that tool is still in use.
Common cleanups: a chat widget installed three years ago, an analytics account you stopped reading, an autoplaying homepage video.
5. Time to first byte
This one is the dividing line. It tells you which direction to optimise.
Time to first byte measures the gap between sending a request and receiving the first byte, excluding images and scripts.
- A second or two just for first byte → the problem is server-side or the network path (origin location, a slow query, no caching). Compressing images will not help.
- First byte fast, full page slow → the problem is page weight. Go back to items 3 and 4.
Skipping this number is how teams spend two weeks compressing images and then discover the bottleneck was never there.
After optimising, measure the same way
Do not trust your impression. Re-run the same tool and compare the same metric.
One warning: a domestic speed test tells you nothing about an overseas buyer. Measure from overseas — PageSpeed Insights does this by default.
The order, in short
- Do the distance arithmetic and decide whether you need a CDN
- Verify cache hits after adding it, and measure one origin fetch
- Compress images, self-host fonts
- Remove third-party scripts you no longer use
- Use time to first byte to decide where to keep working
The first two usually explain half the problem, and they are the fastest to fix — configuration, not code.
To have this diagnosised properly, see Google SEO. If you would rather I measure your site once and tell you which of the five is responsible, ask for a free acquisition audit — the report stands on its own.
Two related reads: the full order of operations once speed is settled, in the first 90 days of SEO; and why multilingual sites feel performance problems more sharply, in translating your site is not multilingual SEO.
FAQ
Why is it fast locally and slow overseas?
Distance. Data travels between the visitor and your server, and a cross-border round trip usually starts at a hundred milliseconds. A page pulls dozens of resources, so the totals add up. It also explains why the same server feels instant to your colleague and slow to a buyer abroad.
How do I tell whether the server or the network is the problem?
Look at time to first byte — the gap between sending a request and receiving the first byte of the response, excluding images and scripts. If that alone takes a second or two, the problem is server-side or in the path, and image compression will not help. If first byte is fast and the full page is slow, the problem is page weight.
Does a CDN guarantee speed?
No. If the CDN edge cannot serve from cache and has to fetch from your origin on every request, you have added a round trip. Whether that is net faster depends on where your origin sits. Turn a CDN on, then verify the cache rules are actually taking effect.