Нажали на ссылку, а браузер думает. Не грузит страницу, не показывает индикатор, просто белый экран и ожидание. Это не скорость интернета и не тормозной JavaScript. Это TTFB: время, за которое сервер отвечает на самый первый запрос.

TTFB определяет, когда пользователь вообще увидит хоть что-то на экране. Медленный TTFB, и посетитель уходит на этапе, когда ваш сайт ещё даже не начал отрисовываться. А Google с 2025 года включает серверную отзывчивость в сигналы ранжирования Core Web Vitals.

Ниже, что такое TTFB на самом деле, из каких четырёх компонентов он складывается и как довести его до уровня, при котором сайт отдаёт первый байт быстрее, чем пользователь моргает.

💡 Быстрый обзор:

• Разберитесь, что такое TTFB и почему каждая секунда этой задержки умножается на каждое действие посетителя.
• Пройдите по цепочке из четырёх факторов: DNS, сервер, плагины WordPress и кеширование HTML.
• Сравните четыре сценария на реальных замерах Pingdom, от 150 мс до катастрофических 4,2 секунды.
• Включите кеширование HTML и увидите, как один плагин снижает TTFB в разы без замены хостинга.

Что такое TTFB и почему он влияет на всё

Формальное определение из Wikipedia: TTFB, это время от отправки HTTP-запроса до получения первого байта ответа браузером клиента. В него входят задержка сокетного соединения, время пересылки запроса и время обработки на сервере.

Если сказать проще: TTFB, это пауза между «перейти по ссылке» и «на сайте что-то начало происходить». В игровых терминах, latency, пинг, задержка до первого отклика. Пользователь не видит ни заголовка, ни меню, ни спиннера, только пустую вкладку. И чем дольше эта пауза, тем выше шанс, что вкладку закроют.

Важный нюанс: TTFB влияет не только на первую загрузку. Каждый внутренний переход, каждое нажатие на ссылку в меню, каждый клик по картинке внутри поста, всё это отдельный HTTP-запрос со своим TTFB. Плохой показатель умножается на каждое действие читателя.

Четыре фактора, из которых складывается TTFB

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

DNS: первый рубеж

Браузер не знает, где физически находится ваш сервер, пока DNS не преобразует домен в IP-адрес. Хорошие DNS-серверы с распределённой сетью узлов делают это за миллисекунды, плохие, добавляют десятки и сотни миллисекунд к каждой загрузке.

Практический минимум: использование Cloudflare или аналогичного сервиса с глобальным кешированием DNS. После первого запроса адрес остаётся в кеше, и для повторных обращений DNS-задержка исчезает полностью.

Сервер и PHP: что происходит на хостинге

Каждый запрос к некэшированной странице WordPress запускает интерпретатор PHP. Сервер загружает ядро, тему и активные плагины, исполняет их код и только потом отдаёт HTML. Современные версии PHP обрабатывают этот цикл в разы быстрее, чем выпуски десятилетней давности, не говоря уже о полностью устаревших ветках.

Два параметра хостинга определяют скорость: версия PHP и процессорное время, выделенное вашему тарифу. Дешёвый shared-хостинг с десятками сайтов на одном сервере и устаревшим PHP, гарантированный путь к TTFB > 1 секунды. Специализированный WordPress-хостинг с PHP 8.2+ и встроенным кешированием на уровне сервера даёт принципиально другие цифры.

Плагины и тема WordPress

WordPress собирает страницу из десятков PHP-файлов, и каждый активный плагин добавляет свой код в этот процесс. Десять качественных плагинов от известных разработчиков могут почти не влиять на TTFB. Один плохо написанный плагин, который на каждом запросе делает три лишних запроса к базе данных, способен уронить скорость всего сайта.

Вот пример разумного набора плагинов, всё необходимое, ничего лишнего:

А это уже потенциально проблемная конфигурация. Несколько десятков активных плагинов, и серверу приходится обрабатывать каждый из них при формировании страницы:

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

Кеширование HTML: главный рычаг

Самый мощный фактор из всех. Плагин кеширования, такой как плагин Cache Enabler, сохраняет готовые HTML-копии страниц на диске сервера. Когда приходит запрос, веб-сервер отдаёт статический файл, минуя весь стек PHP и WordPress.

Результат: серверу больше не нужно загружать ядро, тему и плагины для каждого посетителя. Только сам веб-сервер (nginx или Apache) обслуживает контент напрямую. Именно поэтому кеширование даёт самое значительное снижение TTFB, в разы, а не на проценты. Подробнее о том, почему nginx эффективнее Apache для этой задачи, разбирали в отдельной статье.

TTFB на практике: четыре сценария

Перейдём к реальным замерам. Ниже, результаты тестов на разных комбинациях сайта и сервера, полученные через Pingdom Tools. Каждый сценарий показывает TTFB для некэшированной и кэшированной версий.

Медленный сайт на медленном сервере

Худшая из возможных комбинаций: сайт с десятками плагинов и без кеширования на старом shared-хостинге с PHP 5.4.

Раскроем детали первого запроса, видно, что сервер думает целую вечность:

TTFB составляет 4,2 секунды. Четыре секунды пользователь смотрит на пустой экран, прежде чем браузер получит хоть какие-то данные. Добавьте к этому время рендеринга страницы, и общее ожидание до готовности сайта легко достигает семи секунд. Cloudflare на входе здесь уже не помогает: проблема глубже, на уровне хостинга и кода сайта.

Быстрый сайт на среднем сервере

Меняем условия: сайт с минимумом плагинов, сервер на Apache с рядовой версией PHP, без кеширования.

Результат, 521 мс. Уже в 8 раз лучше, чем в первом сценарии. Полсекунды до первого байта, приемлемо для большинства сайтов. Теперь включаем кеширование:

