TTFB

Как работает

TTFB — суммарное время нескольких этапов: DNS-резолвинг, установка TCP-соединения, TLS-хендшейк, отправка HTTP-запроса, генерация ответа на сервере, получение первого байта в браузере. Всё, что происходит до того, как клиент увидел хоть один символ ответа.

Замер простой — в терминале:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s" https://example.com/

Web-стандарт в API Performance:

const nav = performance.getEntriesByType("navigation")[0];
console.log("TTFB:", nav.responseStart - nav.requestStart, "ms");

Google в документации Web Vitals указывает ориентир для хорошего TTFB — до 800 мс на 75-м перцентиле. Значение больше 1.8 секунды считается плохим и почти всегда тянет за собой плохой LCP.

Сам по себе TTFB официально не входит в Core Web Vitals, но напрямую влияет на LCP: если сервер отдал первый байт за 2 секунды, никакая оптимизация фронтенда не даст отрисовать крупный элемент раньше.

Почему важно для SEO

Медленный TTFB — почти всегда узкое место для скорости страницы в целом. У пользователя это ощущается как «сайт задумывается перед загрузкой»: белый экран без реакции. Даже если верстка легковесная и картинки сжаты, пока не пришёл первый байт HTML, браузеру нечего рисовать.

Для Google TTFB — фундамент под всеми метриками производительности. При равных прочих сайт с TTFB 300 мс уверенно проходит Core Web Vitals, сайт с TTFB 1.5 с — почти никогда. В Search Central Google рекомендует держать TTFB под 800 мс, отдельно упоминая, что для международного трафика без CDN этого добиться крайне сложно.

Яндекс не публикует прямых порогов, но в Вебмастере в разделе «Скорость загрузки» плохой TTFB сразу подсвечивается как проблема — с рекомендациями по кэшированию и CDN.

Частые ошибки

• Хостинг shared без выделенных ресурсов — TTFB плавает от 400 мс до 3 секунд в зависимости от соседей на сервере.
• Backend не кэширует ответы: каждый запрос идёт в БД и рендерится с нуля, TTFB упирается в SQL.
• CDN отсутствует, а аудитория географически распределена — трафик из Владивостока идёт до сервера в Москве через полмира.
• HTTPS без HTTP/2 или HTTP/3 — лишний раунд-трип на TLS каждый раз.
• Первый ответ уходит в редирект (301/302) — TTFB считается по конечному URL и растёт вдвое.
• Тяжёлая middleware в приложении: логирование, аналитика, антифрод-проверки на каждом запросе.

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

В браузере откройте DevTools → Network → любой запрос → вкладка Timing → строка «Waiting for server response (TTFB)». Через терминал — curl -w "%{time_starttransfer}" -o /dev/null -s https://example.com/. Для полевых данных — PageSpeed Insights (pagespeed.web.dev) в разделе «Полевые данные» показывает TTFB на реальных пользователях через API CrUX. Расширение Web Vitals для Chrome выводит метрику при переходе по страницам.

SEO Crawler фиксирует TTFB при каждом запросе к странице и подсвечивает URL с плохими значениями. В отчёте это блок «Производительность» — с разбивкой по типам страниц (главная, категории, товары, статьи) и указанием, какие разделы сайта тянут метрику вниз в первую очередь.

Вывод

TTFB — базовая метрика, за которой стоит вся производительность страницы. Держите его под 800 мс через кэширование ответов на бэкенде, CDN, HTTP/2 и минимальное количество редиректов на пути к целевому URL. Без быстрого TTFB не получится ни хороший LCP, ни зелёные Core Web Vitals, ни стабильные позиции в мобильной выдаче.