Почему сайт «думает» перед загрузкой: разбираем TTFB

Время ответа сервера (TTFB) — пауза до первого байта HTML: браузер уже ждёт, а страница ещё пуста. Полевые данные Google оценивают задержку по своим порогам качества, а лабораторный PSI показывает другой замер. Разберём waterfall по фазам и найдём, где тормозят сеть, PHP, база или CMS.

Почему сайт думает: что такое TTFB до первого байта

Пока экран белый, браузер уже отправил запрос и ждёт первый байт HTML. Эта пауза и есть TTFB. Полная загрузка, DOMContentLoaded и отрисовка происходят позже.

Сайт может быстро отдать первый байт, а потом долго загружать стили и скрипты.

В waterfall запрос HTML делится на фазы. DNS ищет адрес хоста, TCP открывает соединение, TLS согласует шифрование. Waiting (TTFB) показывает ожидание первого байта после отправки запроса; Download — передачу HTML. Первые фазы связаны с сетью и соединением, а waiting зависит также от веб-сервера, PHP, базы и CMS.

Waiting — ожидание. Download — передача.

На карточке магазина DNS и TLS могут пройти быстро, а waiting растянется, пока WordPress или Битрикс собирают шаблон и товары. CDN сокращает сетевой путь до origin. HTTP/2 и HTTP/3 влияют на соединение, но не ускоряют сборку HTML приложением.

Пока браузер не получил первый байт HTML, контент ещё не начал отображаться. TTFB — только часть загрузки страницы.

Какое время ответа сервера считают нормой

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

Лабораторные замеры PSI, Lighthouse и WebPageTest помогают воспроизвести проблему. Полевые данные показывают опыт пользователей. Не сравнивайте показатели из разных типов замеров как одну шкалу.

География и тип страницы влияют на результат: расстояние до дата-центра меняет сетевую часть, а корзина может собираться дольше витрины. Для обычной витрины ориентируйтесь на полевые данные CrUX. Если страница требует авторизации и персонализации, одного числа TTFB недостаточно: нужно разбирать её запросы отдельно.

Для сайта с региональной мобильной аудиторией сначала смотрите полевые данные CrUX. Лабораторный замер из одной точки не показывает опыт всех посетителей.

Как TTFB связан с LCP и Core Web Vitals

TTFB не входит в Core Web Vitals, но влияет на время до начала отрисовки. Пока браузер не получил HTML, он не может показать основной контент страницы. Поэтому долгое ожидание первого байта может увеличить LCP, даже если изображение главного блока уже оптимизировано.

CrUX отражает полевые замеры, а лабораторный PSI запускает тест в заданных условиях. Результаты могут расходиться из-за географии и сетевого подключения посетителей.

Яндекс.Вебмастер и Метрика дают дополнительные данные о сайте и его аудитории. Проверяйте по ним динамику вместе с замерами конкретных страниц. Снижать TTFB стоит ради более быстрой отдачи страницы и сокращения ожидания до отрисовки.

TTFB не входит в Core Web Vitals, но задержка первого байта может отодвинуть LCP.

Из чего складывается задержка ответа

На TTFB влияют сетевой путь, веб-сервер и работа приложения. Чтобы найти причину, сравните несколько запросов и посмотрите, на какой фазе растёт задержка.

• Сеть: DNS и маршрут до origin. Сравните замеры из разных регионов.
• TLS: время соединения. Если растёт эта фаза, проблема возникает до генерации HTML.
• Веб-сервер: очередь запросов или ожидание свободного процесса. Сравните замеры в часы нагрузки и вне пика.
• PHP: тяжёлая логика приложения. Если статический файл отвечает быстрее PHP-страницы, проверьте обработку запроса и OPcache.
• База данных: медленные запросы на листингах и фильтрах. Сравните их с карточкой товара.
• Внешние API: синхронный вызов CRM, 1С, оплаты или геосервиса во время сборки страницы.
• CMS: плагины и темы WordPress, некешируемые компоненты Битрикс или код самописного сайта.

Таймаут браузера, прокси или PHP — это обрыв ожидания, а не высокая, но конечная задержка. Ищите, кто именно прекращает запрос.

Как измерить время ответа сервера

Выбирайте инструмент под вопрос. В DevTools откройте запрос документа HTML и посмотрите Timing -> Waiting (TTFB): это замер конкретного запроса в текущих условиях. PageSpeed Insights показывает лабораторный TTFB и, если данных достаточно, полевые показатели CrUX.

WebPageTest помогает сравнить замеры из разных точек и условия первого и повторного посещения. Один удачный прогон не описывает опыт всей аудитории.

Яндекс.Вебмастер и Метрика дают дополнительные данные по аудитории сайта. Не делайте вывод о сайте по одному лабораторному запросу.

Ошибка «истекло время ожидания ответа» означает, что браузер, прокси или сервер прекратил ждать. Высокий, но конечный TTFB — другая проблема: страница всё же пришла. Если зависает страница обмена, проверьте обращения к 1С и внешним API.

Зелёный лабораторный замер не гарантирует, что посетители из других регионов ждут столько же.

Чек-лист: где искать причину по стеку

Ищите причину сравнением запросов. Сначала проверьте ту же страницу из другого региона, затем сравните замеры с CDN и без него. После этого сопоставьте статику и динамическую страницу, карточку товара и корзину. Если статика отвечает быстро, а карточка медленно, проверяйте приложение, базу и CMS.

В WordPress проверьте кэш страниц, object cache, тяжёлые плагины и задачи wp-cron, запускаемые при запросе. В 1С-Битрикс проверьте композитный и автокэш, некешируемые компоненты и обмен с 1С. Подробнее о композитном кэше и типичных узких местах 1С-Битрикс. В самописном магазине проверьте персонализацию и синхронные запросы к CRM или учётной системе.

Тариф хостинга сам по себе не предсказывает TTFB. VPS не исправит медленный SQL, а выделенный сервер не уберёт задержку внешнего API. Сравнивайте замеры и нагрузку до смены тарифа.

Как сократить TTFB: что даёт эффект раньше

Начните с кэша и измерений, а не со смены тарифа. OPcache уменьшает повторную компиляцию PHP-скриптов; кэш страниц или композитный кэш помогает на публичных страницах. Для корзины и кабинета с персонализацией этот способ не подходит: их содержимое зависит от пользователя.

CDN может сократить сетевую часть для публичных страниц. Он не ускорит генерацию HTML на origin, если каждый запрос запускает PHP и базу. HTTP/3 влияет на соединение, но не устраняет задержку приложения.

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

Когда кэш и CDN не спасают интернет-магазин

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

Синхронный обмен с 1С или CRM во время запроса задерживает ответ, пока внешний сервис не вернёт данные. Композитный кэш не устранит ожидание в некешируемом компоненте. Проверьте, происходит ли вызов при каждом открытии страницы.

Сравните три запроса: карточку без авторизации, ту же карточку после входа и фильтр или поиск. Если публичная карточка отвечает быстро, а персонализированные страницы медленно, ищите задержку в динамической сборке HTML.

CDN ускоряет публичные страницы, но динамические страницы всё равно могут ждать origin.

Когда замеры указывают на задержку динамической страницы, сохраните URL проблемной страницы и данные waterfall. По ним разработчик сможет определить, где растёт время ожидания.

Источники

• Отчёты «Скорость загрузки сайта» — справка Google Analytics.