TTFB: что такое time to first byte, норма и как снизить

TTFB (time to first byte) — время от начала навигации до первого байта HTML-ответа. Google на web.dev называет хорошим значение 0,8 секунды и меньше, а плохим — больше 1,8 секунды, при измерении на 75-м процентиле реальных визитов (web.dev, последнее обновление ноябрь 2025). TTFB не входит в Core Web Vitals, но любая следующая метрика, включая First Contentful Paint и Largest Contentful Paint, начинается только после него. На телефонах здесь складываются редиректы, DNS, TLS и медленный сервер, потому что каждый из этих шагов стоит как минимум одной поездки по мобильной сети.

Что такое time to first byte

TTFB — сумма всех шагов до прихода первого байта документа, включая редиректы, DNS и TLS. По данным web.dev, в него входят:

• время редиректов;
• запуск service worker, если он есть на сайте;
• DNS-запрос;
• соединение и согласование TLS;
• сам запрос, вплоть до первого байта ответа.

Поэтому даже быстрый сервер может показывать медленный TTFB. Визит, который начинается с http://example.com, перенаправляется на https://example.com, а потом на https://www.example.com, заплатил за два редиректа и три соединения, а сервер итоговой страницы ещё ничего не сделал.

TTFB не то же самое, что «время ответа сервера» в старых отчётах Lighthouse. Этот аудит измерял только ожидание основного документа и не учитывал DNS-запросы и редиректы, то есть это одна из частей TTFB (Chrome for Developers).

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

Хороший TTFB — 0,8 секунды или меньше, а сами пороги web.dev называет «a rough guide» (ориентиром), а не требованием. Вот диапазоны на ноябрь 2025 года и более строгое значение Lighthouse:

Эти два числа измеряют разное. 600 мс в Lighthouse относятся к времени ответа самого сервера, а ориентир 0,8 с — ко всему TTFB, так что одна и та же страница может пройти по одному и не пройти по другому. Оба порога — проектные решения Google.

Как часто на телефонах получается хороший результат? В Web Almanac 2025 от HTTP Archive, по данным за июль 2025 года, хороший TTFB был у 44% мобильных сайтов против 55% на десктопе. На мобильных 40% нуждались в улучшении, а 17% были плохими (Web Almanac 2025, Performance).

Почему на телефонах TTFB выше

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

1. DNS-запрос, чтобы узнать адрес сервера.
2. Рукопожатие TCP: один обмен с сервером.
3. Рукопожатие TLS: ещё один обмен при TLS 1.3, который RFC 8446 описывает как «1-RTT handshake».
4. HTTP-запрос и первый байт ответа: один обмен плюс время, которое нужно вашему серверу.

Выходит, одна только сеть стоит три обмена с вашим сервером плюс DNS-запрос, ещё до работы самого сервера. В таблице ниже — арифметика с двумя значениями времени обмена туда и обратно (RTT), выбранными для примера, а не измерения какой-либо сети:

При большем RTT сервер, отвечающий за 400 мс, уже нарушает ориентир 0,8 с, как только добавляется DNS. Сервер ничего не сделал неправильно: установка соединения съела больше половины бюджета.

Эти потери уменьшают две вещи. Переиспользуйте соединение: вернувшийся посетитель, который всё ещё подключён, пропускает шаги с 1 по 3. И берите более новый протокол: HTTP/3 работает поверх QUIC, чьё рукопожатие «объединяет согласование криптографических и транспортных параметров» («combines negotiation of cryptographic and transport parameters», RFC 9000, май 2021), поэтому на установку нужно меньше обменов, чем у TCP с последующим TLS. Web.dev отмечает, что CDN отдают содержимое по современным протоколам вроде HTTP/2 или HTTP/3 (web.dev).

Есть и ещё одна причина, характерная для мобильных: отдельный мобильный сайт. В собственном совете Lighthouse по редиректам сказано, что для мобильных пользователей стоит рассмотреть адаптивный дизайн вместо перенаправления на мобильную страницу (Chrome for Developers). Адаптивный подход разобран в статье как сделать сайт удобным на телефоне.

Как измерить TTFB

Измеряйте TTFB дважды: в лабораторных условиях, чтобы понять, куда уходит время, и в поле, чтобы увидеть, что получают настоящие телефоны. Эти два числа могут отличаться: лабораторный запуск — одна загрузка на одной машине, а полевое значение — 75-й процентиль реальных визитов.

В DevTools (лабораторные условия) откройте панель Network, перезагрузите страницу, выберите первый запрос (документ) и откройте вкладку Timing. Фазы называются Queueing, Stalled, DNS Lookup, Initial connection, Request sent и Waiting (TTFB), а «Waiting (TTFB)» — это один обмен плюс время, нужное серверу на подготовку ответа (справочник Chrome DevTools). Если полоса Initial connection длинная, а Waiting короткая, чинить надо установку соединения, а не приложение.

На странице (поле) библиотека web-vitals сообщает TTFB, а в сборке attribution разбивает его на те же фазы. В её документации (web-vitals README) они названы waitingDuration (редиректы и работа браузера до запроса), cacheDuration (проверка кэша плюс время service worker), dnsDuration, connectionDuration и requestDuration (время сети и обработка на сервере):

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // Отправьте в свою аналитику; здесь мы просто выводим разбивку в консоль.
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

В разрезе устройств (поле, без кода) API Chrome UX Report принимает formFactor со значениями PHONE, TABLET или DESKTOP и возвращает 75-й процентиль для experimental_time_to_first_byte (экспериментальная метрика API) (документация CrUX API). Данные — скользящее среднее за 28 дней. Это самый быстрый способ узнать, хуже ли TTFB на телефонах, чем на десктопе. Как запускать более широкий набор тестов скорости, описано в руководстве по тесту скорости мобильной страницы, а как ту же проблему показывает Lighthouse — в руководстве по мобильному аудиту Lighthouse.

