TTFB — не метрика для отчёта, а ранний сигнал проблем в цепочке CDN

TTFB — не метрика для отчёта, а ранний сигнал проблем в цепочке CDN

Если время до первого байта растёт, причина часто не в «медленном сайте», а в одном из звеньев: DNS, TLS, origin, кэш или перегрузка на стороне приложения. По TTFB удобно ловить деградацию раньше, чем начнут жаловаться пользователи.

Что проверять в мониторинге:
• разделяйте TTFB по кэшу: HIT, MISS, BYPASS — иначе среднее значение будет вводить в заблуждение;
• сравнивайте точки измерения: edge, регион, origin — так видно, где появляется задержка;
• смотрите не только среднее, но и p95/p99: именно хвосты чаще ломают пользовательский опыт;
• фиксируйте корреляцию с 5xx, ростом RTT и очередями на origin.

Для Cloudflare важно не путать быстрый edge с быстрым приложением. Низкий TTFB при HIT может маскировать деградацию origin, а высокий TTFB при MISS часто указывает на тяжёлый backend, долгие запросы к БД или лишние редиректы. Отдельно контролируйте cache status и response headers — без этого диагностика будет неполной.

Хорошая практика — ставить алерты не на абсолютное число, а на отклонение от базовой линии по каждому ключевому URL. Стабильность инфраструктуры — залог масштабируемости.