TTFB

TTFB сайта и время до первого байта

TTFB, или Time to First Byte, показывает время от начала перехода к странице до момента, когда браузер начинает получать первый байт ответа. Для основного HTML документа эта метрика предшествует другим значимым этапам загрузки и помогает понять, где возникает задержка ещё до отображения содержимого страницы.

TTFB часто называют временем ответа сервера, но такое определение упрощает метрику. В измерение могут входить редиректы, поиск DNS, установка соединения, TLS, работа Service Worker и ожидание ответа после отправки запроса. Поэтому высокий TTFB не всегда означает, что проблема находится исключительно в PHP, базе данных или мощности хостинга.

На Vagizov.com TTFB относится к технической оптимизации. Отдельный раздел «Скорость сайта» уже рассматривает производительность страницы в целом, PageSpeed Insights, Core Web Vitals и порядок оптимизации. Здесь фокус находится именно на времени до первого байта, его измерении и диагностике причин задержки.

Что входит в TTFB

Для навигационного запроса TTFB охватывает путь от начала перехода до начала получения ответа. На итоговое значение способны влиять несколько последовательных этапов.

Редиректы

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

Поэтому при диагностике важно проверять не только конечный URL, но и адрес, с которого начинается переход. Лишняя цепочка перенаправлений может увеличивать задержку ещё до обращения к целевой странице.

DNS и соединение

Браузеру необходимо определить адрес сервера и установить соединение. При HTTPS также выполняется TLS согласование.

Задержка на этих этапах зависит от сети, расположения пользователя и сервера, состояния соединения и инфраструктуры. Поэтому одно измерение с компьютера владельца сайта нельзя автоматически считать результатом для всей аудитории.

Обработка запроса

После получения запроса серверу необходимо сформировать ответ. Для динамического сайта это может включать выполнение приложения, обращения к базе данных, работу CMS, плагинов, внешних API и других компонентов.

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

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

web.dev рекомендует рассматривать 0,8 секунды или меньше как ориентир хорошего TTFB. Значения более 1,8 секунды относятся к плохому диапазону, а промежуток между ними требует внимания. Эти значения являются ориентиром, а не универсальной гарантией качества страницы.

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

TTFB не входит в набор Core Web Vitals. В актуальной оценке Core Web Vitals используются LCP, INP и CLS. PageSpeed Insights показывает TTFB среди дополнительных показателей полевых данных.

Как TTFB связан с LCP и скоростью страницы

TTFB и LCP измеряют разные этапы загрузки.

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

После быстрого ответа браузеру всё ещё могут мешать тяжёлое изображение первого экрана, блокирующие стили, шрифты, JavaScript или клиентский рендеринг. Поэтому оптимизация TTFB должна решать именно серверную или сетевую часть проблемы, а не подменять полноценную диагностику скорости сайта.

Как проверить TTFB

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

PageSpeed Insights

PageSpeed Insights использует данные Chrome UX Report для отображения опыта реальных пользователей и Lighthouse для лабораторной диагностики. В полевых данных TTFB показывается отдельно от трёх метрик Core Web Vitals.

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

Chrome DevTools

TTFB можно исследовать через сетевую панель Chrome DevTools. Такой тест помогает увидеть поведение конкретного запроса и сравнить его с другими этапами загрузки.

web.dev относит Network panel Chrome DevTools к лабораторным способам измерения TTFB.

WebPageTest

WebPageTest также используется для лабораторного измерения TTFB. Его преимущество для диагностики состоит в возможности анализировать загрузку страницы как последовательность сетевых запросов и сопоставлять первый ответ с остальными этапами.

Navigation Timing API

В браузере TTFB навигационного запроса можно получать программно через Navigation Timing API. В этом случае значение связывается с моментом начала навигации и началом ответа.

Такой вариант подходит для собственного мониторинга производительности, когда необходимо собирать измерения непосредственно у пользователей и анализировать их вместе с другими показателями.

