Почему сайт медленно отвечает

Что такое TTFB и почему он важен

TTFB, или Time To First Byte, показывает время до первого байта ответа от сервера. Это не полная скорость загрузки страницы, но важный сигнал: если первый байт приходит поздно, браузер не может начать нормально загружать HTML, CSS, JS и остальные ресурсы.

Высокий TTFB особенно заметен на страницах, где пользователь ожидает мгновенной реакции: каталог, карточка товара, оформление заказа, авторизация, форма заявки, админка. Даже если итоговая страница загрузится, задержка в начале создаёт ощущение, что сайт завис.

• TTFB ниже 200 мс обычно выглядит хорошо для большинства сценариев
• TTFB 200-800 мс требует контекста и сравнения с обычным уровнем
• TTFB выше 800-1200 мс часто заметен пользователям
• пики TTFB важнее смотреть по истории, а не по одному замеру

Backend и база данных как частая причина задержки

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

База данных часто становится узким местом при росте данных или трафика. Неоптимальный индекс, тяжёлый JOIN, блокировка транзакции, медленный диск или ограниченный пул соединений могут увеличить время ответа без явного падения сайта.

• проверьте slow query log и самые тяжёлые endpoint
• сравните TTFB до и после деплоя
• проверьте пул соединений к базе
• посмотрите, нет ли ожидания внешних API

Нагрузка сервера: CPU, RAM, диск и сеть

Медленный ответ сайта часто связан с серверными ресурсами. Высокий CPU увеличивает очереди запросов. Нехватка RAM приводит к swap или аварийным завершениям процессов. Медленный или заполненный диск влияет на базу, кеш, логи и загрузку файлов.

Важно смотреть метрики вместе. Сам по себе TTFB показывает симптом, но не причину. Если рядом растёт CPU, RAM близко к лимиту или диск занят почти полностью, диагностика становится намного быстрее. Если ресурсов достаточно, нужно глубже смотреть приложение, базу и внешние зависимости.

• CPU в пике рядом с высоким TTFB указывает на перегрузку
• RAM у лимита может приводить к swap и OOM
• заполненный диск ломает кеши, логи и базу
• сетевые задержки важны при внешних API и удалённой базе

Кеширование и холодные страницы

Если сайт быстро отвечает после первого открытия, но медленно на холодном запросе, причина может быть в кешировании. CMS, фреймворк, reverse proxy и CDN могут резко менять TTFB в зависимости от того, попал запрос в кеш или нет.

Проблема начинается, когда холодный запрос слишком дорогой: генерация страницы занимает секунды, кеш часто инвалидируется, а при пике трафика много пользователей одновременно пробивают кеш. В таких случаях нужно оптимизировать генерацию, прогрев, TTL и тяжёлые участки backend.

• сравните первый и повторный запрос
• проверьте cache hit/cache miss на CDN или proxy
• не инвалидируйте весь кеш при каждом небольшом изменении
• прогревайте критичные страницы после деплоя

Как мониторить медленный ответ

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

Настройте мониторинг ключевых URL: главная, страницы заявок, авторизация, корзина, оплата, API endpoint. Для каждого URL полезно видеть статус, TTFB, редиректы и историю. После восстановления проверьте, вернулся ли TTFB к нормальному уровню, а не просто исчезли ли 5xx.

• проверяйте TTFB регулярно и по нескольким URL
• сравнивайте пики с CPU, RAM, диском и логами
• отправляйте уведомления по повторяющейся деградации
• храните историю для разбора после инцидента

Что оптимизировать в первую очередь

Начинайте не с абстрактной оптимизации, а с самого медленного пользовательского пути. Если медленно открывается каталог, смотрите запросы к базе, кеш фильтров и генерацию карточек. Если тормозит оформление заказа, проверяйте платёжные API, сессии, корзину и блокировки. Если медленный вход в личный кабинет, смотрите авторизацию, внешние OAuth-сервисы и запросы профиля.

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

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

• оптимизируйте самый важный и медленный сценарий первым
• сравнивайте TTFB до и после изменения
• не оценивайте результат только по прогретому кешу
• держите мониторинг включённым после релиза