TTFB: время ответа сервера и как его ускорить

Загрузка страницы начинается не с картинок и скриптов, а с того, как быстро сервер вообще отзовётся. Этот первый барьер называют TTFB — время до первого байта. Если сервер «думает» долго, тормозит вся страница, страдают поведенческие факторы и метрики скорости, которые учитывают поисковики. Разберём, что такое TTFB, какой показатель считать хорошим, из чего он складывается и чем его уменьшить.

Что такое TTFB

TTFB (от англ. Time To First Byte) — это время от момента, когда браузер отправил запрос, до момента, когда от сервера пришёл первый байт ответа. Проще говоря, это пауза между «браузер постучался» и «сервер начал отвечать». Только после первого байта браузер начинает получать и рисовать страницу — поэтому большой TTFB задерживает абсолютно всё, что идёт дальше.

TTFB включает все эти этапы. Чаще всего основная задержка — на этапе обработки на сервере: пока выполняется код, ходят запросы к базе данных, собирается HTML.

Какой TTFB считается хорошим

Ориентиры по времени ответа (для основного документа страницы):

Google в инструментах скорости предупреждает о TTFB выше ~600 мс. Идеал — уложиться в 200 мс. Конкретное значение зависит от хостинга, географии пользователя и сложности страницы, но порядок именно такой.

Почему большой TTFB вредит

• Тормозит всю загрузку. Пока нет первого байта, браузер ничего не рисует. Медленный сервер портит метрику LCP из Core Web Vitals, которую учитывает Google.
• Бьёт по поведенческим. Люди не любят ждать: чем дольше отклик, тем больше уходят, не дождавшись. А отказы — сигнал поисковику, что со страницей что-то не так.
• Замедляет индексацию. Роботу тоже приходится ждать ответа. При медленном сервере он обходит меньше страниц за то же время — страдает краулинговый бюджет.

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

Из чего складывается медленный TTFB

Прежде чем чинить, полезно понять, где теряется время:

• Слабый или перегруженный хостинг — самая частая причина. Дешёвый шаред-хостинг с сотней сайтов на сервере отвечает медленно.
• Тяжёлый бэкенд — неоптимизированный код, медленные запросы к базе данных, отсутствие кэширования: сервер генерирует страницу заново на каждый запрос.
• Нет кэша — динамические страницы собираются с нуля, хотя могли бы отдаваться готовыми.
• География — сервер далеко от пользователя, пакеты идут дольше.
• Медленный DNS и лишние редиректы — добавляют задержку ещё до обработки.

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

TTFB и Core Web Vitals: связь с LCP

TTFB не входит в Core Web Vitals напрямую, но он — фундамент LCP (Largest Contentful Paint, отрисовка главного контента). LCP складывается из нескольких частей, и TTFB — самая первая из них: пока сервер не отдал первый байт, отсчёт остальных этапов даже не начался. Если на хороший LCP отводится ориентир до 2,5 секунды, а сервер «съел» 1 секунду только на TTFB, у браузера остаётся слишком мало времени на загрузку и отрисовку — уложиться почти невозможно. Поэтому оптимизацию скорости часто начинают именно с TTFB: это «бесплатная» секунда, которую можно вернуть на стороне сервера, не трогая фронтенд.

Статика против динамики: почему лендинг быстрее CMS

Огромная разница в TTFB между сайтами объясняется просто. Статическая страница (готовый HTML-файл) отдаётся почти мгновенно — серверу нечего «думать». Динамическая (CMS вроде WordPress или Bitrix) на каждый запрос запускает код, ходит в базу, собирает HTML заново — отсюда задержка. Хорошая новость: динамику можно превратить в статику для робота и пользователя с помощью полностраничного кэша. Первый посетитель инициирует сборку страницы, она сохраняется, и все последующие (включая поискового робота) получают готовый HTML с минимальным TTFB. Поэтому на тяжёлых CMS страничное кэширование — это не опция, а первое, что включают для скорости.

TTFB глазами поискового робота

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

Как измерять TTFB правильно

Одно измерение часто вводит в заблуждение — учитывайте нюансы:

• Холодный и прогретый кэш. Первый запрос после сборки страницы покажет высокий TTFB, повторный — низкий (отдаётся из кэша). Меряйте оба, чтобы понять реальную картину.
• География. Замер из вашего города и из другого региона даст разные числа — сервер дальше, пакеты идут дольше. Проверяйте из целевых регионов.
• Несколько замеров. Один прогон может попасть на случайный всплеск. Сделайте серию и смотрите на типичное значение, а не на единичный выброс.
• Документ, а не вся страница. TTFB относится к основному HTML-документу; не путайте его с временем загрузки всех ресурсов.

Коротко

TTFB — это время от запроса до первого байта ответа сервера, первый барьер скорости. Хорошо — до 200 мс, выше 600 мс — пора чинить. Большой TTFB тормозит загрузку, портит LCP и поведенческие, замедляет индексацию. Складывается он в основном из обработки на сервере: слабый хостинг, тяжёлый код, отсутствие кэша. Лечится нормальным хостингом, кэшированием, CDN, оптимизацией базы данных и уменьшением редиректов. Замерьте время ответа — и если оно большое, начните с хостинга и кэша: обычно это даёт самый заметный эффект.