TTFB сайта: что измеряет метрика и как уменьшить задержку

Что входит в TTFB

Аббревиатура TTFB расшифровывается как Time to First Byte — «время до первого байта». В браузерном измерении отсчет обычно охватывает несколько последовательных этапов: перенаправления, поиск IP-адреса через DNS, создание TCP-соединения, согласование TLS для HTTPS, отправку HTTP-запроса и ожидание начала ответа.

Упрощенно метрику можно представить так:

TTFB = редиректы + DNS + TCP + TLS + отправка запроса + ожидание ответа

Последний компонент часто называют ожиданием сервера, но он шире чистого времени выполнения кода. В него могут попасть задержки на балансировщике, CDN, обратном прокси, очереди запросов и путь ответного пакета по сети. Поэтому высокий TTFB сайта нельзя автоматически объяснять «медленным хостингом».

Лабораторное и реальное измерение

Один лабораторный запрос отражает конкретную точку запуска, маршрут, состояние соединения и состояние кеша. Реальные посетители обращаются из разных регионов, через разных операторов и с разными условиями сети. Для диагностики полезна серия контролируемых измерений, а для понимания пользовательского опыта — агрегированные полевые данные, если они доступны.

Как измерить время до первого байта

Для первичной проверки подойдет curl. Команда ниже выводит длительность основных этапов и итоговое время до первого байта:

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nStart transfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
  https://example.ru/page

time_starttransfer — время от запуска запроса до начала передачи ответа. Это значение близко к TTFB в рамках данного запуска. Чтобы увидеть влияние редиректов, сначала выполните запрос без -L и изучите заголовок Location, затем повторите с переходом по цепочке:

curl -sS -L -o /dev/null \
  -w 'Redirects: %{num_redirects}\nTTFB: %{time_starttransfer}\n' \
  http://example.ru/page

Проводите не один, а несколько запросов. Первый может попасть в холодный кеш и создать новое соединение, следующие — получить кешированный ответ. Записывайте медиану серии и заметные выбросы; среднее значение легко искажает единичный сбой.

Проверка в браузере

В инструментах разработчика откройте вкладку Network, перезагрузите страницу и выберите запрос HTML-документа. В разделе Timing изучите DNS, Initial connection, SSL и Waiting for server response. Проверяйте именно основной документ, а не изображение, API-вызов или файл стилей: у разных ресурсов отличаются сервер, кеш и приоритет.

Диагностический алгоритм

1. Зафиксируйте точный URL. Сохраните схему, домен, путь, параметры, код ответа и время проверки. Сравнение разных адресов дает ложные выводы.
2. Проверьте редиректы. Запросите URL без автоматического перехода. Устраните лишние звенья вроде HTTP → другой домен → HTTPS → адрес со слешем.
3. Разделите сетевые этапы. Сравните DNS, TCP, TLS и время начала передачи. Если соединение устанавливается долго, оптимизация шаблона CMS не решит основную причину.
4. Сравните холодный и прогретый кеш. Повторите запросы с одинаковыми условиями. Дополнительно изучите Age, Cache-Control, Via, X-Cache или аналогичные заголовки, если инфраструктура их отдает.
5. Проверьте разные типы страниц. Сопоставьте статический файл, простую страницу и динамический URL. Быстрый статический ответ при медленном HTML указывает на приложение, базу данных или серверный рендеринг.
6. Сравните точки доступа. Повторите тест из регионов, где находится аудитория. Если задержка растет с расстоянием, исследуйте маршрутизацию и размещение точки выдачи.
7. Сопоставьте с серверными данными. При доступе к инфраструктуре сравните TTFB с временем обработки в логах приложения и прокси. Разница помогает отделить вычисления от очередей и сети.

Как интерпретировать результаты

Это диагностические признаки, а не доказательства. Например, быстрый повторный запрос может объясняться кешем операционной системы, повторным TLS-сеансом или кешем CDN. Подтверждайте гипотезу заголовками и журналами.

Как уменьшить TTFB

Сократить серверную обработку

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

Настроить кеширование

Публичный HTML без персональных данных можно кешировать на обратном прокси или CDN, если это допускает логика проекта. Определите TTL, правила инвалидирования и ключ кеша. Не смешивайте ответы разных пользователей, языков или устройств. Проверяйте поведение авторизованных сессий и заголовок Vary.

Упростить путь запроса

Каждый редирект добавляет отдельный цикл запроса и может потребовать нового DNS-, TCP- или TLS-этапа. Ссылки внутри сайта должны сразу вести на канонический HTTPS-адрес. Также проверьте, не проходит ли запрос через лишние прокси и не выполняет ли приложение перенаправление, которое можно выразить одним правилом на входном сервере.

Снизить сетевую задержку

Размещайте точку ответа ближе к основной аудитории или используйте CDN для кешируемых ресурсов и документов. Поддержка современных HTTP-протоколов и повторное использование соединений уменьшают накладные расходы, но не исправляют медленную бизнес-логику. Сначала определите доминирующий компонент задержки.

Типовые ошибки проверки

• делать вывод по одному запросу без повторов и фиксации региона;
• сравнивать главную страницу одного сайта с тяжелой динамической страницей другого;
• не учитывать редиректы и измерять только последний ответ цепочки;
• принимать CDN-заголовок за гарантию попадания в кеш;
• тестировать HTML с активной сессией и сравнивать его с публичным кешированным ответом;
• считать TTFB временем полной загрузки или появления основного контента;
• оптимизировать базу данных, когда основная задержка возникает на DNS, TLS или сетевом маршруте.

Границы метода

TTFB заканчивается на первом байте и ничего не говорит о размере ответа, скорости передачи оставшихся данных, блокирующих стилях, выполнении JavaScript, отрисовке или готовности интерфейса к действиям. Низкое значение возможно у страницы, которая затем долго отображается; высокое — у ответа, после которого небольшой документ быстро становится полезным.

Поэтому TTFB следует использовать для анализа серверно-сетевой части, не превращая его в универсальную оценку производительности. Общая скорость, пользовательские метрики и оптимизация клиентской части требуют отдельной диагностики. Другие практические материалы собраны в блоге SiteVisor.

Итоговый чек-лист

• измерен один и тот же публичный URL из зафиксированной точки;
• записаны HTTP-код и полная цепочка редиректов;
• разделены DNS, TCP, TLS и ожидание начала ответа;
• сравнены первый и повторные запросы;
• проверены заголовки кеша и тип полученного ответа;
• сопоставлены статические и динамические URL;
• гипотеза подтверждена логами или профилированием, если они доступны;
• после изменения выполнена повторная серия измерений в тех же условиях.

Практический порядок прост: сначала исключить редиректы и сетевые задержки, затем проверить кеш и только после этого разбирать серверную обработку. Такой подход не гарантирует мгновенного исправления, но позволяет локализовать источник TTFB и выбрать проверяемое изменение вместо случайной оптимизации.