Главная → Все проверки → Время ответа сервера (TTFB)
Время ответа сервера (TTFB): что проверяется
Время ответа сервера — пауза между «открыть страницу» и первым откликом. Пока сервер думает, посетитель смотрит на белый экран.
Почему это важно
Пока сервер думает над ответом, посетитель смотрит на пустой экран. Чем дольше пауза, тем выше шанс, что он уйдёт, не дождавшись загрузки, и вес проверки 8 из 10 отражает это. Google документирует пороги на web.dev: до 800 мс — хорошо, после 1800 мс уже плохо, а в отчёте фиксируется один замер с нашего сервера, а не усреднённые полевые данные посетителей. Причина медленного ответа всегда одна из типовых: сервер без кэширования отдаёт каждую страницу заново из базы данных, дешёвый общий хостинг делит ресурсы между сотнями сайтов, или запрос летит через полмира до дата-центра без CDN. Проще всего помогает кэш страниц или CDN, это часы работы, а не дни. Если причина в архитектуре запросов к базе или в тарифе хостинга, чинить придётся дольше, иногда с переездом на мощный сервер.
Откуда взялись требования
Пороги времени ответа документированы Google на web.dev: хорошо до 800 мс, плохо после 1800. Здесь один замер с нашего сервера, а не полевые данные посетителей. Первоисточник ↗
Категория проверки: Скорость и Core Web Vitals. Вес в оценке: 8/10.
Какие результаты возможны
Сервер отвечает быстро, но просыпается долго
Оценка по повторному замеру: хорошо до 800 мс. Но первый посетитель после простоя ждёт столько же, сколько наш первый запрос. Лечится прогревом: пусть хостинг или крон открывает главную раз в несколько минут, либо увеличьте время жизни кэша страниц.
Сервер отвечает быстро
Это один замер с нашего сервера, не статистика реальных посетителей.
Сервер отвечает медленно
Проверьте три места: кэш готовых страниц (сервер отдаёт готовый HTML вместо повторной сборки), тариф хостинга, медленные запросы к базе. Цель: 800 мс и меньше.
Сервер отвечает очень медленно
Начните с кэша готовых страниц: он убирает повторную сборку HTML на каждый запрос. Потом тариф хостинга и медленные запросы к базе. Цель: 800 мс и меньше.
Пороговые значения
Числа, по которым проверка выносит вердикт. Они зашиты в движок и одинаковы для всех сайтов.
- Порог «хорошо»
- 800 мс
- Порог «плохо»
- 1800 мс
Кто исправляет
Правку по этой проверке обычно поручают разработчику или хостингу.
Другие проверки категории «Скорость и Core Web Vitals»
Частые вопросы: время ответа сервера (TTFB)
Чем время ответа сервера (TTFB) отличается от общей скорости загрузки страницы?
TTFB — это только пауза до первого байта ответа сервера, ещё до того, как браузер начнёт получать HTML, картинки или скрипты. Общая скорость загрузки включает TTFB как первый этап, а дальше добавляется время на скачивание и отрисовку всей страницы. Медленный TTFB тянет за собой все следующие метрики, включая Core Web Vitals.
Почему результат проверки TTFB может отличаться от того, что показывает PageSpeed Insights?
В нашем отчёте фиксируется один замер с сервера в конкретный момент, а PageSpeed и похожие сервисы иногда опираются на усреднённые полевые данные реальных посетителей за прошлые недели. Разница по времени суток, нагрузке на сервер и географии измерения — это нормально: важна общая картина, стабильно ли сервер укладывается в 800 мс.
Что быстрее всего снижает время ответа сервера, если чинить своими силами?
Обычно самый быстрый эффект даёт кэширование на уровне сервера или подключение CDN — страница перестаёт каждый раз собираться заново из базы данных. Если это не помогло, проблема глубже: медленные запросы к базе, нехватка ресурсов на тарифе хостинга или устаревшая версия PHP без opcache, и здесь уже нужен разработчик.
Не то, что искали?
Проверить страницу целиком
Эта проверка — одна из 52. Полный анализ показывает оценку от 0 до 100, разбор по категориям и список того, что чинить первым.