TTFB падает до 152 мс. Даже средний хостинг с правильно настроенным кешированием выдаёт отличный результат.

Медленный сайт на быстром сервере

Обратная ситуация: оптимизированный сервер на Plesk с nginx и рядовой версией PHP, но сайт раздут плагинами.

Без кеша быстрый сервер всё равно тратит 1,29 секунды на обработку тяжёлого сайта. Хороший хостинг смягчает, но не решает проблему плохо оптимизированного WordPress.

Включаем кеширование, TTFB снижается до 400 мс. Разница более чем втрое.

Быстрый сайт на быстром сервере

Оптимальный сценарий: лёгкий сайт на хорошем хостинге.

Без кеша сервер отдаёт первый байт менее чем за 500 мс. Добавляем кеширование:

Результат, менее 150 мс. Практически мгновенный отклик.

Сводка результатов

Все четыре сценария на одном графике:

Вывод из этих замеров прямой: хостинг важен, но то, что вы делаете с самим сайтом, влияет на TTFB сильнее. Быстрый сервер с кешированием вытягивает даже проблемный сайт до приемлемых 400 мс, а медленный сервер без кеша топит даже лёгкий WordPress.

Как улучшить TTFB: пошаговый план

Оптимизация идёт от простого к сложному, от того, что делается за пять минут и даёт максимальный эффект, к более тонким настройкам.

Шаг 1: включите кеширование HTML. Установите бесплатный Cache Enabler или аналогичный плагин кеширования. Это одна операция, которая снижает TTFB в разы на любом хостинге. Без преувеличения, самый высокий возврат на минуту усилий во всей оптимизации WordPress.

Шаг 2: проверьте версию PHP. В админке хостинга или в cPanel найдите настройку версии PHP. Если доступна актуальная версия (8.2 или новее), переключите. Переход с устаревшей ветки на современную заметно ускоряет обработку каждого запроса. Перед переключением убедитесь, что тема и все плагины совместимы с выбранной версией.

Шаг 3: проведите аудит плагинов. Отключите всё, что не используется прямо сейчас. Оставьте только те плагины, которые решают конкретную задачу. Остальное, удалите, а не просто деактивируйте. Плагины «на вырост» и «возможно пригодится» добавляют код в каждый запрос независимо от того, пользуетесь вы ими или нет.

Шаг 4: выберите быструю тему. Тема определяет, сколько PHP-кода исполняется при каждой загрузке. Тяжёлые темы с визуальными конструкторами страниц генерируют значительно больше серверной работы, чем минималистичные решения. Если тест TTFB на чистой установке WordPress (без плагинов и со стандартной темой) показывает хороший результат, а после включения вашей темы показатель резко ухудшается, проблема именно в теме.

Шаг 5: оцените хостинг. Если после первых четырёх шагов TTFB всё ещё превышает 500-800 мс, ограничение на стороне хостинга. Специализированный WordPress-хостинг с nginx, PHP 8.2+ и серверным кешированием даёт принципиально другой уровень отклика. При выборе обращайте внимание на наличие встроенного объектного кеширования (Redis или Memcached), это следующий уровень после кеширования HTML.

Видео: TTFB от теории к результату

Посмотрите наглядный разбор TTFB с живыми замерами до и после оптимизации:

⁉️🤔 Частые вопросы

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

Ориентируйтесь на целевые значения Google Core Web Vitals: до 800 мс, приемлемо, до 500 мс, хорошо, до 200 мс, отлично. На практике для сайта на WordPress с кешированием достижимый диапазон, 100-400 мс. Без кеширования даже быстрый сайт редко опускается ниже 400-500 мс.

Обязательно ли менять хостинг для улучшения TTFB?

Не всегда. Кеширование HTML снижает TTFB в разы даже на среднем хостинге. Прежде чем переезжать, включите кеширование, обновите PHP до актуальной версии и почистите плагины. Если после этого TTFB всё ещё выше 800 мс, хостинг действительно пора менять.

Почему TTFB скачет от замера к замеру?

На TTFB влияет загрузка процессора сервера в момент замера, сетевые задержки и география тестового сервера. Делайте серию из 5-7 замеров и берите медиану, а не первое попавшееся значение. Тестируйте с нескольких локаций, сервер в Европе может показывать отличный TTFB из Франкфурта, но плохой из Токио.

Влияет ли TTFB на позиции в Google?

Да, начиная с 2025 года серверная отзывчивость входит в Core Web Vitals как сигнал ранжирования. Прямое влияние умеренное, но косвенное, значительное: высокий TTFB увеличивает показатель отказов, а высокий процент отказов уже напрямую роняет позиции.

Можно ли измерить TTFB бесплатно?

Да. Используйте Pingdom Tools, GTmetrix, PageSpeed Insights или WebPageTest. Важный нюанс: измеряйте именно TTFB (время до первого байта), а не общее время загрузки страницы. В Pingdom для этого нужно раскрыть детали первого запроса к сайту.

Что делать с TTFB прямо сейчас

Главный вывод из замеров выше: кеширование HTML, самый мощный и самый простой рычаг. Один плагин снижает TTFB в разы на любом хостинге, и это занимает ровно пять минут.

Порядок действий такой:

• Если TTFB > 1 секунды, начните с кеширования и обновления PHP. Эти два шага дают основную часть возможного улучшения.
• Если TTFB между 400 и 800 мс, аудит плагинов и темы обычно убирает оставшуюся задержку.
• Если TTFB стабильно ниже 200 мс, вы в оптимальной зоне, поддерживайте текущий уровень.

Начните с бесплатного плагина кеширования: установите, активируйте и сделайте замер через Pingdom Tools. Разница будет видна сразу. А какой у вас TTFB сейчас, поделитесь цифрами в комментариях.