Time-to-First-Byte (TTFB)

Что это

Time-to-First-Byte (TTFB) — время от момента отправки HTTP-запроса браузером до получения первого байта ответа от сервера. Метрика измеряется в миллисекундах и отражает суммарные задержки: DNS-резолюцию, TCP-соединение, TLS-рукопожатие и время обработки запроса на сервере. Чем выше TTFB, тем позже браузер начинает получать HTML и строить страницу.

---

Почему это важно для SEO

TTFB напрямую влияет на Largest Contentful Paint (LCP) — ключевую метрику Core Web Vitals Google. Если TTFB превышает 800 мс, LCP почти гарантированно выйдет за пределы 2,5 секунды даже при идеально оптимизированном фронтенде. Google официально включил TTFB в документацию по Web Vitals как «корневую причину» медленного LCP. В 2024 году данные Ahrefs по 900 000 страниц показали корреляцию: страницы с TTFB до 200 мс в среднем занимают позиции на 15-20% выше, чем аналоги с TTFB 800+ мс при прочих равных.

Для Яндекса медленный TTFB ухудшает скорость индексации: Яндекс.Бот ограничивает частоту обходов сайта, если сервер долго отвечает. В Яндекс.Вебмастере это видно в разделе «Индексирование» — снижение частоты сканирования при нагрузке на сервер. Кроме того, Турбо-страницы Яндекса частично решают проблему для мобильного трафика, но основной сайт всё равно проигрывает конкурентам с быстрым сервером в органической выдаче.

---

Как проверить вручную

1. PageSpeed Insights (pagespeed.web.dev) — вставьте URL, в разделе «Диагностика» найдите пункт «Время ответа сервера (TTFB)». Норма по Google: до 800 мс, цель — до 200 мс.

1. Chrome DevTools — откройте вкладку Network, перезагрузите страницу (Ctrl+Shift+R), кликните на первый запрос к домену. Во вкладке Timing найдите строку «Waiting for server response» — это и есть TTFB.

1. Screaming Frog — в меню Reports > Response Codes выгрузите все URL. В колонке Response Time увидите TTFB для каждой страницы. Отфильтруйте значения выше 500 мс — это приоритет для оптимизации.

1. Google Search Console — раздел «Основные показатели» покажет страницы с плохим LCP. Большинство из них, как правило, имеют высокий TTFB — проверяйте через DevTools точечно.

1. Яндекс.Вебмастер — раздел «Индексирование > Статистика обхода». Если время ответа стабильно выше 1 секунды, бот снижает частоту обходов.

---

Как исправить

Шаг 1. Включите серверное кэширование.

Для WordPress с плагином WP Rocket:

// wp-config.php
define('WP_CACHE', true);

В настройках WP Rocket включите «Page Caching» и «Cache Preloading».

Для 1C-Bitrix — в настройках компонента выберите «Управляемое кэширование», выставьте TTL от 3600 секунд для статичных страниц.

Для Tilda — TTFB практически не регулируется на уровне платформы: Tilda использует собственный CDN. Если TTFB стабильно выше 600 мс, рассмотрите перенос критичных страниц.

Для Webflow — подключите Cloudflare в режиме Proxy (оранжевое облако) с правилом кэширования для HTML: Cache-Control s-maxage=3600.

Шаг 2. Подключите CDN с edge-кэшированием.

Cloudflare (бесплатный план) снижает TTFB для статики на 40-70%, кэшируя ответы на ближайшем узле. Для динамического контента используйте Cloudflare Workers или Argo Smart Routing.

Шаг 3. Настройте HTTP-заголовок кэширования на сервере.

# nginx.conf
location ~* \.(html)$ {
    add_header Cache-Control "public, max-age=3600, s-maxage=3600";
    add_header X-Cache-Status $upstream_cache_status;
}

Шаг 4. Переведите сервер на PHP-FPM + OPcache, если используете PHP. OPcache кэширует скомпилированный байт-код и сокращает время генерации страницы на 30-50%.

; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000

Шаг 5. Проверьте базу данных. Медленные SQL-запросы — частая причина высокого TTFB. В MySQL включите slow query log:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

---

Типичные ошибки

• Кэшировать только статику, игнорируя HTML. Большинство CMS по умолчанию не кэшируют HTML-страницы. Именно генерация HTML даёт 80% TTFB.
• Не разделять TTFB хоста и CDN. Cloudflare может показывать быстрый TTFB (50 мс), а origin-сервер отвечать за 2 секунды. Проверяйте заголовок CF-Cache-Status: HIT/MISS.
• Включать кэш на страницах с персонализацией. Кэшированная страница корзины или личного кабинета отдаст чужие данные. Исключайте такие URL в настройках кэша.
• Не учитывать регион сервера. Если сервер в Европе, а аудитория в России — TTFB вырастет на 100-200 мс только из-за физического расстояния. Используйте CDN с точками присутствия в Москве и Санкт-Петербурге (Cloudflare, G-Core Labs).
• Игнорировать TTFB на мобильных устройствах. PageSpeed Insights измеряет мобильный и десктопный TTFB отдельно. На мобиле он обычно хуже из-за сетевых задержек.

---

Влияние на разные типы сайтов

Для интернет-магазинов TTFB критичен на страницах каталога и карточек товаров — именно они генерируются динамически из базы данных. Интернет-магазин на 1C-Bitrix с 50 000 SKU без OPcache и кэша может выдавать TTFB 1,5-3 секунды. Ускорение до 200 мс напрямую улучшает конверсию: по данным Cloudflare, каждые 100 мс снижения TTFB дают +1% к конверсии в e-commerce.

Для контентных сайтов и блогов на WordPress TTFB решается проще: страницы статичны, достаточно страничного кэша. SaaS-продуктам и лендингам нужно отдельно отслеживать TTFB для лендингов (часто кэшируется хорошо) и API-эндпоинтов (не кэшируются, требуют оптимизации кода). Лендинги на Tilda с TTFB выше 600 мс стоит дублировать на быстром хостинге для SEO-трафика, оставив Tilda для CRO-тестов.