Почему TTFB бывает высоким

Высокое значение не указывает на одну конкретную причину. Диагностика должна определить, на каком участке возникает ожидание.

Медленное формирование HTML

Динамическая CMS может выполнять значительный объём работы до начала отправки ответа. Причиной могут становиться тяжёлые запросы к базе данных, сложная логика шаблонов, плагины, обращения к внешним сервисам или другие серверные операции.

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

Отсутствие подходящего кэширования

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

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

База данных

Запрос страницы может зависеть от одного или нескольких обращений к базе данных. Медленные запросы, отсутствие подходящих индексов, чрезмерный объём операций или высокая конкурирующая нагрузка способны увеличить время формирования ответа.

Проверять базу следует после локализации проблемы. Сам факт высокого TTFB ещё не доказывает, что источником задержки является именно SQL.

Внешние запросы

Серверное приложение может обращаться к API, сервисам лицензирования, CRM, платёжным системам или другим внешним ресурсам до формирования HTML.

Если ответ страницы синхронно зависит от такого обращения, задержка внешнего сервиса способна увеличивать TTFB основного сайта.

Сервер и нагрузка

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

Однако менять хостинг только на основании одного показателя PageSpeed Insights не стоит. Сначала необходимо сопоставить TTFB с серверными метриками, логами и поведением сайта в разные моменты времени.

География и сеть

Расстояние между пользователем и сервером добавляет сетевую задержку. На результат также влияют DNS, установка соединения и TLS.

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

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

Уменьшение TTFB начинается с определения медленного этапа. Универсальная правка без диагностики может улучшить один тест и не устранить реальную причину.

Уберите ненужные редиректы

Если запрос проходит через промежуточные URL, сначала стоит проверить возможность прямого перехода к конечной странице.

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

Ускорьте серверную генерацию

Если основная задержка появляется после получения запроса сервером, необходимо профилировать приложение.

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

Настройте кэширование

Страничный кэш позволяет в подходящих сценариях отдавать уже подготовленный ответ вместо повторной генерации страницы.

Object cache решает другую задачу и уменьшает количество повторных дорогостоящих операций с объектами и данными. Эти механизмы нельзя считать взаимозаменяемыми.

Проверьте инфраструктуру

Если приложение оптимизировано, но сервер стабильно отвечает медленно под реальной нагрузкой, следует проверять ресурсы, конфигурацию веб сервера, PHP workers, базу данных и расположение инфраструктуры относительно аудитории.

Только после такой проверки можно обоснованно решать, требуется ли изменение тарифа, конфигурации или самого хостинга.

Учитывайте географию пользователей

Для аудитории, находящейся далеко от исходного сервера, часть задержки создаёт сама сеть.

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

Как диагностировать высокий TTFB последовательно

Сначала стоит определить, действительно ли проблема наблюдается у реальных пользователей. Для этого полезны полевые данные, если они доступны.

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

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

Завершать оптимизацию нужно повторным измерением в тех же условиях. Иначе невозможно определить, действительно ли изменение уменьшило задержку или результат отличается из-за случайных условий теста.

TTFB и SEO

TTFB полезен в SEO прежде всего как диагностическая метрика технического состояния и производительности сайта. Он не входит в три Core Web Vitals, поэтому его не следует представлять как отдельный основной интернет показатель или обещать рост позиций только после уменьшения значения.

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

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

Чем TTFB отличается от общей скорости сайта

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

Поэтому оптимизация изображений может значительно улучшить LCP и почти не изменить TTFB. И наоборот, серверное кэширование способно уменьшить время до первого байта, но не исправит тяжёлый JavaScript или неоптимизированное изображение первого экрана.

Раздел TTFB посвящён именно этому начальному этапу загрузки. Общую оценку производительности, Core Web Vitals и работу с PageSpeed Insights логичнее рассматривать в соседнем разделе о скорости сайта, чтобы не смешивать разные метрики и не дублировать существующие материалы Vagizov.com.