Что такое TTFB простыми словами?

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

Чем измерить время ответа сервера?

Используйте проверку ответа сервера и тест скорости загрузки на raskruty.ru, PageSpeed Insights, а также вкладку «Сеть» (Network) в инструментах разработчика браузера — там TTFB виден для каждого запроса. Для серверов подойдёт и команда curl с выводом таймингов.

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

Медленный ответ сервера тормозит всю загрузку и портит метрику LCP из Core Web Vitals, которую учитывает Google. Долгое ожидание ухудшает поведенческие факторы — люди уходят, не дождавшись. Кроме того, при медленном сервере поисковый робот обходит меньше страниц за то же время, и страдает краулинговый бюджет.

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

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

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

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

Главные шаги: перейти на быстрый хостинг или VPS; включить кэширование страниц и запросов к базе данных; подключить CDN, чтобы отдавать контент с ближайшего узла; оптимизировать базу (индексы, лёгкие запросы); включить сжатие и keep-alive; убрать лишние редиректы. Чаще всего больше всего помогают смена хостинга и кэш.

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

Что такое TTFB

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

🌐

DNS

Браузер узнаёт IP по домену

🤝

Соединение

TCP-рукопожатие с сервером

🔒

TLS

Установка HTTPS-шифрования

⚙️

Обработка

Сервер готовит ответ (код, БД)

📦

Первый байт

Ответ пошёл в браузер

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

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

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

До 200 мс

🟢 Отлично

200–500 мс

🟡 Приемлемо

Больше 600 мс

🔴 Медленно — пора чинить

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

⏱

Замерить время ответа помогут проверка ответа сервера и тест скорости загрузки. TTFB также показывают PageSpeed Insights и вкладка «Сеть» в инструментах разработчика браузера.

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

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

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

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

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

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

🖥 Нормальный хостинг

Перейдите на хостинг/VPS с быстрым ответом. Это часто решает проблему одним шагом.

⚡ Кэширование

Кэшируйте страницы и запросы к БД (страничный кэш, объектный кэш, OPcache). Готовый ответ отдаётся мгновенно.

🌍 CDN

Сеть доставки контента отдаёт страницы с ближайшего к пользователю узла — сокращает сетевую задержку.

🗄 Оптимизация базы

Индексы, лёгкие запросы, удаление мусора в БД — сервер готовит ответ быстрее.

📦 Сжатие и keep-alive

Gzip/Brotli и переиспользование соединений уменьшают накладные расходы.

↩️ Меньше редиректов

Каждый редирект — лишний круг. Уберите цепочки, ведите сразу на конечный URL.

🛠

По теме скорости: как ускорить загрузку сайта, Core Web Vitals, выбор площадки — как выбрать хостинг. Проверить ответ и коды — ответ сервера и статья HTTP-коды ответа.

Коротко

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