Владелец сайта часто слышит жалобу «сайт тормозит», но не знает, откуда берётся медлительность. Проблема на сервере, в сети или в самой странице — чтобы это понять, нужно измерять. Для сайтов, работающих на аудиторию в Узбекистане, особое значение имеет фактор Tas-IX. В этой статье подробно разберём, как измерять скорость сайта с точки зрения Tas-IX, какими командами пользоваться и как понимать полученные цифры.
Что такое Tas-IX и как он влияет на скорость
Tas-IX — национальная сеть, через которую интернет-провайдеры и дата-центры Узбекистана обмениваются трафиком. Если и сервер сайта, и провайдер пользователя подключены к Tas-IX, данные идут коротким путём внутри страны. В противном случае запрос может уйти через международный канал и вернуться через зарубежные узлы. Особенно ярко эта разница видна во времени отклика, то есть в ping и во времени до первого байта.
Важно помнить, что Tas-IX лишь сокращает сетевой путь. Если страница загружает изображения по 8 мегабайт и десятки скриптов или сервер медленно выполняет PHP-код, даже лучшая сеть ситуацию полностью не исправит. Поэтому измерять нужно поэтапно: сначала сеть, затем ответ сервера и в конце саму страницу.
Этап 1: проверка сетевого маршрута
Сначала посмотрите, каким путём идут данные между пользователем и сервером. Для этого используют ping и traceroute или более удобный инструмент mtr. mtr показывает потери и задержку на каждом промежуточном узле, что помогает понять, на каком именно звене возникает проблема.
# Linux / macOS
mtr -rwc 50 example.uz
traceroute example.uz
# Windows
tracert example.uz
ping -n 20 example.uz
При чтении результатов обратите внимание на несколько вещей. При подключении к местному серверу через Tas-IX ping обычно составляет от нескольких до десятков миллисекунд. Если из Ташкента до сервера в Ташкенте ping исчисляется сотнями миллисекунд, а traceroute показывает маршрут через зарубежные узлы, трафик идёт не через Tas-IX, а через международный канал. Небольшие потери на промежуточных узлах часто не важны, поскольку некоторые маршрутизаторы отвечают на ping с низким приоритетом. Значение имеют потери и задержка на последнем узле, то есть на самом сервере.
Этап 2: поэтапное измерение ответа сервера
Даже при хорошей сети сайт может работать медленно. Это удобно выяснять с помощью curl, который разбивает время запроса на этапы: DNS-запрос, TCP-соединение, TLS-рукопожатие и получение первого байта. Сначала запишем формат в файл, а затем используем его:
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/
Важно понимать, что означает каждая строка. Большое время DNS говорит о том, что серверы имён домена отвечают медленно или DNS-резолвер пользователя находится далеко. Время соединения отражает сетевую задержку и должно примерно совпадать с ping. TLS — время на SSL-рукопожатие. TTFB — время, пока сервер подготовит страницу и отправит первый байт. Если соединение быстрое, а разница между ним и TTFB велика, проблема не в сети, а в коде на сервере, базе данных или отсутствии кеша.
Одно измерение может оказаться случайным, поэтому повторите запрос несколько раз:
for i in $(seq 1 10); do
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.uz/
done
Этап 3: полная загрузка страницы
Даже если сервер отвечает быстро, браузеру нужно загрузить изображения, шрифты, CSS и JavaScript, чтобы пользователь увидел страницу. Это видно на вкладке Network в инструментах разработчика. Перезагрузите страницу с отключённым кешем и посмотрите, какие файлы занимают больше всего времени. Часто главная проблема — внешние ресурсы: шрифт с зарубежного сервера, видеоплеер или виджет чата. Даже если ваш сайт в Tas-IX, эти файлы идут через международный канал и замедляют страницу.
Практический пример: интернет-магазин в Ташкенте
Владелец магазина бытовой техники в Ташкенте получил жалобы, что вечером сайт открывается медленно. Сначала проверили mtr: сервер местный, ping около 5–10 миллисекунд, потерь нет. Значит, сеть не виновата. Затем curl измерил главную страницу: соединение было быстрым, но TTFB доходил до нескольких секунд. Анализ показал, что блок «хиты продаж» на главной каждый раз отправлял тяжёлый запрос к базе данных. После включения кеша страниц и добавления индекса TTFB заметно сократился. Затем на вкладке Network нашли два шрифта, загружавшихся из-за рубежа, и перенесли их на сам сайт.
Пример показывает важный вывод: без измерений легко искать проблему не там. Владелец магазина сначала хотел сменить хостинг, хотя причина была в коде.
Советы для корректных измерений
- Проводите измерения с выключенным VPN, иначе трафик пойдёт через зарубежье и результат исказится.
- Проверяйте минимум с двух разных провайдеров, например с домашнего и мобильного интернета.
- Измеряйте отдельно днём и вечером, когда сеть загружена сильнее всего.
- Записывайте результаты: сравнение цифр до и после изменений — самое надёжное доказательство.
- Кроме главной, тестируйте самые тяжёлые страницы, например каталог или результаты поиска.
Что делать, если результат плохой
Если mtr показывает, что трафик идёт через зарубежье, сохраните результаты и отправьте их хостинг-провайдеру. Иногда проблема на стороне провайдера пользователя, и решить её может только он, но точный traceroute помогает быстро её локализовать. Если велик TTFB, включите кеш, отключите лишние плагины и проанализируйте медленные запросы. В хостинге sayt.uz серверы находятся в Узбекистане и подключены к Tas-IX, поэтому сетевая часть обычно не вызывает проблем; при вопросах результаты измерений можно отправить в техподдержку sayt.uz через тикет.