Медленный TTFB разрушает скорость сайта и позиции. Узнайте как измерить время до первого байта, найти причину задержек и ускорить сервер до целевых 200 мс.
Что такое Time to First Byte и почему он критичен
Time to First Byte (TTFB) — это время, которое проходит между отправкой HTTP-запроса пользователем и получением первого байта ответа от сервера. Проще говоря, это показатель того, насколько быстро ваш сервер реагирует на запрос. Если сервер долго думает, прежде чем начать отдавать страницу, никакая оптимизация на стороне клиента не спасёт ситуацию.
Google рекомендует TTFB не более 200 миллисекунд. Это амбициозный, но достижимый показатель для правильно настроенного сервера с кешированием. При TTFB от 200 до 500 мс требуется улучшение. Значения выше 500 мс считаются проблемными и могут влиять на ранжирование.
TTFB влияет на все последующие метрики скорости. Если сервер тратит 800 мс на обработку запроса, ваш LCP не может быть меньше 800 мс, даже если вся остальная страница загружается мгновенно. TTFB — это фундамент, на котором строится вся производительность сайта.
Как TTFB влияет на SEO и бизнес-показатели
Google напрямую учитывает скорость сервера как фактор ранжирования. Медленный TTFB увеличивает общее время загрузки, что повышает показатель отказов. По данным Google, 53% мобильных пользователей покидают сайт, если загрузка занимает более 3 секунд. Если ваш TTFB составляет 1 секунду, у вас остаётся всего 2 секунды на загрузку и отображение всего контента. Это очень жёсткое ограничение.
Для интернет-магазинов каждая секунда задержки напрямую конвертируется в потерянную выручку. Исследования показывают снижение конверсии на 7% при задержке в 1 секунду и на 20% при задержке в 3 секунды. Для SaaS-компаний задержка снижает количество регистраций. Для медийных сайтов — уменьшает количество просмотров страниц и доход от рекламы.
Мобильные пользователи страдают от высокого TTFB сильнее, чем десктопные. Мобильные сети имеют более высокую латентность и меньшую пропускную способность. Сервер, который отвечает за 200 мс на десктопе, может показать 600 мс на мобильном устройстве из-за сетевых задержек. Google использует mobile-first индексацию, поэтому ваш мобильный TTFB определяет ранжирование для всех устройств.
Технические причины высокого TTFB
Медленный хостинг
Самая распространённая причина. Дешёвый shared-хостинг размещает сотни сайтов на одном сервере. Ресурсы процессора, оперативной памяти и дисковой подсистемы делятся между всеми. Когда соседний сайт получает всплеск трафика, ваш сайт замедляется. Виртуальные серверы (VPS) и выделенные серверы обеспечивают гарантированные ресурсы и стабильный TTFB.
Отсутствие кеширования
Без кеширования каждый запрос обрабатывается с нуля. CMS запускает PHP, делает десятки запросов к базе данных, собирает страницу из шаблонов, плагинов и контента, и только потом отправляет HTML. Этот процесс занимает сотни миллисекунд. При кешировании готовая HTML-страница сохраняется в памяти или на диске и отдаётся мгновенно при повторном запросе.
Географическая удалённость сервера
Скорость света ограничена, и данные не могут передаваться быстрее. Сервер во Франкфурте имеет задержку около 5 мс для пользователей в Германии, 40 мс для Лондона, 150 мс для Нью-Йорка и 300 мс для Сиднея. Если ваша аудитория глобальна, а сервер один, часть пользователей всегда будет получать высокий TTFB из-за физики сетей.
Неоптимизированная база данных
База данных накапливает мусор: ревизии постов, удалённые комментарии, истёкшие транзиенты, логи. Запросы к такой базе выполняются медленнее. Отсутствие индексов на часто запрашиваемых полях увеличивает время ответа в разы.
Устаревшая версия PHP
Каждая новая мажорная версия PHP приносит значительные улучшения производительности. Переход с PHP 7.4 на PHP 8.2 может сократить TTFB на 20-30% только за счёт более эффективного выполнения кода. На устаревших версиях PHP 5.x TTFB в несколько раз выше.
Пошаговое снижение TTFB
- Измерьте текущий TTFB. Используйте несколько инструментов для объективной картины. Chrome DevTools (вкладка Network, столбец Waiting), WebPageTest, KeyCDN Performance Test. Измеряйте с разных географических точек.
- Оцените хостинг. Если TTFB стабильно выше 500 мс даже для кешированных страниц, проблема в сервере. Рассмотрите переход на VPS (DigitalOcean, Linode, Vultr) или облачный хостинг (Google Cloud, AWS). Стоимость начинается от 5-10 долларов в месяц, что ничтожно по сравнению с потерями от медленного сайта.
- Включите серверное кеширование. Настройте Nginx FastCGI Cache, Varnish или LiteSpeed Cache. Для WordPress используйте плагины WP Rocket, Flying Press или W3 Total Cache. Кешированная страница должна отдаваться за 50-100 мс независимо от сложности сайта.
- Подключите CDN. Cloudflare (бесплатный план), BunnyCDN или KeyCDN распределят контент по десяткам дата-центров по всему миру. Пользователи получают данные с ближайшего узла, сокращая сетевую задержку до 10-30 мс.
- Оптимизируйте базу данных. Удалите ревизии, спам, транзиенты. Оптимизируйте таблицы. Добавьте индексы. Для WordPress используйте WP-Optimize. Для кастомных решений проверьте медленные запросы через EXPLAIN и добавьте недостающие индексы.
- Обновите PHP до версии 8.2 или 8.3. Если ваш хостинг не поддерживает современные версии PHP, это дополнительный аргумент для смены хостинга.
- Проверьте результат. Запустите анализатор производительности до и после оптимизации. Инструмент измерит TTFB и покажет точное улучшение в миллисекундах, а также оценит влияние на Core Web Vitals.
Анализ TTFB с помощью инструментов
Инструмент анализа производительности тестирует ваш сайт с нескольких географических локаций и возвращает точные значения TTFB. Отчёт разбивает задержку на составляющие: DNS lookup, TCP connection, TLS handshake и server processing. Вы видите, какой именно этап создаёт задержку.
Если проблема в сетевой задержке из-за географии, отчёт покажет разницу TTFB для разных регионов и порекомендует CDN. Если проблема в обработке запроса, отчёт укажет на необходимость кеширования или оптимизации базы данных. Если проблема в DNS, будет рекомендован переход на более быстрый DNS-провайдер.
После внесения изменений повторный аудит подтверждает улучшения конкретными цифрами. Вы не гадаете, помогло ли изменение. Вы видите точную разницу в миллисекундах.
FAQ
Какой TTFB считается хорошим?
Google рекомендует до 200 мс. На практике до 300 мс — приемлемо для большинства сайтов. Всё что выше 500 мс требует немедленного вмешательства.
Можно ли достичь TTFB 200 мс на дешёвом хостинге?
С кешированием и CDN — возможно для кешированных страниц. Но первый запрос и динамические страницы всё равно будут медленными. Для стабильного TTFB на всех страницах требуется качественный хостинг.
Влияет ли TTFB на Core Web Vitals напрямую?
TTFB не является отдельным Core Web Vital, но напрямую влияет на LCP. Медленный серверный ответ задерживает начало загрузки всех ресурсов страницы, включая LCP-элемент.
Как часто нужно измерять TTFB?
После каждого изменения на сервере: обновления CMS, установки плагинов, миграции, изменения конфигурации. При стабильной работе — ежемесячный мониторинг для раннего обнаружения деградации.
Заключение
TTFB — это фундаментальная метрика, с которой начинается вся производительность сайта. Пока сервер отвечает медленно, никакая оптимизация фронтенда не даст хороших результатов. Регулярное измерение TTFB и своевременное устранение проблем защищает ваши позиции в поиске и доходы бизнеса.