TTFB (Time to First Byte) — это интервал между отправкой HTTP-запроса и приходом самого первого байта ответа от сервера. Показатель складывается из времени на DNS-запрос, установку TCP-соединения, TLS-рукопожатие и обработку запроса на бэкенде. Что это значит на практике: пока первый байт не дошёл, браузер не может начать рендеринг, и вся загрузка страницы стоит на паузе.
Время отклика сервера напрямую задаёт нижнюю границу для остальных метрик скорости. Google относит серверную задержку к диагностическим сигналам Core Web Vitals: если бэкенд отвечает медленно, пострадает и LCP. Ориентир из документации Google — держать значение до 800 мс на 75-м перцентиле реальных пользователей. Замерить можно в PageSpeed Insights, вкладке Network в DevTools или через поле server response time в CrUX.
§ 01Что показывает
Задержка первого байта отражает скорость работы серверной части: как быстро веб-сервер, база данных и приложение готовят ответ. В структуру метрики входят DNS lookup, TCP handshake, TLS-соединение и Time to First Byte самого документа. Высокое значение указывает не на тяжёлую вёрстку, а на проблемы бэкенда: медленные SQL-запросы, отсутствие кеша, перегруженный хостинг или далёкий от пользователя дата-центр. Отличается от FCP и LCP тем, что измеряет момент до начала рендеринга, а не отрисовку контента.
§ 02Какие значения считаются нормой
По ориентирам Google скорость отклика сервера делится на три зоны: до 800 мс — хорошо, от 800 до 1800 мс — требует внимания, выше 1800 мс — плохо. Оценка берётся по 75-му перцентилю полевых данных, то есть по реальным визитам, а не по одному лабораторному замеру. Для статических страниц на CDN нормой считаются значения в пределах 100-200 мс. Динамические страницы с обращением к базе данных естественно медленнее, поэтому кеширование ответа сдвигает показатель в зелёную зону.
TTFB 820→190 мс — Интернет-магазин косметики на Shopify Plus вынес рендер в edge-кэш Cloudflare и включил early hints. TTFB упал с 820 до 190 мс за 4 недели, LCP -1.1 c. Замер через PSI и CrUX-75th, отказы снизились на 9%.
TTFB 640→240 мс — B2B SaaS-платформа для HR с MRR около $180k переписала тяжёлые SQL-запросы дашборда и добавила Redis-кэш ответов API. TTFB сервера упал с 640 до 240 мс за 7 недель. Динамика по WebPageTest и логам Grafana APM.
§ 03Как измерить
Полевые данные по метрике доступны в отчёте CrUX и в PageSpeed Insights — там значение считается по реальным пользователям Chrome. Для лабораторного замера откройте DevTools, вкладку Network, кликните по основному документу и найдите строку Waiting for server response в разделе Timing. Быстрая проверка через терминал: curl -w %{time_starttransfer} -o /dev/null -s URL выведет время до первого байта в секундах. Разовый замер искажают холодный кеш, география тестового сервера и текущая нагрузка — поэтому опираться стоит на полевую статистику.
§ 04Что делать с плохим значением
Первый шаг при высоком времени ответа сервера — включить серверное кеширование готовых HTML-ответов, чтобы бэкенд не пересобирал страницу на каждый запрос. Дальше по порядку влияния:
- подключить CDN, чтобы контент отдавался с ближайшего к пользователю узла;
- оптимизировать медленные запросы к базе данных и добавить индексы;
- перейти с HTTP/1.1 на HTTP/2 или HTTP/3 для ускорения соединения;
- вынести тяжёлую логику в фоновые задачи вместо обработки в момент запроса.
После правок замер повторяют через несколько недель — полевые данные CrUX обновляются с задержкой.