Среднее время ответа сервера

Что это

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

---

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

Google официально включил TTFB в цепочку метрик, влияющих на Core Web Vitals: высокий TTFB напрямую ухудшает LCP (Largest Contentful Paint), потому что браузер не может начать рендер до получения первого байта. Порог Google — до 800 мс считается «хорошим», 800–1800 мс — «требует улучшения», свыше 1800 мс — «плохо». Сайты с TTFB выше 1,5 с теряют позиции в конкурентных нишах по данным корреляционных исследований (например, анализ Ahrefs по 3,4 млн страниц показал значимую связь между TTFB и позицией в топ-10).

Яндекс также учитывает скорость загрузки при ранжировании и при расчёте ИКС: медленные сайты хуже удерживают посетителей, что ухудшает поведенческие факторы — глубину просмотра, время на сайте, показатель отказов. Робот Яндекса (YandexBot) при краулинге тратит больше crawl budget на медленные сайты, а значит часть страниц может не попасть в индекс вовремя. Для Турбо-страниц Яндекс дополнительно стимулирует владельцев снижать TTFB основного домена, чтобы обеспечить корректную подгрузку данных.

---

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

1. PageSpeed Insights — введи URL на pagespeed.web.dev, в разделе Diagnostics найди «Reduce initial server response time». Здесь же видно реальное поле CrUX (данные Chrome-пользователей).

1. Google Search Console — раздел «Core Web Vitals» покажет страницы с проблемами LCP, которые часто коренятся в высоком TTFB.

1. Яндекс.Вебмастер — раздел «Индексирование → Страницы в поиске → Скорость загрузки». Там видны проблемные URL по данным робота.

1. Screaming Frog — при краулинге в колонке Response Time фиксирует TTFB для каждого URL. Отфильтруй строки со значением выше 500 мс: Bulk Export → Response Codes → All.

1. Топвизор — в разделе «Аудит» показывает среднее время ответа по всем страницам с разбивкой по кластерам.

1. Браузерный DevTools (Chrome/Firefox): открой вкладку Network, выдели нужный запрос — во Waterfall секция TTFB подписана как «Waiting (TTFB)».

---

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

Шаг 1. Включи серверное кэширование страниц. Генерация HTML «на лету» — самая частая причина высокого TTFB.

WordPress (WP Rocket / W3 Total Cache):

// В wp-config.php для object cache
define('WP_CACHE', true);

Установи WP Rocket → включи «Page Caching» и «Cache Preloading».

1C-Bitrix:

// В .settings.php — включить управляемое кэширование
'cache' => ['type' => 'memcache', 'host' => '127.0.0.1', 'port' => 11211]

В административной панели: Настройки → Производительность → включи композитный сайт.

Tilda: кэш на уровне CDN включается через настройки домена; дополнительно подключи Cloudflare с включённым APO (Automatic Platform Optimization).

Webflow: встроенный CDN Fastly активен по умолчанию, но отключи «Preview mode» на продакшн-домене.

Шаг 2. Переедь на хостинг ближе к аудитории или подключи CDN. Если сервер в Германии, а аудитория в России — только это даёт +200–400 мс TTFB. Варианты: Selectel, Timeweb Cloud, либо Cloudflare / BunnyCDN с точкой присутствия в Москве.

Шаг 3. Оптимизируй базу данных. Медленные SQL-запросы — вторая по частоте причина. Включи slow query log:

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

Проанализируй с помощью mysqldumpslow или Percona Toolkit.

Шаг 4. Настрой HTTP/2 или HTTP/3. Проверь через curl -I https://yourdomain.ru — в заголовке HTTP/ должна быть версия 2 или 3.

---

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

• Замер TTFB без прогрева кэша. Первый «холодный» запрос всегда медленнее — замеряй среднее по 5–10 запросам.
• Игнорирование регионального TTFB. Время ответа из Москвы и из Новосибирска может отличаться в 2 раза — используй Топвизор или WebPageTest с выбором локации.
• Включение тяжёлых плагинов без проверки TTFB. Каждый PHP-плагин добавляет время выполнения; после установки нового плагина всегда перепроверяй Screaming Frog.
• Оптимизация фронтенда вместо бэкенда. Сжатие картинок не снизит TTFB — он формируется до отдачи HTML.
• Отсутствие мониторинга. TTFB деградирует постепенно — настрой алерт в UptimeRobot или Zabbix при превышении порога 600 мс.

---

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

Для интернет-магазинов на 1С-Битрикс или Magento TTFB критичен вдвойне: каждая страница товара генерируется динамически с обращением к БД, а каталог может содержать тысячи URL. Высокий TTFB на фильтрованных URL (например, /catalog/?price=1000-5000) напрямую замедляет краулинг и снижает охват индексирования фасетной навигации.

Для контентных сайтов и SaaS-лендингов TTFB влияет прежде всего на LCP и поведенческие факторы: читатель, открывший статью из поиска, уйдёт обратно раньше, если страница «висит» дольше 2 секунд. По данным Google, с каждым дополнительным секундой задержки вероятность отказа растёт на 32%. Лендинги с одной страницей проще всего закрыть через статическую генерацию (SSG) или Cloudflare Workers — это даёт TTFB менее 100 мс даже без выделенного сервера.