TTFB (Time to First Byte) показывает, сколько времени проходит от начала запроса до получения первого байта ответа. Если этот этап затянут, браузер ещё не начал получать HTML, поэтому оптимизация изображений или скриптов не устранит исходную задержку.
Но TTFB — не синоним скорости всей страницы. Сначала отделите ожидание первого байта от скачивания ответа, выполнения JavaScript и отрисовки: так станет понятно, где искать причину и какие изменения проверять.
Что именно измеряет TTFB
Для загрузки документа TTFB заканчивается в момент, когда браузер получает первый байт ответа. До него могут происходить редиректы, поиск DNS, установка TCP-соединения, согласование TLS, отправка запроса и подготовка ответа сервером.
Граница показателя зависит от инструмента. В Navigation Timing интервал до responseStart относится ко всей навигации, а Chrome DevTools отдельно показывает этап Waiting (TTFB) конкретного запроса. Поэтому сравнивайте результаты, полученные одним способом, для одного URL и в похожих условиях.
TTFB отвечает на вопрос «когда начал приходить ответ», но не показывает, когда страница стала готова для посетителя. После первого байта браузеру ещё нужно получить тело ответа, загрузить зависимые ресурсы, выполнить код и отрисовать интерфейс.
| Этап | Что он помогает понять | | --- | --- | | DNS и соединение | Есть ли задержка до отправки запроса | | Waiting (TTFB) | Как долго ожидается начало ответа | | Content Download | Сколько занимает получение тела ответа | | DOMContentLoaded и Load | Когда документ и его ресурсы проходят следующие стадии загрузки |
Быстрый TTFB не компенсирует тяжёлые изображения и блокирующие скрипты. Медленный TTFB, наоборот, может задержать даже лёгкую страницу.
Как проверить TTFB в браузере
- Откройте Chrome DevTools, перейдите на вкладку Network и очистите список запросов.
- Загрузите точный URL, на который приходит пользователь. Учитывайте редиректы с HTTP на HTTPS и между вариантами домена.
- Выберите запрос типа Document и откройте вкладку Timing.
- Сравните DNS Lookup, Initial connection, Waiting (TTFB) и Content Download.
- Повторите проверку с включённым и отключённым кэшем. Тёплое соединение и кэш могут скрыть задержку первого визита.
Проверяйте не только главную. Карточка товара, форма заявки или личный кабинет могут обращаться к базе данных и внешним сервисам иначе, поэтому их TTFB бывает другим.
Как измерить через curl
Для независимой проверки из командной строки можно получить код ответа, время редиректов, TTFB и полное время запроса:
curl -sS -o /dev/null -L \
-w 'code=%{http_code} redirect=%{time_redirect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/Подставляйте только публичный URL без токенов, адресов служебных панелей и других секретов. Один запуск не доказывает постоянную проблему: повторите измерение, сохраните время проверки и сравните результат из другой сети или региона.
Если curl и браузер дают разные значения, проверьте условия. Браузер может использовать кэш, существующее соединение, Service Worker и расширения, а curl начинает с другим окружением.
Где искать причину задержки
Долго выполняются DNS или соединение
Проверьте DNS-ответ, сетевой маршрут, TLS и работу CDN или прокси. Серверное приложение ещё могло не получить запрос, поэтому начинать с оптимизации базы данных рано.
Соединение быстрое, но велико ожидание ответа
Ищите задержку на origin-сервере: обработку PHP, запросы к базе данных, обращение к внешнему API, промах кэша, очередь фоновой операции или нехватку ресурсов. Сопоставьте время проверки с серверными и прикладными логами.
TTFB обычный, а страница всё равно медленная
Смотрите размер ответа, изображения, шрифты, CSS, JavaScript и сторонние виджеты. Это уже задача полной загрузки и отрисовки, а не только первого байта.
Медленным оказался один URL
Сравните шаблон, запросы к базе и внешние зависимости этой страницы с быстрым URL. Общая проверка главной здесь даст ложное спокойствие.
Задержка видна только из части сетей
Сравните DNS, CDN-узел и маршрут из проблемного региона. Проверка из одной точки не показывает опыт всех посетителей.
Порядок диагностики без лишних изменений
- Зафиксируйте точный URL, код ответа, цепочку редиректов, время и точку проверки.
- Разделите DNS, соединение, Waiting (TTFB) и получение тела ответа.
- Повторите замер одинаковым способом, чтобы исключить случайный всплеск.
- Проверьте серверные логи и метрики за тот же интервал.
- Исправляйте самый длинный подтверждённый этап и повторяйте тот же тест.
Не начинайте с переноса хостинга или установки нового кэша только по одному числу. Без разложения этапов такое изменение может не затронуть причину и усложнить сравнение.
Ограничения TTFB
У TTFB нет универсального значения, которое одинаково подходит любому проекту. На результат влияют география, сеть, кэш, повторное использование соединения, CDN и логика конкретной страницы. Полезнее сравнивать показатель с собственной стабильной базовой линией и отмечать устойчивое ухудшение.
TTFB также не подтверждает, что на странице есть нужный контент, работает форма или завершился пользовательский сценарий. Общий план проверки медленного сайта описан в материале «Сайт работает, но медленно: как контролировать время ответа».
Что делать после исправления
Повторите исходный тест тем же инструментом, а затем проверьте страницу как пользователь. Если задержка возникает периодически, разового замера недостаточно: нужна история проверок точного URL, чтобы связать ухудшение с нагрузкой, релизом или внешней зависимостью.
Чтобы замечать повторяющиеся задержки без ручных запусков, настройте регулярную проверку сайта в Web-Puls. Начните с критичного публичного URL и задайте реакцию только на подтверждённое ухудшение, чтобы уведомления оставались полезными.