ПаветтаTTFB — это время между запросом браузера и получением первого байта ответа от сервера. Базовая характеристика производительности backend и сети. Хороший TTFB — до 200 мс, выше 800 мс уже плохо.
Высокий TTFB обычно означает медленный backend, далёкий хостинг, тяжёлые серверные шаблоны, отсутствие кеширования. Лечится: CDN, HTTP/2 или HTTP/3, кеш на уровне приложения, рендер статики, прокачка SQL-запросов.
Время от запроса до первого байта: 180 мс с CDN и кешем, 1,2 с без них при тяжёлом backend. Разница в 7 раз бьёт по LCP и поведенческим.
Бенчмарк
TTFB выглядит одним числом, а внутри — сумма этапов: DNS-резолвинг, TCP-хендшейк, TLS-рукопожатие и только потом генерация ответа сервером. Поэтому «медленный TTFB» иногда лечится переездом ближе к аудитории, а код тут ни при чём: запрос из Москвы на сервер во Франкфурте теряет 40-60 мс только на сетевой дороге, до того как backend вообще начал работать. Разнести этапы помогает вкладка Network в DevTools (поле Waiting / TTFB) или заголовок Server-Timing — он показывает, сколько ушло именно на серверную логику против сети.
Кэш меняет картину радикально. Первый запрос «прогревает» кэш и даёт точный TTFB backend, а повторный отдаётся из CDN за 20-40 мс и маскирует реальную тяжесть генерации страницы. Поэтому замерять стоит и cache-miss, и cache-hit. В Core Web Vitals TTFB напрямую не входит, но это фундамент LCP: пока не пришёл первый байт, браузер не может начать рендер, и любые 200 мс задержки сервера целиком переносятся в задержку отрисовки. Яндекс отдельной метрики TTFB не публикует, но медленный ответ бьёт по обходу — робот при тормозах урезает частоту краулинга.
Время от отправки запроса до прихода первого байта: сеть плюс генерация ответа на backend.
Далёкий хостинг и TLS съедают сетевую часть, тяжёлые SQL-запросы и шаблоны без кэша — серверную.
CDN и edge-кэш сокращают дорогу, кэш приложения и оптимизация запросов — генерацию; цель до 200 мс.
Показатель складывается из трёх частей: время установки соединения, время обработки запроса на сервере и время передачи первого байта. Разобрать их помогает вкладка сети в инструментах разработчика: там видно, где именно уходят миллисекунды. Чаще всего виновата генерация страницы без кэша, реже — медленный ответ базы данных или сторонний сервис в цепочке.
Лечится в понятном порядке: кэширование готовых страниц, вынос статики на отдельную раздачу, ускорение запросов к базе, ближайший к аудитории дата-центр. Каждая сотня миллисекунд здесь входит в LCP целиком, поэтому ускорение сервера улучшает и метрики скорости, и удобство для людей.
Частые вопросы
Какое значение считается хорошим?
До 200 миллисекунд — отличный результат, до 800 — приемлемый, выше секунды — повод разбираться с хостингом и генерацией страниц. Смотреть нужно на живых пользователях: тест с быстрого канала приукрашивает картину.
Как уменьшить время ответа сервера?
Включить кэширование готовых страниц, ускорить тяжёлые запросы к базе, убрать синхронные обращения к сторонним сервисам при рендеринге и приблизить сервер к аудитории. Для статичных разделов помогает раздача через сеть доставки контента.
Влияет ли этот показатель на позиции напрямую?
Отдельным фактором ранжирования он не считается, зато входит в метрики скорости, которые учитываются. Медленный ответ сервера ещё и ограничивает скорость обхода: робот успевает загрузить меньше страниц за то же время.
Почему показатель скачет в разных проверках?
Он зависит от географии, канала и загруженности сервера в момент запроса. Поэтому ориентируются на распределение по реальным пользователям, а единичные замеры используют для поиска узких мест.