Tracker.ru На главную

Waterfall сайта на пальцах: DNS, TCP, TLS, TTFB

Когда говорят «сайт тормозит» — за этой фразой не одна цифра, а четыре фазы: резолвинг домена (DNS), установка соединения (TCP), TLS-рукопожатие и серверная обработка (TTFB). Каждую можно измерить отдельно — и понять, что именно чинить.

Waterfall сайта на пальцах: DNS, TCP, TLS, TTFB

Когда говорят «сайт тормозит» — за этой фразой не одна цифра, а четыре фазы: резолвинг домена (DNS), установка соединения (TCP), TLS-рукопожатие и серверная обработка (TTFB). Каждую можно измерить отдельно — и понять, что именно чинить, вместо того чтобы гадать по общему «время ответа: 800 мс».

Если ваш сайт стал медленнее, чем месяц назад, или Google в Search Console пишет «Reduce server response times» — без разбивки по фазам диагностика превращается в шаманство. Эта статья — про то, как читать waterfall времени ответа, что в каждой фазе норма, а что повод копать.

Почему «сайт медленный» — это бессмысленный диагноз

Представьте, что вы пришли к врачу с жалобой «мне плохо». Врач спрашивает: где болит? Голова, желудок, спина? Без уточнения лечить нечем. С сайтом так же. «Медленно» бывает разное:

  • DNS-резолвер у пользователя ходит к авторитетному серверу 2 секунды, потому что вы поставили TTL=60 и часто меняли запись.
  • Сервер в Москве, пользователь в Алматы — каждый TCP-пакет летит 80 мс туда-обратно. Только на установку соединения уходит четверть секунды.
  • На сервере включён старый TLS 1.2 с тяжёлым cipher suite и без OCSP stapling — рукопожатие 400 мс на ровном месте.
  • Приложение в порядке, но запрос к БД без индекса крутится 1.2 секунды.

Все эти симптомы пользователь видит одинаково: «сайт грузится медленно». Но чинят их в четырёх разных местах — и часто разные люди. Уровни ответственности тоже разные: DNS — это администратор домена, TCP/TLS — системный администратор или хостинг, TTFB — разработчик.

Когда мониторинг показывает один общий «response time: 1247 мс» — вы знаете только что плохо. Когда показывает waterfall с разбивкой — вы знаете, кому позвонить.

Из каких четырёх фаз состоит время ответа сайта

Полный цикл от вашего запроса до первого байта ответа проходит через четыре фазы, каждая со своим назначением и временем.

DNS — справочник адресов

Браузер или мониторинг получает доменное имя example.com и должен превратить его в IP-адрес 93.184.215.14. Для этого он спрашивает DNS-резолвер: «какой IP у этого домена?». Резолвер либо отвечает из кэша мгновенно, либо идёт по цепочке к авторитетным серверам и спрашивает их.

Аналогия: представьте, что вам надо позвонить в компанию. Имя компании вы знаете, а номер — нет. Открываете справочник, ищете строку, читаете номер. Это и есть DNS.

Что считать нормой:

  • 5–30 мс — прогретый кэш у близкого резолвера. Чаще всего так.
  • 30–100 мс — холодный кэш, резолвер идёт к авторитетным NS, но они недалеко.
  • 200+ мс — что-то не так. Удалённые NS, низкий TTL, проблема у резолвера или у регистратора.

Если DNS постоянно даёт 500 мс — пользователи получают «сайт зависает на старте» ещё до того, как успел отработать backend. Сам сайт может быть быстрым, но первая полусекунда уходит на справочник.

TCP Connect — первый звонок

IP-адрес получен. Теперь надо установить соединение с сервером по этому адресу. TCP делает это через рукопожатие из трёх пакетов: SYN, SYN-ACK, ACK. Каждый пакет летит туда-обратно по сети. Время этой фазы зависит почти исключительно от RTT (round-trip time) — физического расстояния между мониторингом и сервером.

Аналогия: вы набрали номер. Гудки, ответный «алло», ваше «здравствуйте». Пока эти три реплики не прошли — разговора нет.

Что считать нормой:

  • Москва ↔ Москва — 5–15 мс.
  • Москва ↔ Франкфурт — 30–60 мс.
  • Москва ↔ США — 130–200 мс.
  • Москва ↔ Сингапур — 200–300 мс.

