TTFB не лечат «ускорением CDN»: сначала находят, где теряется первая миллисекунда

TTFB не лечат «ускорением CDN»: сначала находят, где теряется первая миллисекунда

TTFB — это не только скорость ответа origin. В цепочке участвуют DNS, TLS, кэш на edge, прокси-слой и сам бэкенд. Если мерить только среднее значение, вы пропустите деградацию на отдельных PoP, на конкретных маршрутах или под нагрузкой. Для бизнеса это прямой риск: страница «в целом открывается», но отдельные пользователи получают медленный первый байт и уходят раньше загрузки контента.

Что стоит мониторить постоянно:
• TTFB по географиям и ASN, а не одной цифрой по всему трафику.
• Разделение edge hit / miss: кэш может выглядеть здоровым, пока miss-цепочка уже тормозит.
• P95 и P99 вместо среднего: именно хвосты ломают UX и конверсию.
• Разницу между origin time, TLS handshake и waiting time в логах.

Если TTFB растёт только на miss, ищите узкое место в origin, БД или сетевом пути до backend. Если растёт и на hit, проверяйте edge-логи, правила Worker/Transform, лимиты на стороне приложений и лишние запросы к сторонним сервисам. Нельзя лечить задержку без разложения по этапам — это почти всегда приводит к ложным выводам и лишним изменениям в конфигурации.

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