Почему ваш Time to First Byte медленный и что с этим делать

Начните с того, что на самом деле измеряет TTFB

Time to First Byte, обычно сокращаемое до TTFB, — это время между запросом ресурса браузером и получением первого байта ответа.

Звучит как серверная метрика, но это не только серверная метрика. TTFB включает несколько этапов:

• DNS lookup, если hostname еще не разрешен
• Установление TCP-соединения
• TLS-согласование для HTTPS
• Время прохождения запроса до сервера или CDN edge
• Ожидание в очереди и обработка на сервере
• Время прохождения ответа обратно к браузеру

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

Это важно, потому что TTFB находится почти в начале цепочки загрузки. Если HTML-документ приходит поздно, браузер поздно обнаруживает CSS, JavaScript, шрифты и изображения. У вас может быть отличная фронтенд-оптимизация, но сайт все равно будет ощущаться медленным, если первый ответ с документом занимает 1,5 секунды.

Какой TTFB считать медленным?

Нет универсального числа, которое подходит для любого сайта, региона и архитектуры. Но практические пороги помогают.

Рекомендации Google web.dev классифицируют хороший TTFB как значение ниже 800 ms; 800–1800 ms требуют улучшения, а выше 1800 ms считаются плохим результатом. Для хорошо кэшируемой маркетинговой страницы, которая обслуживается рядом с пользователем, часто можно добиться значительно лучшего результата. Для сложной аутентифицированной панели, выполняющей динамическую работу, приемлемое значение может быть выше, но оно все равно должно быть объяснимым.

Важная привычка — сегментировать показатель. Глобальный средний TTFB в 900 ms может скрывать ответ за 150 ms для пользователей рядом с вашим CDN edge и ответ за 2200 ms для пользователей в другом регионе. Точно так же главная страница может быть в порядке, тогда как поиск, категории или страницы для вошедших пользователей тихо создают проблемы.

Измеряйте больше чем в одном месте

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

Для TTFB нужны как минимум три взгляда:

1. Инструменты разработчика в браузере

Откройте панель Network, перезагрузите страницу с отключенным кэшем и изучите запрос основного документа. Разбивка по времени показывает DNS, соединение, TLS, ожидание и фазы загрузки. Фаза “waiting” часто и есть то, что люди называют временем бэкенда, хотя она может включать задержку upstream.

2. Синтетические тесты из нескольких регионов

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

3. Real user monitoring или серверные логи

Полевые данные показывают, что реальные пользователи испытывают на разных устройствах, сетях и сессиях. Серверные логи могут показать, быстро ли origin сгенерировал ответ. Разница между TTFB, наблюдаемым клиентом, и временем обработки на origin часто указывает на проблемы CDN и сети.

Обычные причины медленного TTFB

Ваш HTML не кэшируется

Это самая распространенная проблема на контентных и ecommerce-сайтах. Статические ресурсы кэшируются агрессивно, но HTML-документ — то, что браузеру нужно первым, — генерируется при каждом запросе.

Иногда это необходимо. Часто — нет.

Если публичная страница меняется несколько раз в день, ей, вероятно, не нужен свежий рендер из базы данных для каждого анонимного посетителя. Используйте full-page caching, edge caching, static generation или паттерны stale-while-revalidate там, где это уместно.

Проверяйте заголовки ответа на признаки вроде Cache-Control, CDN-Cache-Status, Age, Vary и Set-Cookie. Страница, которая отправляет уникальную cookie каждому посетителю, может случайно сделать себя некэшируемой. Если вам нужен практичный способ рассуждать об этом слое, те же отладочные привычки из нашего руководства по редиректам и HTTP headers в production напрямую применимы к работе с TTFB.

Ваш CDN кэширует только assets

Многие команды добавляют CDN и считают, что задача производительности решена. Но если CDN обслуживает только изображения, CSS и JavaScript, первый HTML-запрос все еще может идти до единственного origin-сервера.

Это может быть нормально для локального бизнес-сайта с локальными пользователями. Но это не подходит для международной аудитории. Чем дальше пользователь от origin, тем большую задержку вы оплачиваете еще до начала работы бэкенда.

