Tracker.ru / Документация

Waterfall времени ответа: DNS / Connect / TLS / TTFB

6 мин чтения
Обновлено 12 мая 2026

HTTP-чек со стороны клиента — это не одна операция, а цепочка фаз. Сначала браузер (или мониторинг) резолвит домен в IP, потом устанавливает TCP-соединение, потом — TLS-рукопожатие для HTTPS, и только после всего этого начинает ждать первого байта ответа от сервера. Каждая фаза занимает своё время, и общая «скорость сайта» — это их сумма.

Tracker.ru замеряет все четыре фазы для каждого HTTP-чека и показывает их в журнале проверок в виде waterfall — горизонтального графика с разноцветными отрезками. Это даёт прямой ответ на вопрос «почему сайт медленный»: видно, в какой именно фазе теряются миллисекунды.

Из каких фаз состоит waterfall

Полный цикл от запроса до первого байта в Tracker.ru разбит на четыре независимо измеряемые фазы:

  • DNS — резолвинг домена в IP-адрес. Запрос уходит к DNS-резолверу (как правило — к локальному кэшу провайдера или сервиса), который возвращает A/AAAA-запись. Норма для прогретого кэша — 5–30 ms; долгий резолвинг (200+ ms) указывает на проблему с авторитетными NS, гео-удалённый резолвер или TTL=0.
  • Connect (TCP handshake) — трёхстороннее SYN/SYN-ACK/ACK с целевым сервером. Зависит главным образом от RTT (round-trip time) — физического расстояния и качества канала. Москва ↔ Москва — обычно 5–15 ms; Москва ↔ Франкфурт — 30–60 ms; Москва ↔ США — 130–200 ms.
  • TLS (handshake) — рукопожатие шифрованного канала, только для HTTPS. Современный TLS 1.3 укладывается в 1 RTT, TLS 1.2 — в 2 RTT. Долгий TLS handshake (300+ ms на близком сервере) — признак тяжёлого cipher suite, OCSP-проверки сертификата или непрогретых сессий. Для HTTP-чеков (не HTTPS) фаза равна 0 — рукопожатия нет.
  • TTFB (Time To First Byte) — время от завершения handshake до получения первого байта ответа. Это серверная обработка: маршрутизация во фреймворке, выполнение запроса в БД, рендеринг шаблона, формирование заголовков. Норма для статических страниц — 50–200 ms; для динамических с БД-запросами — 200–600 ms; всё, что выше 1 секунды, обычно требует профайлинга backend.

Сумма этих четырёх значений — общая длительность HTTP-чека (поле response_time в журнале). Если у вас открыта главная страница в браузере, после TTFB ещё происходит загрузка тела HTML, парсинг, дозагрузка ассетов, рендер DOM — но всё это уже за пределами серверного ответа, и Tracker.ru это не измеряет: мы фокусируемся на серверной части, которой можно управлять.

Как читать waterfall в Tracker.ru

В журнале проверок каждая успешная запись содержит подробности по фазам. Достаточно навести курсор на строку — появится tooltip с разбивкой:

Total: 487 ms
├─ DNS:     12 ms
├─ Connect: 38 ms
├─ TLS:     74 ms
└─ TTFB:   363 ms

Если вы открываете страницу URL и переключаетесь на вкладку «Логи», то же самое доступно колонками. Для длинных периодов (7/30 дней) удобнее смотреть тренды на странице статистики — там видно, какая из фаз растёт со временем.

Помимо UI, эти же значения доступны через REST API: эндпоинт GET /api/urls/{id}/logs возвращает поля dns_time, connect_time, tls_time, ttfb для каждой записи (миллисекунды). Это полезно, если вы экспортируете метрики в Grafana, Prometheus или собственный observability-стек.

Зачем смотреть на waterfall

Один общий «response time» не отвечает на вопрос «что чинить». Waterfall — отвечает.

«Сайт стал медленнее за последний месяц»

