TTFB (Time to First Byte) — время от старта навигации до момента, когда в браузер пришёл первый байт ответа документа. В Navigation Timing это responseStart минус startTime. Это не LCP (когда нарисовался основной блок) и не кабинетный отчёт Core Web Vitals: TTFB в тройку стабильных метрик не входит. Как Search Console клеит группы и красит статус по LCP / INP / CLS — Core Web Vitals. Сама отрисовка героя — соседний LCP. Хаб — техническое SEO.
Ориентир web.dev / PSI на 75-м процентиле, мобильные отдельно от компьютера: ≤800 мс — «хорошо», ≤1800 мс — «нужно увеличить скорость», >1800 мс — «плохо». Это грубая шкала: web.dev прямо пишет, что порог не обязателен, если FCP и LCP зелёные. SPA с пустой оболочкой нуждается в низком TTFB сильнее, чем SSR, который может ответить позже, но сразу отдать готовый герой. Яндекс TTFB в Вебмастере не считает; «скорость сайта» там — другая величина (открытия в Яндекс Браузере с мобильной выдачи), отдельный planned URL.
Из каких фаз складывается число
Для запроса HTML TTFB — сумма фаз до первого байта, не «пинг сервера» и не время полной загрузки.
| Фаза | Что входит | Что часто путают |
|---|---|---|
| Редиректы | Каждый 301/302/307/308 до финального документа | Лаборатория по финальному URL их не видит |
| Service Worker | Старт SW, если он перехватывает навигацию | Кэш hit SW может укоротить, холодный старт — удлинить |
| DNS | Резолв имени | Повторный визит с тёплым кэшем DNS почти нулевой |
| Соединение + TLS | TCP, рукопожатие, сертификат | Аудит Lighthouse «Server response time» DNS и TLS не включает |
| Ожидание ответа | Сервер собрал заголовки и отдал первый байт | Не полный HTML и не LCP-картинка |
web.dev раскладывает хороший LCP примерно так: ~40% TTFB, <10% задержка до старта качки LCP-ресурса, ~40% сама качка, <10% отрисовка. Это пропорции, не миллисекунды. Сжать hero и оставить http→https→www→слеш — TTFB съедает бюджет LCP ещё до картинки. Цепочку сжимают до одного 301: соседние цепочки редиректов и HTTPS. HSTS (и preload) убирает повторный http→https после первого визита, не заменяет каноническую ссылку в HTML.
103 Early Hints путает «первый байт». Chrome 115 считал responseStart с финального 200, в Chrome 133 вернули прежнее поведение из‑за несовместимости инструментов. Сравнивать TTFB площадок с и без Early Hints / early flush заголовков можно только если понятно, что именно меряет ваш инструмент.
Поле видит редирект, лаборатория — финальный URL
Поле: верх PSI (CrUX, ~28 дней) и onTTFB из web-vitals. Search Console TTFB не рисует: в отчёте CWV только LCP, INP, CLS. Лаборатория часто открывает уже канонический HTTPS со слешем — без рекламного сокращателя, без http и без www. Тогда полевой TTFB выше лабораторного: виноваты редиректы, география и холодный кэш origin, не «Lighthouse сломался». Обратное (лаборатория хуже поля) обычно значит, что лабораторная среда беднее типичного визита или что вы попали в промах серверного кэша, а живые URL его держат.
Аудит Lighthouse «Reduce initial server response time» — подмножество: DNS и редиректы выкинуты. Кросс-доменный ресурс без Timing-Allow-Origin в поле даст responseStart = 0: это не нулевой TTFB, это дыра в заголовке. Свой бэкенд режут заголовком Server-Timing (db / ssr / cache hit) — так отличают медленный SQL от медленного TLS.
CSR с быстрым «200 OK» и пустым div#root зелёный по TTFB и красный по LCP: первый байт пришёл, героя в нём нет. Соседи — SSR и CSR. Origin-контракт для роботов — JavaScript SEO: TTFB измеряет человека в Chrome, не очередь WRS.
TTFB — диагностика, не KPI выдачи. Смотрят его, когда полевой LCP красный, а герой уже в первом HTML: тогда виноват путь до байта, не картинка.
На денежных шаблонах сначала сверяют полевой TTFB origin с лабораторным по финальному URL. Разрыв больше редиректа и кэша — постановка SEO-аудита сайта, не «поставить CDN» как отдельный H1 (CDN — следующий URL карты). Шире трёх метрик — Page Experience.
Ограничение. Нет доли витрин РФ с TTFB >1,8 с — не выдумываем. Нет формулы «минус N позиций за 801 мс»: метрика не Core Web Vital. Не складывайте индекс скорости Яндекса с 800 мс Google. Не подставляйте «Server response time» Lighthouse вместо полевого TTFB.
Частые вопросы
TTFB — это Core Web Vital?
Нет. Стабильная тройка — LCP, INP и CLS. TTFB в PSI помечен как экспериментальный диагностический показатель. Зелёный TTFB не закрывает отчёт Search Console, красный сам по себе не ставит группе статус «Низкая скорость».
Почему в Lighthouse 200 мс, а в PSI у реальных пользователей 1,2 с?
Лаборатория чаще бьёт в финальный канонический URL с тёплым DNS. Поле включает http→https, www, слеш, рекламный редирект и холодное соединение с другого континента. Сначала сжимают цепочку до одного 301, потом смотрят origin.
Достаточно ли ускорить PHP, чтобы TTFB стал зелёным?
Нет, если до PHP ещё DNS, TLS и два редиректа. Аудит «время ответа сервера» как раз выкидывает эти фазы. Чинят все куски до responseStart, не только скрипт страницы.
Яндекс смотрит TTFB?
В Вебмастере нет отчёта TTFB и нет Core Web Vitals. Достижение «скорость сайта» считается по открытиям в Яндекс Браузере с мобильного поиска — другая выборка и другая величина. Пороги 800 / 1800 мс относятся к Google CrUX.