Хорошая настройка CDN для TTFB обычно означает:

• Кэшировать публичный HTML там, где это безопасно
• Соблюдать намеренные правила обхода кэша для аутентифицированных или персонализированных страниц
• Избегать ненужных заголовков Vary, которые слишком мелко дробят кэш
• Использовать очистку кэша или revalidation вместо полного отключения кэша
• Убедиться, что edge locations действительно отдают hits, а не пересылают каждый запрос

CDN — не магия. Это слой кэша и маршрутизации. Относитесь к нему именно так.

Ваш сервер делает слишком много до ответа

Медленный путь на бэкенде может складываться из множества небольших задержек: запросов к базе данных, API-вызовов, рендеринга шаблонов, проверок feature flag, аутентификации, персонализации, логирования и cold starts.

Худший паттерн — последовательная работа зависимостей. Например:

1. Получить данные страницы
2. Затем получить связанные товары
3. Затем получить цены
4. Затем вызвать сервис рекомендаций
5. Затем отрендерить HTML

Если каждый шаг ждет предыдущего, TTFB быстро растет. Распараллеливайте независимую работу, убирайте некритичные вызовы из первого ответа и кэшируйте дорогие результаты.

Полезное правило: если пользователь не может сразу увидеть или использовать результат, он, вероятно, не должен блокировать первый байт.

Запросы к базе данных медленные или непредсказуемые

Базы данных часто создают проблемы TTFB, потому что хорошо ведут себя в разработке и плохо — под реальным трафиком. Отсутствующие индексы, большие joins, N+1 queries, lock contention и слишком крупные result sets — все это проявляется как “сервер медленный”.

Здесь не стоит гадать. Собирайте timings запросов для медленных requests. Смотрите на p95 и p99, а не только на средние значения. Страница, которая обычно отвечает за 120 ms, но иногда блокируется на 4 секунды, все равно создает плохой пользовательский опыт.

Типичные исправления включают:

• Добавление или исправление индексов
• Удаление паттернов N+1 queries
• Кэширование данных с большим числом чтений
• Пагинацию больших запросов
• Вынос reporting или analytics queries из времени обработки request
• Настройку разумных timeouts для downstream calls

У вашего приложения есть cold starts

Serverless и контейнеризованные платформы могут быть отличными, но cold starts могут ухудшать TTFB, когда трафик идет всплесками или регионы недостаточно обеспечены ресурсами.

Если первый запрос после простоя намного медленнее последующих, исследуйте cold starts. Вам могут понадобиться provisioned concurrency, меньшие bundles, меньше startup dependencies, warmer functions или другая форма деплоя для routes, чувствительных к задержке.

Это не аргумент против serverless. Это аргумент против притворства, что runtime model невидима.

Редиректы тратят первый запрос впустую

Редирект добавляет еще один цикл request-response до того, как браузер получит финальный документ. Один редирект с http:// на https:// может быть неизбежен для старых ссылок, но цепочки расточительны.

Распространенные цепочки включают:

• http://example.com → https://example.com → https://www.example.com
• нормализацию trailing slash после нормализации протокола
• geo- или language-редиректы до lookup кэша
• старые campaign links, которые проходят через несколько URLs

Исправляйте исходные ссылки там, где возможно, объединяйте правила редиректов и делайте canonical URLs прямыми. Время редиректа не всегда отображается как TTFB финального запроса, но пользователь все равно за него платит.

Практическая последовательность отладки

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

Step 1: Тестируйте основной документ, а не только всю страницу

Найдите запрос HTML-документа. Запишите общий TTFB и разбивку по времени. Повторите с кэшем браузера и без него. Проверьте публичную страницу, динамическую страницу и страницу для вошедшего пользователя, если это актуально.

Step 2: Сравните регионы

Запустите тот же URL из нескольких географических локаций. Если медленные регионы коррелируют с расстоянием до origin, приоритизируйте CDN и edge caching. Если медленно в каждом регионе, смотрите на обработку бэкенда и емкость origin.

Step 3: Изучите заголовки ответа

