Your website is lightning fast in Moscow, but slow for a client in Brazil or Indonesia? This is a common issue for marketers, arbitrage specialists, and e-commerce teams working across multiple geographies. Let's explore why loading speed depends on the user's country and how to accurately measure TTFB (Time To First Byte) through residential IPs to see the real picture, not just the readings from your office.
Why website speed depends on the client's country
Website loading speed is not an absolute value, but the result of a whole chain of factors: the distance to the server, the quality of the provider's network, the load on the CDN in a specific region, DNS resolution, and sometimes even simple traffic filtering at the country level. If your server is located in Germany and a client accesses it from Vietnam, the request physically passes through more nodes, and every millisecond of delay adds up to a noticeable slowdown.
For arbitrage specialists, this is critical: if a landing page loads in 4-5 seconds instead of 1-2, part of the traffic from paid ads on Facebook Ads or TikTok Ads simply drops off before the offer is shown. For SMM agencies promoting a brand in several countries, a slow website tarnishes the client's image. For sellers listing products on AliExpress or working with overseas buyers, speed directly affects conversion rates and search rankings. Google and other search engines also consider loading speed when ranking, specifically from the perspective of users in a particular region, not from the perspective of your office.
The problem is that most website owners check speed only once — at home or in the office — and consider the issue resolved. In reality, a website that flies in Moscow can load several times slower for a user in Mexico or the Philippines, and finding out about this without a special test is simply impossible.
What is TTFB and why businesses should measure it
TTFB (Time To First Byte) is the time from the moment the browser sends a request to receiving the first byte of response from the server. Simply put, it indicates how quickly the server "responds," even before images, scripts, and styles begin to load. A high TTFB means that the problem is not with heavy images or overloaded design, but with the infrastructure itself: the server, CDN, DNS, or the network route to a specific region.
For businesses, this is an important metric because it shows "pure" latency without the influence of the frontend. If TTFB from Russia is 80 ms and from India is 600 ms, it means the problem is not with the website's code, but that the server is physically far from Indian users or the CDN does not cover that region. A good benchmark is TTFB up to 200 ms, acceptable up to 500 ms, and anything above that is noticeably felt by users and affects abandonment rates.
| TTFB Range | Rating | What it means for business |
|---|---|---|
| up to 200 ms | Excellent | The site loads quickly, almost no speed-related drop-offs |
| 200-500 ms | Acceptable | Users will notice a delay, but it’s not critical |
| 500-1000 ms | Poor | Increased drop-offs, loss of some traffic from paid ads |
| 1000+ ms | Critical | Users leave before the page loads, conversion drops |
Why tests from your office can be misleading
If you open a website at home in Moscow and see that it loads in a second, this says nothing about the speed for a client in Germany, the USA, or Indonesia. Your provider may have direct peering with the website's hosting, you may have a browser cache, and the CDN may serve the request from the nearest point of presence to you. All of this creates an illusion of a fast website, which collapses as soon as a real user from another country opens the same page.
Online services like GTmetrix or Pingdom partially solve the problem by offering a choice of testing points, but they have a limited set of locations and, more importantly, they make requests from data center servers, not from "live" IPs of regular users. This distinction is critical: some websites and CDNs handle traffic differently from data center IPs and from residential addresses of real providers. Because of this, a test may show one TTFB, while a real user sees another.
That’s why for accurate measurement, you need to test through an IP that closely resembles that of a real client — that is, through a residential proxy from a specific country. This provides an honest picture: you see the website exactly as a user from Brazil, Vietnam, or Nigeria sees it, with the real traffic route through a local provider.
Which proxies are suitable for speed measurement: a comparison
Different types of proxies are used for testing website speed from various geographies, and the choice depends on how accurately you need to simulate a real user.
| Proxy Type | User Simulation Accuracy | When to Use |
|---|---|---|
| Data Center Proxies | Low | Quick estimate of server latency when accuracy is not critical |
| Residential Proxies | High | Measuring real TTFB as seen by an ordinary user from a home IP |
| Mobile Proxies | Very High | Speed check for mobile traffic from the region, relevant for TikTok Ads and Instagram |
Data center proxies are good for quick diagnostics: they are cheaper and provide an approximate picture of latency to the server. However, if the website or CDN applies different logic for data center traffic and regular users (which is often the case, especially with large bot protection providers), the readings may differ significantly from reality. Residential proxies eliminate this gap because the request comes from an IP issued by a local internet provider in a specific country — just as a real client would access it.
Mobile proxies make sense to connect if the majority of your audience accesses from phones via cellular networks — this is especially relevant for promotions in TikTok Ads and Instagram, where mobile traffic dominates. Cellular networks have their own routing peculiarities, which may yield a different TTFB than home Wi-Fi in the same region.
Step-by-step guide: measuring TTFB through residential IPs
Let's break down a practical algorithm that will suit both marketers without programming skills and technical specialists.
Step 1. Identify target countries. Create a list of geographies where you have or plan to have traffic: for example, the USA, Germany, Brazil, Indonesia. Each country will need a separate residential IP from that region.
Step 2. Connect residential proxies of the required geolocation. In the personal account of the proxy service, select the country, copy the connection details (host, port, username, password), and use them in your browser or testing tool. If you are running several projects simultaneously, it’s convenient to set up proxies in separate profiles of an anti-detect browser — Dolphin Anty, AdsPower, or Octo Browser — to avoid mixing sessions and cookies from different geographies.
Step 3. Open the website through the proxy and measure TTFB. The easiest way to do this is through the built-in developer tools in the Chrome browser: open the Network tab, refresh the page, and look at the first line of the document request — the waiting time (Waiting for server response) will be displayed there, which is the TTFB.
Step 4. Repeat the measurement several times. Make 5-10 measurements at different times of the day to exclude random fluctuations in server load. Record the average value for each country.
Step 5. Compare results by geography. Create a table: country — average TTFB — conclusion. If the spread between countries is more than 300-400 ms, this is a signal to adjust the CDN or choose a server closer to the problematic region.
Tools for measurement: from online services to curl
For most marketers and SMM specialists, a browser and a residential proxy connected via an extension or network settings are sufficient. But there are also specialized services that simplify the process: WebPageTest allows you to choose a testing point and provides a detailed breakdown of TTFB, DNS resolution, and connection time. Pingdom Tools and GTmetrix provide a simpler report but with a limited set of locations.
If you are technically savvy and want to automate measurements, you can use the command-line utility curl with the specified proxy and timing parameters:
curl -x http://username:password@host:port \
-o /dev/null -s -w "TTFB: %{time_starttransfer}\n" \
https://example.comThis command sends a request through a residential proxy of the specified region and outputs the time until the first byte of response is received. For a series of measurements from different countries, simply change the proxy host to the desired geolocation and run the command in a loop, saving the results in a table.
For those working with Python, a similar measurement can be done using the requests library with the proxies parameter and measuring time manually using the time module, or through the built-in response.elapsed object, which will show the total request time, including TTFB.
Practical cases: who needs this and why
Arbitrage specialists and media buyers. Before launching a campaign in Facebook Ads or Google Ads targeting a new geography, it is useful to check the TTFB of the landing page from the target country. If the delay is over 500 ms, part of the clicks will be lost before the offer fully loads, and the cost of conversion will increase without any visible reason.
SMM agencies. If an agency promotes a client's brand in several countries through Instagram and TikTok, it is important to ensure that the website linked from the profile bio loads equally quickly for the audience in each region. A slow website reduces trust in the brand and negatively impacts engagement metrics.
Sellers and e-commerce. For sellers working with overseas buyers through their own online store or listings on AliExpress, the loading speed of the product card directly influences the purchasing decision. Measuring TTFB from target countries helps understand if an additional CDN node or a change of hosting is needed.
Marketers testing ads from different regions. Before launching a localized campaign, it is useful not only to check translations and creatives but also to ensure that the technical foundation — website speed — does not become a bottleneck in the funnel.
Common mistakes when testing speed from different countries
The first and most common mistake is testing through a VPN instead of a proxy. Public VPN services often use shared data center IPs with heavy loads, which distorts measurements and yields unstable results that do not reflect the actual speed for the user.
The second mistake is a single measurement. TTFB can fluctuate depending on server load, time of day, and even caching on the CDN side. Without a series of measurements, it is easy to draw an incorrect conclusion based on a random spike or drop.
The third mistake is ignoring the difference between data center and residential IPs. If a website is protected from bots by services like Cloudflare, requests from data center addresses may be processed differently, including additional checks that artificially increase TTFB. A residential IP does not create such delays because it appears as regular user traffic.
The fourth mistake is testing only one point in the country. Large countries like the USA, Brazil, or India are heterogeneous in terms of internet infrastructure quality across different regions, so one measurement from New York will not provide any insight into the speed for a user from rural Texas.
Checklist before running the test
- All target countries for which TTFB measurement is needed have been identified
- Residential proxies of the required geolocations have been connected, not a public VPN
- A minimum of 5-10 measurements per country at different times of day has been planned
- A measurement tool is being used: browser DevTools, WebPageTest, curl, or a Python script
- Results have been compiled into a table for comparison between countries
- For countries with high TTFB, a check of CDN and server selection has been planned
Conclusion
Website speed is not an abstract technical metric, but a factor that directly influences conversion, traffic costs, and brand trust in each specific region. Measuring TTFB from your office or through a public VPN provides a distorted picture that will not help make the right decision. An honest result is obtained only by testing through an IP that closely resembles that of a real user from a specific country.
If you are launching ads in new geographies, managing multi-accounts for clients, or testing the speed of an online store for overseas buyers, we recommend using residential proxies — they provide an accurate picture of TTFB as seen by a real client. For checking mobile scenarios, mobile proxies will suffice, while for quick initial diagnostics of latency, more budget-friendly data center proxies can be used.