TTFB: что это такое, почему важно и как его снизить

От DNS до первого байта ответа — разбираем, где теряется время и как вернуть пользователя

Пользователь закрыл вкладку, не дождавшись загрузки

Март 2026. Интернет-магазин детских товаров «Малыш и Карлсон» запустил рекламную кампанию в Яндекс.Директ. Бюджет 450 000 рублей, ожидаемый ROI — 180%.

Кампания пошла. Клики шли. Но конверсия в заказ оказалась втрое ниже прогноза. Аналитик открыл WebVitals и увидел: TTFB 2.8 секунды. Пользователи с мобильных устройств ждали загрузки страницы почти три секунды. 40% из них закрывали вкладку до появления контента. Регулярный замер времени ответа сервера показал бы проблему ещё до старта кампании.

Проблема была не в сервере — CPU загружен на 15%. Не в сети — ping до хостинга 12 мс. Виновник оказался в третьей строке кода: перед формированием ответа PHP делал синхронный запрос к внешнему API доставки, который отвечал 1.5–2.5 секунды.

После асинхронного вынесения этого запроса TTFB упал до 180 мс. Конверсия выросла на 23%. Рекламная кампания окупилась за 10 дней вместо месяца.

Эта история иллюстрирует главный принцип: TTFB — это не про серверную мощность. Это про время ожидания.

Что такое TTFB

TTFB (Time To First Byte) — это время от момента, когда браузер отправил HTTP-запрос, до момента, когда он получил первый байт ответа от сервера. Это не время полной загрузки страницы. Это время до начала её получения.

Измеряется в миллисекундах и включает три составляющих:

Этап	Что происходит	Кто виноват, если медленно
1. Время до сервера	DNS-резолвинг, TCP-handshake, TLS-handshake	DNS, CDN, сеть, SSL-сертификат
2. Время обработки	Сервер принимает запрос, выполняет код, формирует ответ	PHP/Python/Node.js, база данных, API-запросы
3. Время от сервера	Первый байт ответа отправляется обратно к клиенту	Сеть, маршрутизация, CDN

На пальцах: TTFB — это как время от того момента, как вы сказали бармену «пиво», до того момента, как он поставил перед вами пустой бокал. Ещё нет пива, но бармен уже начал выполнять заказ.

Полная цепочка: от клика до первого байта

Когда пользователь вводит URL, происходит следующее:

DNS-резолвинг (10–200 мс). Браузер узнаёт IP-адрес сервера. Если DNS-запись закэширована локально — 0 мс. Если нужен запрос к DNS-серверу — 10-100 мс. Если CDN с GeoDNS — до 200 мс.
TCP-handshake (1 RTT ≈ 20–100 мс). Браузер устанавливает TCP-соединение: SYN → SYN-ACK → ACK. Время равно одному round-trip.
TLS-handshake (1–2 RTT ≈ 20–300 мс). Для HTTPS: обмен ключами, согласование шифрования. TLS 1.3 быстрее TLS 1.2. Если используется OCSP-stapling — экономит ещё один RTT.
HTTP-запрос → сервер (0 мс). Браузер отправляет GET/HEAD запрос. Время передачи незначительно.
Обработка на сервере (50 мс — 5+ сек). Веб-сервер (Nginx/Apache) передаёт запрос backend'у. Backend выполняет код, ходит в базу, рендерит шаблон. Это самый переменный этап.
Первый байт ответа (1 RTT ≈ 20–100 мс). Сервер начинает отправку ответа. TTFB засчитан.

Суммарный TTFB для хорошего сайта: 50–200 мс. Для среднего: 200–800 мс. Для проблемного: 1+ секунда.

Как измерить TTFB

В DevTools браузера

F12 → Network → кликните по запросу к главной странице → вкладка Timing.

Вы увидите:

Stalled / Queueing — браузер ждёт свободного слота (HTTP/1.1 ограничение 6 соединений на домен)
DNS Lookup — резолвинг домена
Initial Connection — TCP + TLS handshake
SSL — только TLS (если отдельно)
Request sent — отправка HTTP-запроса
Waiting (TTFB) — время ожидания ответа от сервера. Это и есть TTFB.
Content Download — загрузка тела ответа (не входит в TTFB)

Через curl

$ curl -o /dev/null -s -w "Connect: %{time_connect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n" https://prufen.ru

Connect: 0.014
TTFB: 0.187
Total: 0.412

time_connect — TCP-handshake
time_starttransfer — DNS + TCP + TLS + TTFB
time_total — полная загрузка

Web Vitals и Google Search Console

Google использует TTFB как один из факторов ранжирования через Core Web Vitals. Данные собираются из реальных посещений (CrUX — Chrome User Experience Report).

Оценка	TTFB	Что значит
Хорошо	< 800 мс	Не влияет на ранжирование
Требует улучшения	800–1800 мс	Возможно небольшое влияние на SEO
Плохо	> 1800 мс	Негативно влияет на ранжирование и конверсию

Важно: Google измеряет TTFB у 75-го перцентиля (75% пользователей должны быть в зелёной зоне). Если у 25% пользователей TTFB > 3 секунды — оценка будет «Плохо» даже при среднем 600 мс.

Что замедляет TTFB

1. Медленный DNS-резолвинг

DNS-запросы проходят через цепочку рекурсивных резолверов. Если ваш DNS-провайдер перегружен или географически удалён — каждый запрос добавляет 50-200 мс.