Откройте 30-дневный график response time на странице URL. Если общий тренд ползёт вверх — дальше смотрите по фазам. Растёт TTFB при стабильных DNS/Connect/TLS — проблема на backend (выросла нагрузка на БД, появился медленный запрос, кэш не работает). Растёт DNS — проверьте состояние авторитетных NS и TTL записей. Растёт TLS — посмотрите cipher suite и нет ли OCSP must-staple без прогретой сессии. Растёт Connect при стабильном TTFB — изменилась маршрутизация или сетевой провайдер.

«Сайт открывается через раз медленно»

Точечные всплески одной фазы — другой класс проблем. Спайки DNS до 1–2 секунд — резолвер периодически промахивается мимо кэша и идёт на авторитетный NS. Спайки TLS — серверу не хватает CPU на криптографию (характерно для дешёвых VPS). Спайки TTFB — фоновые задачи (cron, GC, бекапы) забирают ресурсы у обработчика запросов.

Tracker.ru хранит каждый чек, поэтому такие спайки видны на детальном графике, а не усредняются в часовой средней.

«Один регион тормозит, другие нет»

Если вы используете мультирегиональный мониторинг — Москва, Франкфурт, Алматы — то waterfall у каждого региона свой. Это сразу разводит две причины:

  • TTFB одинаковый везде, а Connect в одном регионе вырос — значит, проблема в сети между этим регионом и сервером. Серверу легчать не надо, надо смотреть на провайдера или промежуточные хопы.
  • TTFB вырос везде одинаково — наоборот, серверная нагрузка. Сеть ни при чём.

«Сайт быстрый, но Google Search Console говорит, что медленный»

Google использует TTFB как один из сигналов Core Web Vitals (метрика INP частично коррелирует). Если PageSpeed Insights показывает «Reduce server response times», но в браузере вы не чувствуете замедления — отслеживайте именно TTFB на регулярных чеках. Среднее за 7 дней даёт более устойчивую картину, чем разовые замеры от Google.

Что делать с большими значениями

Фаза Что значит большой показатель Куда смотреть
DNS > 100 ms Резолвер промахивается или авторитетный NS далеко TTL DNS-записей, гео-удалённость NS, переход на быстрый DNS-провайдер
Connect > 200 ms (близкий сервер) Длинный сетевой путь или потеря пакетов traceroute, провайдер, CDN/edge
TLS > 300 ms Тяжёлый cipher или OCSP без stapling TLS 1.3, OCSP stapling, переиспользование сессий
TTFB > 1000 ms Медленный backend Профайлинг запроса, slow query log БД, кэш страниц

Эти пороги — ориентиры, не абсолютные правила. Сайт-первоисточник со сложной аналитикой может иметь TTFB 800 ms и быть в норме; статический лендинг с TTFB 400 ms — уже подозрительный.

Сравнение с другими сервисами

Разбор времени ответа на фазы есть не у всех мониторинг-сервисов:

  • Tracker.ru — все четыре фазы (DNS / Connect / TLS / TTFB) для каждого чека, доступны в UI и через API.
  • UptimeRobot — показывает только общий response time, без разбивки.
  • Pingdom — да, есть аналогичная разбивка в синтетическом мониторинге.
  • Better Stack (Better Uptime) — да, в продвинутых тарифах.
  • Healthchecks.io — нет (это heartbeat-сервис, не URL-мониторинг).

Это важная деталь при выборе мониторинга для production-сайтов: без разбивки по фазам диагностика медленного сайта превращается в гадание. Подробное сравнение функционала Tracker.ru с конкурентами — в разделе сравнения.

Где tracker.ru хранит данные

Все четыре поля сохраняются в каждой записи журнала проверок:

  • dns_time — миллисекунды
  • connect_time — миллисекунды
  • tls_time — миллисекунды (0 для HTTP без TLS)
  • ttfb — миллисекунды

Если фаза не успела отработать (например, DNS не разрешился — host_not_found), все последующие поля остаются нулевыми, а статус чека помечается как ошибочный с соответствующим error_status.

История хранится за весь период жизни URL: вы можете посмотреть waterfall чеков за вчера, за месяц назад или сравнить два периода между собой.

Связанные статьи