Если у вас вырос Connect, а сервер вы не переезжали — изменилась сеть. Это могут быть проблемы у магистрального провайдера, маршрутизация через далёкий хоп, замена аплинка. Сам сервер тут ни при чём — он ещё ничего не делал, его только окликнули.

TLS — договор о шифровании

После TCP идёт TLS handshake, но только для HTTPS. Клиент и сервер договариваются о версии протокола, выбирают cipher suite, обмениваются ключами, сервер показывает сертификат. Современный TLS 1.3 укладывается в 1 RTT, TLS 1.2 — в 2 RTT, плюс возможна OCSP-проверка отзыва сертификата у удостоверяющего центра.

Аналогия: вы дозвонились до банка. До того, как обсуждать деньги, оператор спрашивает кодовое слово, проверяет ваш номер по базе и говорит «теперь говорим в защищённом режиме». Это занимает пару секунд — даже если потом вы только переведёте 100 рублей.

Что считать нормой:

  • 50–150 мс — TLS 1.3 на близком сервере с прогретой сессией.
  • 150–300 мс — TLS 1.2 или удалённый сервер.
  • 300+ мс — тяжёлый cipher, отсутствие OCSP stapling, непрогретая сессия.

Для HTTP без шифрования эта фаза равна нулю — рукопожатия нет. Это нормально и не означает проблему.

TTFB — время на обдумывание ответа

TLS установлен, защищённый канал есть. Клиент отправляет HTTP-запрос: GET /products HTTP/2. Сервер получает запрос и начинает работать: маршрутизация в фреймворке, проверка авторизации, запросы к БД, рендер шаблона, формирование заголовков. Время от отправки запроса до первого байта ответа — это и есть TTFB (Time To First Byte).

Аналогия: вы задали оператору вопрос. Он смотрит в систему, проверяет данные, формулирует ответ. Время от вашего вопроса до первого его слова — это TTFB.

Что считать нормой:

  • 50–200 мс — статика, простой backend, кэш страниц.
  • 200–600 мс — динамика с парой запросов к БД.
  • 600–1000 мс — тяжёлая страница с агрегациями, аналитикой, внешними API.
  • 1000+ мс — что-то идёт не так. Профайлинг, slow query log, проверка кэша.

TTFB — главный индикатор скорости backend. Google использует его как один из сигналов Core Web Vitals — медленный TTFB просаживает позиции в поисковой выдаче.

Как читать waterfall на примере

Вот как выглядит разбивка одного успешного чека:

Total: 487 мс
├─ DNS:     12 мс    ████
├─ Connect: 38 мс    █████████████
├─ TLS:     74 мс    ████████████████████████
└─ TTFB:   363 мс    █████████████████████████████████████████████████████████████████████████████████████████████████

Что эта картинка говорит:

  • DNS 12 мс — резолвер сработал из кэша. Норма.
  • Connect 38 мс — близкий сервер, скорее всего в той же стране. Норма.
  • TLS 74 мс — современный TLS 1.3, чуть выше идеала, но в пределах. Норма.
  • TTFB 363 мс — основное время. Скорее всего динамическая страница с запросами к БД. Норма для CMS, повод копать для лендинга.

А вот тот же сайт через две недели:

Total: 1842 мс
├─ DNS:     11 мс
├─ Connect: 41 мс
├─ TLS:     78 мс
└─ TTFB:  1712 мс    ⚠️ выросло в 4.7 раза

DNS / Connect / TLS на месте, TTFB вырос почти впятеро — проблема на backend. Сетевые фазы стабильны, значит маршрут и провайдер не меняли. Идти разбираться к разработчикам: что они задеплоили за последние две недели, какие запросы стали медленнее, нет ли нового медленного API в цепочке.

5 типичных кейсов

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

Откройте 30-дневный тренд по фазам. Если ползёт вверх TTFB при стабильных остальных — нагрузка на backend выросла. Появился медленный запрос, отвалился кэш, БД набрала записей и сканирует таблицу. Если растёт TLS — посмотрите cipher suite и OCSP stapling. Если Connect — изменилась маршрутизация или провайдер у дата-центра.

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

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

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