Решение: используйте быстрый DNS-провайдер (Cloudflare DNS, Google DNS 8.8.8.8, Яндекс.DNS). Включите DNS-кэширование на стороне клиента (TTL записей).

2. TLS-handshake

TLS 1.2 требует 2 RTT для handshake. TLS 1.3 сокращает до 1 RTT. Неправильно настроенный сервер может требовать дополнительный RTT для OCSP-проверки.

Решение: включите TLS 1.3. Настройте OCSP-stapling (сервер сам прикрепляет подтверждение валидности сертификата). Используйте HTTP/2 или HTTP/3.

3. Перегруженный backend

PHP-скрипт, который выполняется 2 секунды, добавляет ровно 2 секунды к TTFB — независимо от скорости сети. Типичные причины:

Медленные SQL-запросы без индексов
Синхронные запросы к внешним API
Генерация изображений или PDF на лету
Сложные вычисления в шаблонизаторе
Блокировки в базе данных (deadlocks, table locks)

Решение: профилируйте код. В PHP используйте xdebug или встроенные профилировщики. Вынесите тяжёлые операции в фон (очереди: Redis, RabbitMQ, cron).

4. Большое расстояние до сервера

Сервер в Москве, пользователь в Владивостоке. RTT — 80-120 мс. Только сеть «съедает» 20-30% хорошего TTFB.

Решение: CDN (Cloudflare, Akamai, Yandex Cloud CDN). CDN кэширует статику ближе к пользователю и может проксировать динамический контент через edge-серверы.

5. Отсутствие серверного кэширования

Если каждый запрос требует полного рендеринга страницы — TTFB растёт линейно со сложностью страницы. WordPress без кэша может иметь TTFB 800+ мс на shared-хостинге.

Решение: серверный кэш (OPcache для PHP, кэширование страниц в Varnish/Nginx, Redis/Memcached для данных). В Пруфене — кэширование запросов к БД через Redis или встроенные механизмы.

TTFB vs другие метрики

Частая путаница: люди думают, что TTFB — это время загрузки страницы. Нет. Это только начало.

Метрика	Что измеряет	Хорошее значение
TTFB	Время до первого байта ответа	< 800 мс
FCP	First Contentful Paint — первый видимый контент	< 1.8 сек
LCP	Largest Contentful Paint — крупный контент отрисован	< 2.5 сек
TTI	Time To Interactive — страница интерактивна	< 3.8 сек
TBT	Total Blocking Time — сколько мс страница была неинтерактивна	< 200 мс

TTFB влияет на FCP и LCP, но не определяет их. Страница может иметь TTFB 100 мс, но LCP 5 секунд — если основное изображение грузится долго. Или TTFB 1.5 секунды, но LCP 2 секунды — если критический CSS inline и изображение оптимизировано.

Как снизить TTFB: чек-лист

Приоритет	Мера	Экономия
🔴 Высокий	Включить серверный кэш (Varnish / Nginx cache / Redis)	100–1000 мс
🔴 Высокий	Вынести медленные API в фон (async / cron)	500–3000 мс
🟡 Средний	Включить TLS 1.3 + OCSP-stapling	50–150 мс
🟡 Средний	Использовать быстрый DNS (Cloudflare / Google)	20–100 мс
🟡 Средний	Оптимизировать SQL-запросы (EXPLAIN, индексы)	50–500 мс
🟢 Низкий	CDN для статики	10–50 мс
🟢 Низкий	HTTP/2 Server Push (если применимо)	10–30 мс

TTFB в мониторинге Пруфена

В Пруфене есть проверка производительности, которая измеряет TTFB.

Проверка делает полный HTTP GET-запрос и фиксирует:

DNS-время — сколько занял резолвинг
Connect-время — TCP + TLS handshake
TTFB — время до первого байта ответа
Total-время — полная загрузка HTML
HTTP-статус — 200, 301, 500 и т.д.
Размер ответа — сколько байт получено

Почему это важнее Ping

Ping (ICMP) измеряет сетевую задержку. Если ping = 20 мс, а TTFB = 2500 мс — проблема в сервере, не в сети. Ping не покажет это. HTTP GET покажет.

Рекомендуемая комбинация для мониторинга скорости:

Проверка	Частота	Зачем
HTTP GET (скорость)	2–15 мин	TTFB, статус, размер ответа
Ping	2–15 мин	Отделить сетевые проблемы от серверных
Контент (XPath)	1 раз/день	Убедиться, что страница не пустая

Заключение

TTFB — это не абстрактная метрика для гиков. Это прямое влияние на бизнес: каждая секунда задержки снижает конверсию на 7%, увеличивает отказы на 32% и ухудшает позиции в поиске.

Хорошая новость: TTFB — один из самых «дешёвых» показателей для улучшения. В отличие от полной оптимизации фронтенда (сжатие JS/CSS, lazy loading, WebP), серверные улучшения часто требуют только конфигурации, а не редизайна.

Включите кэш — −100..1000 мс
Вынесите API в фон — −500..3000 мс
Оптимизируйте SQL — −50..500 мс
Настройте TLS 1.3 — −50..150 мс

Суммарный эффект может составить 1–4 секунды. Это разница между «пользователь ушёл» и «пользователь купил». А чтобы TTFB не деградировал незаметно, подключите мониторинг доступности сайта и узнавайте о замедлениях раньше пользователей.