Website Speed Test in Asia: Compare Real Loading Performance from Tokyo, Singapore and Beijing

The most reliable way to see how your website loads for visitors in Asia is to load it in a real browser located in Asia, and to do it from more than one place. Asia does not behave like a single network. Latixo runs live Chromium Browser Nodes in Tokyo, Singapore and Beijing. If you test the same URL from all three with the same profile, you can see whether a site is fast across the region or only fast in one part of it.

A test from the United States or Europe tells you very little here. A page served from an origin in Virginia can look excellent from Virginia. A visitor in Southeast Asia may still wait through several long intercontinental round trips before anything appears. The only way to see that cost directly is to measure from the other end of the path.

Asia needs more than one test location

People often treat “Asia” as one market and pick one test location to represent it. The network conditions don’t support that shortcut.

Tokyo and Singapore are several thousand kilometres apart, and the traffic between them usually crosses submarine cable. A CDN edge that serves Japan well can sit far from users in Indonesia or Vietnam. Mainland China is different again. International traffic in and out of the mainland passes through a comparatively small number of gateways, with its own peering arrangements, congestion patterns and on-path filtering. A site that loads cleanly from Singapore can stall from Beijing for reasons that have nothing to do with the server.

So a test from one Asian node is a sample of one sub-region. If the general mechanics are new to you (distance, routing, peering, edge caching and why they change TTFB), Why Website Speed Varies by Location covers them in depth. This page focuses on using Latixo’s Asian nodes to compare real results.

The Asian locations Latixo tests from

All three nodes run the same Chromium test profiles. What differs is where they sit on the network and which audience they help you understand.

Latixo also has a live Sydney node. Australia is not part of Asia, but if your audience is “Asia-Pacific” in the commercial sense, Sydney is a useful fourth point. It often exposes a different set of routing and edge decisions than the Asian locations.

It also helps to be clear about what is not covered. Latixo has no Browser Node in South Korea, Hong Kong, Taiwan, India or the Middle East. A Tokyo or Singapore result should not be stretched to describe those markets.

What a test from an Asian node measures

Each test opens your public URL in Chromium on the selected node. The page loads over that node’s real network path. Latixo does not run the test locally and add an artificial geographic delay afterward. The result reports the Latixo performance grade, transferred page weight, total load time, request count, Time to First Byte, the main document’s HTTP status, the negotiated HTTP protocol, the content type and the node that ran the job. You also get a final screenshot, a Loading Replay when capture succeeds, and recommendation checks based on the run.

Two boundaries matter when you compare locations. The standard result does not report FCP, LCP or CLS as separate values, and it does not break DNS lookup and TLS negotiation out as their own timings. Those phases still happen, and they still feed into TTFB, but you will not see them as separate rows. Website Speed Test Metrics explains what each reported value includes.

It is equally important to separate what the report shows from what you conclude from it. A statement such as “the report showed a higher TTFB from Singapore than from Tokyo” describes a measurement when backed by your actual runs. “The CDN isn’t caching in Singapore” is an inference. It may be correct, but it needs supporting evidence such as response headers, repeated runs, or a test after you change the cache configuration.

Running a fair comparison across Asia

Differences between locations only mean something if everything else stays the same. This sequence keeps the comparison controlled:

1. Pick one profile and keep it. Desktop runs at 1366 × 768 with the node’s native CPU and network. Each node’s own connectivity is part of a Desktop result, and that connectivity is not identical across locations. Mobile uses a fixed 390 × 844 viewport at DPR 3, a 4× CPU slowdown and limits of 1.6 Mbps down, 750 Kbps up and 150 ms latency. Those limits are applied on top of each node’s real path, so Mobile narrows bandwidth differences between nodes, but distance and routing still show through. Compare Desktop with Desktop and Mobile with Mobile.
2. Test exactly the same URL. Use the same scheme, the same host (with or without www) and the same path. If one location is redirected somewhere else, for example to a country-specific domain or a consent page, you are no longer comparing like with like. Check the HTTP status and screenshot before reading the timings.
3. Run each location more than once. A first request can land on a cold edge cache and a second request can be served from that same edge, so the two runs answer different questions. Cross-border paths can also vary noticeably between runs. A difference smaller than the normal spread of repeated tests is not strong evidence.
4. Add a reference location near your origin. If your server is in the United States, run the same test from Virginia or Seattle. If it is in Europe, use Nuremberg. The nearby result provides a reference point for the added Asian path, but it does not separate server work from connection and network time by itself.
5. Watch the Loading Replay before trusting the numbers. A page can report a reasonable load time from Beijing while a font, a cookie banner or an embedded map never finishes loading. The replay shows what a visitor would have seen.

