TTFB (Time to First Byte)

TTFB измеряет, сколько времени прошло от начала перехода на страницу до прихода первого байта ответа сервера. Это самый первый этап, и он складывается из нескольких шагов:

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

TTFB — диагностическая метрика, не входит в тройку Core Web Vitals, но важна, потому что открывает цепочку загрузки страницы: пока не пришёл первый байт, браузеру нечего парсить, поэтому откладываются FCP и LCP. Высокий TTFB часто ухудшает и другие метрики производительности.

Но низкий TTFB не гарантирует хороший LCP или FCP: после получения первого байта браузеру всё ещё нужно скачать ресурсы, выполнить JavaScript и отрисовать страницу.

Хорошим считается TTFB до 0,8 с, плохим — больше 1,8 с. Полную таблицу порогов для всех метрик смотрите в статье «Что такое Core Web Vitals». Измерить TTFB можно в PageSpeed Insights, на вкладке Network в DevTools или через библиотеку web-vitals, а для полевых данных — через Chrome UX Report (CrUX), базу реальных замеров с устройств пользователей Chrome.

Чаще всего высокий TTFB вызван либо сетью (большое расстояние до сервера, отсутствие CDN — сети распределённых серверов, которая раздаёт контент с узла, физически близкого к пользователю), либо медленной работой сервера (рендеринг страницы, запросы к базе данных, обращения к внешним API).

• подключите CDN для статики и, если возможно, для HTML — заодно получите HTTP/2, HTTP/3 и TLS 1.3;
• кешируйте HTML через Cache-Control, настройте инвалидацию кеша при релизах и избегайте уникальных query-параметров, которые могут помешать кешированию на CDN и промежуточных кешах;
• уберите редиректы. Каждый 301/302 — это лишний круг ожидания перед ответом. Прописывайте правильную схему и слеши. Ставьте заголовок HSTS (Strict-Transport-Security), чтобы убрать редирект HTTP в HTTPS у повторных посетителей. Для первого визита (когда браузер ещё не видел этот заголовок) редирект всё равно случится — от него избавляет попадание домена в HSTS preload list, встроенный в браузер список доменов, для которых он сразу использует HTTPS, не выполняя первоначальный HTTP-запрос;
• современные протоколы HTTP/2 и HTTP/3 (QUIC) уменьшают задержки на установке соединения — обычно они уже включены на уровне CDN.

• стримьте разметку: браузеры умеют обрабатывать HTML кусками по мере поступления. Используйте серверный стриминг, например renderToPipeableStream в React с компонентом <Suspense> — он начнёт отправку страницы, пока медленные данные ещё загружаются;
• в Next.js используйте SSG (статическая генерация HTML на этапе сборки) или ISR (инкрементальная регенерация статики) для страниц, которым не нужен ответ, собранный для каждого посетителя — готовый HTML можно отдать через CDN;
• service worker со стратегией stale-while-revalidate отдаёт оболочку приложения мгновенно из кеша (app shell), а динамический контент подгружает следом. Для персонализированной разметки, которая формируется при каждом запросе, stale-while-revalidate не годится: отдаст устаревшую версию;
• 103 Early Hints: сервер успевает подсказать браузеру, какие критичные ресурсы качать, пока готовит основной ответ. Некоторые CDN (например, Cloudflare) умеют отправлять его ещё до формирования основного ответа. Приём пока распространён слабо, так что это ваше потенциальное преимущество;
• проверьте бэкенд: хватает ли памяти, свежее ли ПО. Измеряйте узкие места заголовком Server-Timing: сервер размечает в нём отдельные внутренние этапы (запрос к БД, рендер, попадание в кеш CDN). Эти тайминги становятся доступны в браузере через Navigation Timing API — встроенный браузерный интерфейс, который отдаёт в JavaScript точные метки времени по каждому этапу загрузки страницы, поэтому узкое место видно и на реальных визитах пользователей, а не только в тестовом прогоне в DevTools.