Measuring Website Speed on Tas-IX: Commands and How to Read Results

Site owners often hear "the site is slow" without knowing where the slowness comes from: the server, the network or the page itself. Measuring is the only way to tell. For sites serving visitors in Uzbekistan, Tas-IX plays a special role, so this article explains how to measure speed with Tas-IX in mind, which commands to use and how to read the results.

What Tas-IX is and why it matters

Tas-IX is the national network through which Uzbek internet providers and data centres exchange traffic. When both the server and the visitor's provider are connected to it, data takes a short path inside the country; otherwise a request may travel abroad and back. The difference shows most clearly in latency and time to first byte. Tas-IX only shortens the network path, though: 8 MB images, dozens of scripts or slow PHP code will hurt on any network, so measure in stages.

Stage 1: check the network route

Start with ping and traceroute, or better, mtr, which shows loss and latency at every hop.

# Linux / macOS
mtr -rwc 50 example.uz
traceroute example.uz

# Windows
tracert example.uz
ping -n 20 example.uz

A local server reached via Tas-IX typically answers within a few to a few tens of milliseconds. If a Tashkent user sees hundreds of milliseconds to a Tashkent server and the trace passes through foreign hops, traffic is not using Tas-IX. Small loss on intermediate hops is often harmless, since some routers deprioritise ping replies; what matters is loss and latency at the final hop.

Stage 2: break down the server response

curl can split a request into DNS lookup, TCP connect, TLS handshake and first byte:

cat > curl-format.txt <<'EOF'
   DNS:      %{time_namelookup}s
   Connect:  %{time_connect}s
   TLS:      %{time_appconnect}s
   TTFB:     %{time_starttransfer}s
   Total:    %{time_total}s
EOF

curl -o /dev/null -s -w "@curl-format.txt" https://example.uz/

A large DNS time points to slow name servers or a distant resolver. Connect time reflects network latency and should roughly match ping. If connect is fast but the gap to TTFB is large, the problem is server-side code, the database or missing caching rather than the network. Repeat the measurement to rule out flukes:

for i in $(seq 1 10); do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.uz/
done

Stage 3: full page load

Open the Network tab in your browser's developer tools, reload with cache disabled and see which files take longest. External resources such as fonts, video players or chat widgets hosted abroad often dominate, and they travel over international links even if your site is on Tas-IX.

Example: an online shop in Tashkent

An appliance shop in Tashkent received complaints about slow evenings. mtr showed a local server, 5-10 ms ping and no loss, so the network was fine. curl showed fast connects but TTFB of several seconds: a "best sellers" block ran a heavy database query on every view. Enabling page caching and adding an index cut TTFB sharply, and two fonts loaded from abroad were moved onto the site. The owner had planned to switch hosting, but the cause was in the code.

Tips for reliable measurements

Turn off VPN, or traffic will be routed abroad.
Test from at least two providers, such as home broadband and mobile.
Measure both during the day and in the evening peak.
Record results before and after every change.
Test heavy pages like catalogue and search, not just the home page.

If the results are bad

If mtr shows traffic leaving the country, save the output and send it to your hosting provider; sometimes only the visitor's ISP can fix the route, but a precise trace speeds things up. If TTFB is the issue, enable caching, remove unnecessary plugins and analyse slow queries. sayt.uz servers are located in Uzbekistan and connected to Tas-IX, and you can send your measurements to sayt.uz support through a ticket if you have questions.