What the pattern across Tokyo, Singapore and Beijing usually means

Once you have comparable runs, the shape of the results is more useful than any single number.

TTFB is high everywhere, including near the origin

If the first byte arrives slowly from every location, including the one next to your server, geography is not the main problem. Slow application code, database queries, cold server-side caches or an overloaded origin are more likely. A CDN can improve cached delivery, but it cannot by itself remove slow backend work for HTML that still has to be generated at the origin.

TTFB rises sharply only from Asian locations

This is the classic sign of a distant origin with no effective edge delivery for the HTML document. Many CDN setups cache images, scripts and stylesheets but send every HTML request back to the origin. In that case static assets load quickly from Singapore while the document itself still crosses the Pacific or the Indian Ocean. What Is a Good TTFB? explains why the commonly cited 0.8-second guideline is a rough reference and not a pass/fail line for a single lab run.

Tokyo and Singapore look reasonable, Beijing is much slower or incomplete

Cross-border conditions into mainland China are the usual suspect, but the replay is where you find the specific cause. Look for a page that stays blank while it waits for a web font, a script tag manager, an analytics tag, a CAPTCHA, a map or a social embed hosted on a service that loads unreliably from the mainland. One blocked resource in the critical path can hold up an otherwise healthy page.

Infrastructure is part of the picture too. Using CDN edge locations inside mainland China generally requires an appropriate ICP filing or license, depending on the service. Many international sites are therefore reached from outside the mainland even when they use a CDN, so a Beijing result can look quite different from Tokyo even with a well-configured global CDN.

TTFB is similar, but total load time diverges

When the first byte arrives at roughly the same time everywhere but the full load finishes much later from some locations, the bottleneck is in delivering the page’s resources. Heavy images, a long list of requests, or assets served from a distant third-party host all cost more on long or congested paths. Do Large Images Slow Down a Website? covers the transfer side. The protocol field is worth checking as well, because whether HTTP/2 or HTTP/3 was negotiated can differ between paths. HTTP/2 vs HTTP/3 explains when that matters.

Limits of an Asian lab test

A Latixo result from Tokyo, Singapore or Beijing is one page load, from one Browser Node, under one fixed profile, at one point in time. It is good evidence for diagnosis, before-and-after checks and spotting regional problems. It does not represent every visitor in that country.

• Visitors on different ISPs and mobile carriers in the same city can take different routes to your server.
• Field data, such as the Chrome User Experience Report, aggregates real visits across devices and networks. It answers a different question than a lab test and can complement one.
• The performance grade is a Latixo heuristic based on the run. It is not a Lighthouse score or an official Core Web Vitals assessment.
• Because the Beijing node has one worker, a test there can sit in the queue longer when other jobs are running.

The Methodology page describes how tests are queued, run and reported.

Common questions

Can I test from Tokyo, Singapore and Beijing in one run?

Each test runs from the single location you select. To compare, run the same URL with the same profile from each location in turn, then repeat each one at least once.

Is a Singapore test enough to represent Southeast Asia?

It is a strong reference point for the region, because Singapore is a major connectivity hub and many CDNs and cloud providers have a presence there. Visitors in Manila, Jakarta or Ho Chi Minh City can still reach your site over different paths, so treat Singapore as an indicator, not a guarantee.

Does a Beijing test show whether my site is blocked in China?

It shows whether this node could load your page, and what it saw, during that run. A successful load does not prove the site is reachable everywhere in mainland China, and a failed or partial load does not by itself prove a block. Routing problems, timeouts and third-party failures can look similar. Repeated runs and the Loading Replay help you tell them apart.

Why is my site fast from Tokyo but slow from Singapore?

The usual causes are an origin or edge located in Japan with no equivalent delivery point in Southeast Asia, or HTML that is not cached at the edge. Compare TTFB between the two locations: if most of the gap is in TTFB, look at edge coverage and cache behavior before you look at the page itself.