TTFB против времени отклика против задержки: что измеряет каждое

Что означает каждый термин

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

Время до первого байта (TTFB) измеряется с момента, когда клиент начинает запрос, до момента, когда до него доходит первый байт ответа. В этот отрезок входят DNS-поиск, TCP-соединение, TLS-рукопожатие, время, которое запрос проводит в пути, все, что делает сервер, чтобы сформировать ответ, и обратный путь. Поэтому TTFB всегда больше одного кругового пути, обычно в несколько раз.

Время отклика - самый расплывчатый из трех терминов. Большинство инструментов мониторинга используют его для обозначения общего времени завершения запроса, от первого пакета до последнего байта тела. Некоторые инструменты используют его как синоним TTFB. Прежде чем сравнивать два числа с подписью "время отклика", проверьте, на каком именно моменте каждый инструмент остановил счетчик.

Как измеряется каждый показатель

Задержка получается из ICMP echo, именно это отправляет ping, либо из замера времени TCP-рукопожатия, когда ICMP заблокирован. TTFB и общее время дает сам HTTP-клиент. Один вызов curl печатает все границы сразу:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Каждое значение накопительное с начала запроса, поэтому читайте их как границы, а не как длительности. Чтобы получить длину конкретного этапа, вычтите предыдущее значение.

Какое именно число показывает ваш инструмент

Каждый инструмент показывает свой срез одного и того же запроса, и это обычная причина, по которой два замера одного сайта расходятся:

• ping показывает только задержку кругового пути, без учета работы сервера
• curl -w показывает все границы из списка выше, что делает его эталоном при расхождении чисел
• Инструменты разработчика в браузере показывают TTFB как этап ожидания запроса, отдельно от этапа загрузки под ним
• Lighthouse и PageSpeed показывают время отклика сервера, которое для запроса документа и есть TTFB
• Мониторы аптайма показывают время отклика, чье определение меняется от продукта к продукту и включает установку соединения оттуда, откуда шла проверка
• Мониторинг реальных пользователей показывает полевой TTFB, агрегированный по реальным посетителям в реальных сетях

Как выглядит хорошее число

Задержка ограничена географией. Меньше 30 мс - нормально внутри одного города, 50-100 мс - через континент, 150-250 мс - между континентами. Маршрут, показывающий значение сильно выше ожидаемого для расстояния, указывает на плохой путь, а не на медленный сервер.

Для TTFB web.dev считает хорошим значение 800 мс и меньше, а плохим - все, что выше 1,8 секунды, тогда как аудит времени отклика сервера в Lighthouse начинает проваливаться выше 600 мс. Стремитесь к значению меньше 600 мс для запроса документа и считайте 200 мс целью для всего, что кэшируется или отдается статически.

Общее время отклика зависит от размера того, что вы отправляете, поэтому универсальной цифры не существует. Измерьте собственную базовую линию в обычный день и считайте сигналом именно отклонение от нее, а не абсолютное число.

Чтение разрывов между показателями

Отдельные числа значат меньше, чем расстояние между ними, потому что каждый разрыв указывает на свою подсистему:

• TTFB минус задержка кругового пути - это примерно то, сколько времени сервер провел «в раздумьях». Если это самая большая часть, проблема в коде приложения, медленном запросе или холодном кэше
• Соединение минус DNS-поиск - это один круговой путь на TCP-рукопожатие. Если это значение намного больше измеренной вами задержки, сетевой маршрут перегружен или неверно проложен
• TLS минус соединение - это стоимость рукопожатия, обычно один-два дополнительных круговых пути, и большое значение указывает на проблемы с цепочкой сертификатов или возобновлением сессии
• Общее время минус TTFB - это время передачи. Если оно доминирует, ответ слишком велик или соединение слишком медленное, и никакая настройка сервера тут не поможет
• DNS-поиск сам по себе после кэширования должен занимать всего несколько миллисекунд. Стабильно медленный поиск - проблема резолвера или авторитетного сервера имен, а не веб-сервера

То же чтение работает и в обратную сторону, когда медленно только из одной локации. Одинаковое время «раздумий» сервера везде, с разницей, целиком лежащей в задержке и передаче, означает, что сервер в порядке, а маршрут - нет. Прежде чем трогать приложение, запустите проверку из нескольких мест.

Измерение в одном месте

Чтобы увидеть эти цифры для страницы, не собирая их вручную, запустите тест скорости страницы, который загружает страницу из внешней локации и разбивает загрузку на этапы. Руководство по времени отклика сервера разбирает тот же замер из командной строки. Разовый запуск рассказывает только об этом конкретном моменте, поэтому если показатель важен, поставьте на него плановую проверку: HostTracker измеряет время отклика при каждой проверке из 300+ точек в 158 городах, и именно это превращает разовый замер в базовую линию, относительно которой можно заметить регрессию. Больше определений - в разделе о понятиях мониторинга.