Это мультирегиональный мониторинг ловит мгновенно. Москва — 400 мс, Франкфурт — 380 мс, Алматы — 1900 мс. Сравните waterfall по регионам: если в Алматы вырос только Connect — проблема в сети между сервером и казахстанским провайдером, серверу легчать не надо. Если TTFB вырос везде одинаково — наоборот, бэкенд под нагрузкой, сеть ни при чём.

«Google говорит slow, у меня всё быстро»

Открываете сайт — работает шустро. Search Console пишет «Reduce server response times». Объяснение простое: вы — один пользователь с прогретым DNS, разогретыми TCP-соединениями и кэшированной страницей. Google замеряет холодный заход с разных стран, разных устройств. Чтобы поймать то, что видит Google — смотрите TTFB на регулярных чеках со среднесуточным значением, а не разовые замеры из браузера.

«Новый сервер — и TLS вырос вдвое»

Переехали с одного хостинга на другой, сайт открывается медленнее, хотя «всё то же самое». Сравните waterfall до и после. Если TLS скакнул с 80 мс до 400 мс — у нового хостинга включён TLS 1.2 вместо 1.3, нет OCSP stapling или cipher suite с тяжёлой криптографией. Это правится в конфиге веб-сервера, без переписывания приложения.

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

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

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

Как Tracker.ru показывает waterfall

В Tracker.ru разбивка по фазам собирается для каждого HTTP-чека — это не отдельная платная фича, а часть базового мониторинга. Открываете страницу URL, переключаетесь на вкладку «Логи», наводите курсор на запись — появляется tooltip с разбивкой DNS / Connect / TLS / TTFB в миллисекундах.

Для трендов есть отдельный график на странице URL: видно, как менялась каждая фаза за 7 или 30 дней. Сразу заметно, если одна из них поползла вверх, пока остальные стабильны.

Через REST API те же значения доступны в полях dns_time, connect_time, tls_time, ttfb каждой записи журнала — если выгружаете метрики в Grafana, Prometheus или свой observability-стек. Подробности — в технической документации по разбору времени ответа.

Часто задаваемые вопросы

Что такое TTFB и почему он важен?

TTFB (Time To First Byte) — время от отправки HTTP-запроса до получения первого байта ответа. Это серверная обработка: маршрутизация во фреймворке, запросы к БД, рендер шаблона. Google использует TTFB как один из сигналов Core Web Vitals — медленный TTFB ухудшает позиции сайта в поисковой выдаче.

Сайт медленный — куда смотреть в первую очередь?

Сначала разберите waterfall на четыре фазы. Чаще всего проблема в TTFB (backend) — выросла нагрузка на БД, появился медленный запрос, отвалился кэш. Реже — в TLS (тяжёлый cipher, нет OCSP stapling). Иногда — в Connect (сеть между мониторингом и сервером изменилась). DNS вырастает обычно у сайтов с агрессивно низким TTL.

Какой TTFB считается нормальным?

Для статики без БД — 50–200 мс. Для динамики с парой запросов к БД — 200–600 мс. Тяжёлая страница с агрегациями и внешними API — 600–1000 мс. Всё, что выше секунды, обычно требует профайлинга backend: посмотреть slow query log, профилировать ORM, проверить, что кэш реально работает.

Чем waterfall в мониторинге отличается от Lighthouse и PageSpeed Insights?

Lighthouse и PageSpeed делают разовый замер из конкретной точки в конкретный момент. Это синтетический тест: один раз, никакой истории. Waterfall в мониторинге — это регулярные замеры тех же фаз на каждой проверке (раз в минуту или в 5 минут). Видно тренды за неделю и месяц, спайки в часы пик, разницу между регионами. Инструменты не конкурируют — они дополняют друг друга: Lighthouse даёт детальный разбор одной загрузки страницы, waterfall в мониторинге — устойчивую картину серверного ответа во времени.

Зачем мониторить DNS, если он редко падает?

Долгий DNS — это «сайт зависает на старте» с точки зрения пользователя ещё до того, как заработал backend. Сам сайт может быть быстрым, но первая полусекунда уходит на справочник. Кроме того, рост DNS в трендах часто намекает на проблему с авторитетными серверами имён заранее — пока не упало совсем. Дешёвая фаза с точки зрения отслеживания, заметная с точки зрения пользовательского опыта.

См. также