Ищите cache headers, cookies, Age, статус CDN и Vary. Отсутствующий заголовок Age или повторяющиеся промахи кэша — подсказки. Широкий Vary: Cookie на публичном HTML часто убивает кэш.

Step 4: Проверьте timing на origin

Добавьте server timing instrumentation. Заголовок Server-Timing может показывать фазы бэкенда, такие как время базы данных, время рендера и время upstream API. Даже простые метки полезны:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Теперь timings в браузере могут показать, потратил ли сервер 300 ms на реальную работу или задержка произошла до того, как запрос достиг вашего приложения.

Step 5: Исправьте самую большую подтвержденную задержку

Звучит очевидно, но команды часто исправляют то, что им знакомо, а не то, что измерено. Если доминируют промахи кэша, исправляйте кэширование. Если доминирует база данных, исправляйте запросы. Если TLS и установление соединения доминируют для глобальных пользователей, исправляйте маршрутизацию, покрытие CDN или географию origin.

Фронтенд-работа все еще важна. Шрифты, изображения и JavaScript влияют на то, что происходит после прихода HTML. Но они не заменяют быстрый первый ответ. Если вы также работаете над производительностью рендера, web fonts остаются одним из самых простых выигрышей на многих сайтах, потому что они влияют на то, как быстро текст становится usable после прихода документа.

Исправления, которые обычно работают

Кэшируйте публичный HTML на edge

Для маркетинговых страниц, документации, блогов, landing pages и category pages edge caching часто дает самое большое улучшение TTFB. Используйте короткие TTL, если контент часто меняется. Используйте stale-while-revalidate, если слегка устаревший контент приемлем, пока кэш обновляется в фоне.

Будьте осторожны с персонализацией. Если страница различается по валюте, языку, состоянию входа или экспериментальной группе, определяйте эти варианты явно. Случайная вариативность на уровне каждого пользователя разрушает эффективность кэша.

Выносите некритичную работу из request path

Отправка email, analytics enrichment, генерация рекомендаций, webhook calls и тяжелое логирование редко должны блокировать первый байт. Помещайте их в очереди или запускайте после начала ответа.

Сократите цепочки зависимостей бэкенда

Распараллеливайте независимые вызовы. Кэшируйте ответы медленных API. Настраивайте timeouts. Проектируйте fallback content для сервисов, которые полезны, но не обязательны.

Медленный виджет рекомендаций не должен задерживать всю страницу товара.

Размещайте вычисления ближе к пользователям

Если ваши пользователи глобальны, а origin находится в одном регионе, задержка является структурной. CDN caching может скрыть большую ее часть для публичного контента. Для динамического контента рассмотрите regional deployments, edge rendering для подходящих routes или перенос API ближе к аудитории.

Держите редиректы скучными

Канонизируйте URLs за один hop. Обновляйте внутренние ссылки, чтобы пользователи и crawlers шли прямо к финальному назначению. Аудируйте старые campaign URLs и миграции платформ. Редиректы легко игнорировать, потому что они невидимы, когда работают, но они все равно стоят времени.

Чего не делать

Не гонитесь за идеальным числом TTFB для каждого route. Аутентифицированный отчет, выполняющий реальные вычисления, не будет вести себя как кэшированный blog post.

Не используйте средний TTFB как единственную метрику. Percentiles важны. География важна. Тип страницы важен.

Не считайте, что CDN означает кэшированный HTML. Проверяйте это.

И не рассматривайте TTFB отдельно от продуктовых решений. Персонализация, эксперименты, real-time inventory и сторонние сервисы — все это имеет цену в задержке. Некоторые из них того стоят. Некоторые — просто привычка.

<!-- tool-cta:start -->

💡 Попробуйте это: При диагностике TTFB Get Headers показывает состояние кеша, серверные тайминги и перенаправления, которые часто объясняют, откуда возникает задержка.

<!-- tool-cta:end -->

Спокойная версия плана

Медленный TTFB обычно можно исправить, как только вы перестаете относиться к нему как к расплывчатой “серверной проблеме”. Измерьте запрос документа. Сегментируйте по региону и типу страницы. Изучите заголовки. Сравните client timing с origin timing. Затем исправьте самое большое подтвержденное узкое место.

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