На сервере добавьте заголовок Server-Timing, чтобы увидеть, какой шаг бэкенда медленный. Его поддерживают Chrome 65, Firefox 61 и Safari 16.4 (MDN browser-compat-data 8.1.7, октябрь 2026):

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

Значения после этого появляются на вкладке Timing панели Network и в navigationEntry.serverTiming в объекте attribution выше.

Как снизить TTFB

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

Исправления ниже следуют руководству web.dev по оптимизации TTFB (web.dev, обновлено в ноябре 2025).

1. Уберите редиректы. Web.dev советует убрать редиректы 301 и 302 в пределах одного origin, например из-за пропущенного https:// или несовпадения косой черты в конце адреса, а рекламодателям и в рассылки давать итоговый URL. HSTS указывает браузеру сразу использовать https://, а не сначала запрашивать http://.
2. Поставьте перед сайтом CDN. CDN отвечает с пограничного сервера рядом с посетителем, и это сокращает каждый обмен в таблице выше. По данным web.dev, обычно он ещё приносит HTTP/3, TLS 1.3 и сжатие.
3. Кэшируйте HTML. Страницу, одинаковую для всех посетителей, можно кэшировать через Cache-Control и отдавать, не обращаясь к приложению. Web.dev отмечает, что даже короткое время кэширования помогает нагруженным сайтам. Добавьте параметр URL, чтобы обойти кэш при диагностике.
4. Сократите работу сервера. Рекомендация Lighthouse: оптимизировать логику приложения и запросы к базе данных, при необходимости обновить железо и использовать CDN для документов, которые можно кэшировать на границе сети. Сначала найдите медленный шаг с помощью Server-Timing.
5. Сжимайте текст. Insight Lighthouse отмечает основной документ, отправленный без сжатия. Браузер сообщает, что он принимает, в Accept-Encoding, а сервер отвечает заголовком Content-Encoding.
6. Отдавайте HTML потоком. Web.dev советует не прерывать поток ответа: по возможности использовать потоковый серверный рендеринг или статический, чтобы первые байты уходили рано. Ранняя отправка тоже засчитывается как responseStart, так что TTFB может выглядеть лучше, чем ощущается страница; проверяйте и First Contentful Paint.
7. Отправьте 103 Early Hints. Если серверу нужно время на сборку страницы, он может сначала отправить ответ 103 с заголовками Link, и браузер начнёт preconnect или preload, пока ждёт.

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

Early Hints в большинстве браузеров работает по HTTP/2 и новее, а обрабатывается только первый ответ 103 (MDN, июнь 2026). Поддержка начинается с Chrome 103, Firefox 120 и Safari 17. Ответ 103 считается первыми байтами для TTFB, а Chrome менял то, какую отметку времени сообщает responseStart (итоговый ответ в Chrome 115, обратно к первым байтам в Chrome 133), поэтому сравнивать TTFB между инструментами нужно осторожно (web.dev).

Если на сайте есть service worker, отдача оболочки из его кэша тоже сокращает TTFB при повторных визитах. Web.dev предлагает stale-while-revalidate для редко меняющихся ресурсов и network-first для персонализированного HTML.

Статические сайты и сайты на CMS

У статического сайта уже лучший случай: HTML существует до запроса, так что TTFB в основном состоит из установки соединения, и главное решение — CDN. CMS собирает страницу по запросу, поэтому самый большой выигрыш даёт кэширование страниц целиком. Для WordPress в документации Lighthouse перечислены лёгкая тема, кэширование страниц целиком и меньше плагинов; для Drupal — кэширование страниц, PHP OPcache и Redis или Memcached; для Magento — Varnish (Chrome for Developers, последнее обновление 2019, до Lighthouse 13).

Отдельный URL AMP добавляет ещё одну версию страницы, которую нужно держать согласованной с канонической; нужен ли он до сих пор, разобрано в статье AMP в 2026.

Проверьте цепочку редиректов на ширине телефона

Редиректы — единственная причина высокого TTFB, которую видно без секундомера: телефон могут отправить не туда, куда десктоп. Mobile View Extension перезагружает вкладку с user agent, размером экрана и pixel ratio телефона, так что можно проверить, на какой URL вы попадаете и загружается ли мобильная страница как настоящая мобильная версия. TTFB и другие метрики скорости расширение не измеряет, а работает на вашем десктопном соединении и железе, поэтому для замеров времени на настоящих телефонах используйте полевые инструменты выше.

Частые вопросы

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

Хороший TTFB — 0,8 секунды или меньше на 75-м процентиле, а всё выше 1,8 секунды — плохо, по данным web.dev (ноябрь 2025). Это ориентиры, и TTFB не входит в Core Web Vitals.

Входит ли TTFB в Core Web Vitals?

Нет. Core Web Vitals — это Largest Contentful Paint, Interaction to Next Paint и Cumulative Layout Shift, и web.dev прямо пишет, что TTFB среди них нет. Он важен, потому что высокий TTFB задерживает First Contentful Paint и Largest Contentful Paint.

Почему мой TTFB в Lighthouse и в полевых данных разный?

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

Влияет ли TTFB на SEO?

Web.dev пишет, что TTFB не входит в Core Web Vitals, но идёт перед First Contentful Paint, поэтому медленный TTFB задерживает следующие за ним метрики, в первую очередь Largest Contentful Paint. Сначала исправляйте эти метрики, а TTFB используйте, чтобы выяснить, почему они медленные.