Почему страницы сайта долго отвечают до начала загрузки
Если после перехода по ссылке несколько секунд ничего не происходит, проблема может возникать ещё до получения HTML. Браузер ждёт DNS, соединение, TLS, редиректы и работу сервера. Совокупное время до первого байта ответа называется TTFB.
Высокий TTFB нельзя исправить сжатием картинки, которая начнёт загружаться позже. Но и любой «белый экран» нельзя автоматически считать серверной проблемой: HTML может прийти быстро, а интерфейс появиться поздно из-за CSS, JavaScript или позднего обнаружения главного ресурса. Сначала нужно разделить эти случаи.
Что входит в TTFB
MDN определяет TTFB как время между началом запроса страницы и получением первого байта. В него входят DNS-разрешение, установление TCP-соединения, TLS для HTTPS и ожидание ответа [1]. Полевое значение также учитывает редиректы, поэтому оно нередко выше лабораторного замера финального URL.
Web.dev предлагает ориентир: большинству сайтов полезно стремиться к TTFB не выше 0,8 секунды на 75-м процентиле, а значения свыше 1,8 секунды считаются плохими. Это диагностический ориентир, а не Core Web Vital и не универсальная гарантия быстрого интерфейса [2].
Как отличить серверную задержку от медленной отрисовки
- Долго ждёт основной Document. В Network большой участок Waiting/TTFB — исследуют сеть и backend.
- Document пришёл быстро, контент появился поздно. Ищут блокирующие стили, шрифты, JavaScript и позднее обнаружение LCP-ресурса.
- Первое открытие медленное, повторное быстрое. Проверяют прогрев серверного кеша, кеш браузера и соединения.
- Только отдельные URL медленные. Вероятна зависимость от SQL, шаблона, внешнего API или объёма данных.
- Медленно только под нагрузкой. Проверяют очереди PHP-FPM, пул соединений, блокировки и исчерпание CPU, RAM или диска.
Где измерять TTFB
Полевые данные
PageSpeed Insights показывает данные реальных пользователей, если URL или группа страниц представлены в Chrome UX Report. Собственная RUM-система может записывать responseStart из Navigation Timing и сегментировать результат по URL, устройству, региону и типу посетителя [1].
Лабораторная проверка
В Chrome DevTools открывают Network, отключают кеш и смотрят основной документ. Замер повторяют несколько раз для прогретого и непрогретого состояния. Один внешний тест может включать случайную сетевую задержку, поэтому решение принимают по серии измерений.
Логи приложения и Server-Timing
Чтобы увидеть внутреннюю структуру ожидания, приложение может отправлять заголовок Server-Timing с длительностью SQL, серверного рендеринга, обращения к файлам или внешнему API. Эти метрики отображаются в инструментах браузера и доступны через Performance API [2][3].
Заголовок не должен раскрывать SQL, пути, идентификаторы пользователей или внутренние адреса. В публичном ответе достаточно нейтральных названий и длительности.
TTFB также входит в полное время LCP: задержка HTML отодвигает обнаружение и загрузку главного ресурса страницы [4].
Частые причины высокого TTFB
Цепочка редиректов
Переход с HTTP на HTTPS, затем с одного варианта домена на другой и ещё один редирект по пути добавляют отдельные сетевые циклы. Для внутренних ссылок сразу указывают финальный канонический URL, а правила на сервере объединяют там, где это возможно.
Промах серверного кеша
Популярная страница после прогрева может отвечать быстро, а редкая — каждый раз собираться заново. Сравнивают cache hit и miss, TTL, причины инвалидирования и ключ кеша. Персонализированный HTML нельзя безусловно раздавать всем из общего кеша.
Медленные запросы или блокировки базы
Проблему ищут по журналу медленных запросов, профилю URL и планам выполнения. Отдельно проверяют ожидания блокировок во время импорта, отчётов и фоновых заданий. Увеличение мощности сервера может временно скрыть неэффективный запрос, но не устранить причину.
Внешние API в критическом пути
Если страница до отправки HTML ждёт курс валют, доставку, остаток, рекомендации или CRM, задержка и отказ внешней системы становятся задержкой сайта. Помогают короткие таймауты, кеширование допустимых данных, ограниченные повторы и безопасный сценарий деградации.
Очередь PHP-FPM и нехватка ресурсов
Когда все воркеры заняты, новый запрос ждёт даже при быстром коде. Сопоставляют очередь, число активных процессов, память на процесс, CPU и время выполнения. Бесконтрольное увеличение числа воркеров способно исчерпать RAM и ухудшить ситуацию.
Фоновые задачи на том же сервере
Резервное копирование, импорт, генерация выгрузки, переиндексация и отчёт могут конкурировать за диск и базу. Проверяют корреляцию по времени и разносят тяжёлые задачи, не нарушая требуемую частоту обновления данных.
Пошаговый разбор
- Выбрать медленный URL и записать точное время, пользователя и состояние кеша.
- Проверить редиректы и сетевую часть из региона основной аудитории.
- Сравнить TTFB прогретого и непрогретого запроса.
- Добавить серверные тайминги или трассировку приложения.
- Сопоставить запрос с SQL, внешними вызовами и очередями процессов.
- Внести одно изменение и повторить тот же сценарий.
- Проверить результат под обычной и повышенной нагрузкой.
Если TTFB нестабилен, медиана скрывает редкие провалы. Полезно смотреть 75-й и 95-й процентили, а также максимумы по отдельным шаблонам. Именно длинный хвост часто объясняет жалобы, которые не воспроизводятся при ручном открытии страницы.
Что исправлять в первую очередь
Приоритет выбирают по доказанной доле времени. Сначала убирают лишние редиректы и синхронное ожидание внешних систем, исправляют тяжёлые SQL и частые промахи кеша. Затем настраивают процессы PHP, базу и ресурсы сервера. CDN полезен для удалённой аудитории и кешируемого контента, но не должен маскировать медленный origin: web.dev рекомендует иметь способ отдельно проверить обход кеша [2].
Как выглядит проверяемый результат
После работ остаются исходные и итоговые значения для набора URL, описание найденного узкого места, конфигурация таймаутов и кеша, а также проверка функций сайта. Измерения проводят в одинаковых условиях и продолжают наблюдать после публикации: реальная нагрузка и редкие страницы способны показать проблему, которой не было на тестовом запуске.
Источники
[1] MDN — Time to First Byte: developer.mozilla.org/en-US/docs/Glossary/Time_to_first_byte
[2] web.dev — Optimize Time to First Byte: web.dev/articles/optimize-ttfb
[3] MDN — заголовок Server-Timing: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Server-Timing
[4] web.dev — составляющие Largest Contentful Paint: web.dev/articles/optimize-lcp