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 мс.