TTFB (Time to First Byte)

Что такое TTFB и откуда он взялся

TTFB (Time to First Byte) — это время, которое проходит с момента, когда браузер отправляет запрос к серверу, и до получения первого байта данных в ответе. Эта метрика появилась вместе с развитием веб-технологий, когда стало очевидно: скорость загрузки страницы зависит не только от объема контента, но и от того, как быстро сервер вообще начинает отвечать. Впервые о TTFB заговорили в контексте производительности веб-приложений, а позже поисковые системы включили его в факторы ранжирования. Сегодня TTFB считается базовым показателем «отзывчивости» сервера, и его значение можно увидеть в таких инструментах, как Google PageSpeed Insights, Lighthouse или WebPageTest.

Если упростить, TTFB — это «задержка перед началом передачи данных». Представьте, что вы звоните в службу поддержки: время от набора номера до ответа оператора — это и есть аналог TTFB. Если оператор молчит слишком долго, вы начинаете нервничать, даже если потом разговор займет меньше минуты. Точно так же и с сайтом: если сервер долго «думает», пользователь уходит, даже если сама страница грузится быстро.

Как TTFB влияет на SEO и разработку

Для SEO TTFB не является прямым фактором ранжирования, но он косвенно влияет на него через пользовательский опыт и метрики поведения. Чем выше TTFB, тем дольше пользователь видит пустой экран или прелоадер. Это увеличивает показатель отказов и снижает время на сайте. В 2010 году Google официально заявил, что скорость загрузки страницы учитывается в алгоритме ранжирования, а в 2018 году — что первая загрузка (FCP) тоже важна. TTFB лежит в основе этих метрик, поэтому его оптимизация обязательна для сайтов, которые претендуют на высокие позиции.

С точки зрения разработки, TTFB — это индикатор эффективности серверной части. Высокий TTFB может сигнализировать о проблемах с хостингом, медленной базе данных, неоптимизированном коде или недостаточном кэшировании. Например, если сайт работает на дешевом shared-хостинге, где на одном сервере сотни других сайтов, TTFB будет нестабильным. Или если на странице генерируется сложный динамический контент без кэша — каждый запрос будет обрабатываться заново, что увеличивает время ответа.

Практический пример: как измерять и интерпретировать TTFB

Допустим, вы открываете сайт в браузере в режиме инкогнито и нажимаете F12 → Network. Вы видите запрос к главной странице, и в колонке Timing виден разбитый TTFB: время на DNS, TCP-соединение, TLS-хендшейк, ожидание ответа сервера. Если общее время больше 600 мс — стоит разбираться. Например, TTFB в 800 мс при том, что сама страница весит всего 100 КБ, говорит о медленной серверной обработке. А если TTFB маленький (100 мс), но общая загрузка долгая — проблема уже в клиентской части: тяжелые скрипты, изображения, CSS.

Еще один пример: интернет-магазин на WordPress с загруженными плагинами. Даже с хорошим хостингом TTFB может быть выше 700 мс из-за большого количества PHP-запросов. После установки плагина кэширования и включения объектного кэша TTFB падает до 200 мс — скорость загрузки страницы растет, позиции в выдаче улучшаются.

Типичная ошибка или заблуждение о TTFB

Самое распространенное заблуждение: «TTFB должен быть меньше 100 мс у всех сайтов». Это не так. Нормальный TTFB зависит от типа сайта и региона пользователя. Для простого лендинга 200 мс — отличный результат, а для крупного интернет-магазина с тяжелой логикой — 500 мс может быть приемлемо. Попытка искусственно занизить TTFB до 50 мс через CDN иногда приводит к тому, что сервер начинает отвечать первым байтом слишком быстро, но содержимое страницы собирается долго — в итоге пользователь ждет столько же.

Другая ошибка — путать TTFB с общей скоростью загрузки. Сайт может иметь отличный TTFB в 150 мс, но если HTML-документ весит 2 МБ без сжатия, пользователь все равно будет долго ждать рендеринга. И наоборот, TTFB в 400 мс при легкой странице может быть незаметен. Поэтому не стоит гнаться за абсолютно минимальным TTFB — важно оценивать его в комплексе с другими метриками.