Сайт отвечает. Status code 200. Uptime 100%. Но пользователи жалуются: "Всё тормозит". Дашборд грузится 4 секунды. Поиск — 3. Checkout — 5. Технически — сайт работает. Практически — пользователи уходят. Amazon подсчитал, что каждые 100ms дополнительной задержки снижают конверсию на 1%. Google обнаружил, что увеличение времени загрузки с 0.4 до 0.9 секунды снижает трафик на 20%.
Uptime monitoring отвечает на вопрос "работает ли сервис?". Response time monitoring отвечает на другой: "насколько хорошо он работает?". Оба критичны, но второй чаще игнорируют — пока деградация не станет очевидной.
Анатомия HTTP-запроса: из чего складывается response time
Когда мониторинг отправляет HTTP-запрос к вашему серверу, request проходит через несколько фаз. Каждая добавляет время. Понимание этих фаз — ключ к диагностике: если response time вырос, вы должны знать, на какой фазе он вырос.
DNS Lookup (5-50ms). Резолвинг доменного имени в IP-адрес. Обычно кэшируется, но первый запрос или запрос после TTL expiry требует полного round-trip к DNS-серверу. Anycast DNS (Cloudflare, Route53) минимизирует этот этап. DNS-мониторинг ловит аномалии на этом уровне.
TCP Connection (10-100ms). Три-стороннее рукопожатие: SYN → SYN-ACK → ACK. Время зависит от расстояния между клиентом и сервером. Франкфурт → Амстердам — 10ms. Франкфурт → Сингапур — 150ms. CDN и edge servers сокращают этот этап.
TLS Handshake (20-100ms). Установка шифрованного соединения. TLS 1.3 делает это за 1 round-trip (vs 2 для TLS 1.2). OCSP Stapling экономит ещё один round-trip на проверку отзыва сертификата.
TTFB — Time to First Byte. Время от отправки запроса до первого байта ответа. Это серверная обработка: routing, middleware, database query, template rendering, сериализация. TTFB — главная метрика, которую вы контролируете. Всё до TTFB — сеть; TTFB — ваш код.
Content Transfer. Получение всего тела ответа. Для маленьких JSON-ответов (1-5KB) — миллисекунды. Для тяжёлых HTML-страниц (500KB+) — заметное время, особенно на медленных соединениях.
TTFB: метрика, которая важнее всего
TTFB изолирует серверную производительность от сетевых факторов. Если TTFB вырос с 80ms до 500ms, а DNS и TCP не изменились — проблема внутри вашего приложения: медленный SQL-запрос, утечка памяти, cold cache, перегруженный worker pool.
AtomPing записывает TTFB для каждой HTTP-проверки отдельно от total response time. Это позволяет видеть: "total time = 800ms, но из них TTFB = 600ms" → проблема на сервере; vs "total time = 800ms, но TTFB = 100ms" → проблема в размере ответа или скорости передачи.
TTFB < 100ms — отлично. Ваш бэкенд быстр, кэширование работает.
TTFB 100-300ms — хорошо. Типично для API с database queries без тяжёлых JOIN.
TTFB 300-800ms — приемлемо для тяжёлых страниц с серверным рендерингом. Ищите оптимизации.
TTFB 800ms-2s — проблема. Пользователи ждут заметно. Google может снизить частоту crawling.
TTFB > 2s — критично. Скорее всего, медленные запросы к БД, тяжёлые вычисления или проблемы с внешними зависимостями.
Percentiles vs average: почему среднее врёт
Допустим, за час ваш API обработал 10,000 запросов. Средний response time — 120ms. Выглядит отлично. Но если посмотреть распределение:
p50 (медиана): 90ms — половина запросов отвечает за 90ms. Быстро.
p95: 250ms — 5% запросов медленнее 250ms. Терпимо.
p99: 3,200ms — 1% запросов отвечает дольше 3 секунд. При 10,000 запросов — это 100 пользователей с отвратительным опытом.
p99.9: 12,000ms — один из тысячи запросов висит 12 секунд. Скорее всего, таймаут к внешнему сервису.
Среднее (120ms) маскирует хвост распределения. Именно поэтому SLI для latency задаётся через перцентили: "p95 response time \< 500ms за rolling 30 дней".
Как настроить мониторинг response time
Шаг 1: Определите baseline
Прежде чем ставить пороги — поймите, какой response time "нормальный" для каждого endpoint. Включите мониторинг, подождите 24-48 часов, посмотрите распределение. У landing page, API health и тяжёлого dashboard report будут разные нормы. Нельзя ставить одинаковый порог 500ms на всё.
Шаг 2: Установите пороги
Двухуровневая система:
Warning — 2x от baseline. Если нормальный TTFB = 100ms, warning при 200ms. Это ранний сигнал деградации. Уведомление в Slack, без пробуждения on-call.
Critical — 5x от baseline или абсолютный потолок. Если нормальный TTFB = 100ms, critical при 500ms или при абсолютном пороге 2 секунды (что меньше). Это открывает инцидент и отправляет алерт.
Шаг 3: Мониторьте из нескольких регионов
Response time зависит от расстояния между probe и сервером. Проверка из Франкфурта покажет 80ms, а из Хельсинки — 200ms для того же endpoint. Multi-region мониторинг даёт полную картину: как видят ваш сервис пользователи из разных локаций.
Шаг 4: Отслеживайте тренды, не только алерты
Response time, который растёт на 5ms в день, через месяц станет на 150ms больше. Каждый день — в пределах нормы. Через месяц — заметная деградация. Графики response time за 7/30/90 дней показывают тренд, который ежеминутные проверки не покажут.
Диагностика: response time вырос, что делать
Мониторинг показал рост response time. Как найти причину? Алгоритм зависит от того, какая фаза выросла.
TTFB вырос, total time вырос пропорционально. Проблема на сервере. Проверяйте: slow queries в PostgreSQL (pg_stat_statements), CPU/memory utilization, количество active connections, ошибки в логах приложения. Частая причина — N+1 queries после деплоя нового кода.
TTFB в норме, total time вырос. Увеличился размер ответа или замедлилась передача. Проверяйте: включено ли gzip/brotli, не добавился ли неожиданно большой payload, нет ли проблем с CDN или пропускной способностью.
Response time вырос в одном регионе. Сетевая проблема между этим регионом и вашим сервером. BGP routing change, congestion на промежуточном hop. Обычно временно — проходит за часы.
Response time вырос на одном endpoint. Изолированная проблема: медленный database query, сломанный кэш, тяжёлая вычислительная операция именно на этом маршруте. Полезно, когда мониторите несколько endpoints отдельно.
Response time и SEO
Google учитывает скорость сервера при ранжировании. Официальная рекомендация — TTFB ниже 800ms для crawlable страниц. На практике: если ваш сайт отвечает за 200ms, а конкурент — за 2 секунды, при прочих равных вы получите преимущество в выдаче.
Более практичный эффект: Googlebot имеет crawl budget для каждого сайта. Если ваши страницы отвечают медленно, Googlebot за один визит проиндексирует меньше страниц. Новый контент появляется в поиске позже. Для блога с десятками статей — это прямая потеря органического трафика.
Оптимизация response time: практические шаги
На уровне приложения
Database queries. 80% проблем с TTFB — в SQL. Включите slow query log (>100ms). Добавьте индексы на частые WHERE-условия. Избегайте N+1: если список из 20 элементов делает 21 запрос, используйте JOIN или prefetch. ORM делает N+1 незаметным — проверяйте количество queries per request.
Кэширование. Redis/Memcached для часто запрашиваемых данных. HTTP-кэш (Cache-Control headers) для CDN и браузера. Full-page cache для страниц, которые не меняются каждую секунду. Правило: если данные не изменились за последнюю минуту — кэшируйте.
Async processing. Тяжёлые операции (отправка email, генерация отчётов, обработка изображений) — в фоновые задачи (Celery, Sidekiq, Bull). API должен принять запрос и вернуть 202 Accepted, а не блокировать клиента на 5 секунд.
На уровне инфраструктуры
CDN. Статические ассеты (JS, CSS, изображения) — через CDN. Это не только скорость, но и разгрузка origin-сервера. Для dynamic content — CDN edge workers (Cloudflare Workers, Lambda@Edge) для кэширования API-ответов.
Compression. gzip — минимум. Brotli — лучше (на 15-20% эффективнее). Проверьте, что ваш nginx/Caddy отдаёт Content-Encoding: br или gzip. Для API-ответов это может сократить transfer time в 3-5 раз.
Connection reuse. HTTP/2 мультиплексирует запросы по одному TCP-соединению. HTTP/3 (QUIC) убирает head-of-line blocking. Если ваш сервер всё ещё на HTTP/1.1 — обновление даст заметный прирост для клиентов, делающих несколько запросов.
Response time мониторинг для API
Для API response time — ещё критичнее, чем для веб-страниц. Страница грузится один раз; API-запросы летят десятками на каждое действие пользователя. Если один API call медленный — дашборд, собранный из 15 API calls, будет невыносимо тормозить.
Практика: разделяйте пороги по типам endpoints.
Read endpoints (GET /users, GET /products) — warning 200ms, critical 500ms.
Write endpoints (POST /orders, PUT /settings) — warning 500ms, critical 2s.
Health check (GET /health) — warning 50ms, critical 200ms. Health check должен быть мгновенным.
Heavy operations (GET /reports/monthly, POST /export) — warning 3s, critical 10s. Если дольше — переносите в async.
Чеклист: минимальный response time monitoring
1. Включите response time tracking для каждого HTTP-монитора. Записывайте TTFB и total time раздельно.
2. Определите baseline для каждого endpoint (24-48 часов данных).
3. Установите warning (2x baseline) и critical (5x baseline) пороги.
4. Мониторьте из нескольких регионов — разница в latency между регионами покажет проблемы с CDN или маршрутизацией.
5. Настройте графики за 7/30 дней — тренды важнее точечных значений.
6. Проверьте бизнес-импакт: если каждые 100ms стоят 1% конверсии, это конкретная цифра для обоснования оптимизации.
FAQ
What is response time in monitoring?
Response time is the total time from sending a request to receiving the complete response. It includes DNS resolution, TCP connection, TLS handshake, server processing, and data transfer. In monitoring, response time is the primary performance indicator — it tells you not just 'is it up' but 'how fast is it.'
What is TTFB and why does it matter?
TTFB (Time to First Byte) measures the time from sending a request to receiving the first byte of the response. It isolates server-side processing time from network transfer. A high TTFB means your server is slow to start responding — usually due to slow database queries, heavy computation, or resource contention.
What is a good response time for a website?
Under 200ms is excellent, under 500ms is acceptable for most sites, and over 1 second is poor. For APIs, user-facing endpoints should aim for under 200ms (p95). These numbers are for server response time, not full page load — add 1-3 seconds for the browser to render the page with all assets.
Should I monitor average response time or percentiles?
Percentiles, always. Average hides problems: if 99 requests take 100ms and 1 takes 10 seconds, the average is 199ms — looks fine. But p99 is 10 seconds — one in a hundred users has a terrible experience. Monitor p50 (median), p95, and p99.
How do I reduce high response time?
First, identify the bottleneck: is TTFB high (server-side problem) or is the transfer time high (large response)? For TTFB: optimize database queries, add caching, increase server resources. For transfer: compress responses, reduce payload size, use a CDN for static assets.
Does response time affect SEO?
Yes. Google uses page speed as a ranking factor, and server response time is a major component. Google's recommendation is TTFB under 800ms for crawlable pages. Consistently slow response times lead to reduced crawl frequency, which means new content gets indexed slower.