Тест времени ответа

Что входит в это число

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

Монитор работает иначе: он ведёт отсчёт, пока не придёт тело ответа (до 1 МБ), поэтому время ответа на графике монитора для того же URL выше, чем здесь. Сравнивайте сравнимое.

Почему первый запрос медленный

Холодному запросу приходится пройти несколько обменов с сервером, прежде чем тот что-либо увидит: один на DNS, один на TCP, один-два на TLS и ещё один на сам запрос. При RTT в 100 мс новое соединение стоит как минимум 300 мс, прежде чем вернётся хотя бы один байт страницы, даже если приложение отвечает мгновенно. Поэтому быстрый тест до далёкого региона может выглядеть плохо на совершенно здоровом сервере.

Есть и физический предел. Свет в волокне проходит около 200 км за миллисекунду, так что от Франкфурта до Нью-Йорка, примерно 6 500 км, RTT не может быть меньше 65 мс, а реальные маршруты дают скорее 90–110 мс. Если ваши посетители в одном регионе, важно то число, которое измерено именно из этого региона.

Как читать цвета

Строки зеленеют ниже 500 мс, становятся янтарными от 500 мс и выше и краснеют, когда запрос не удался. Рекомендации Google по скорости веба считают хорошим TTFB до 800 мс на 75-м процентиле, так что 500 мс — осторожная граница для одного замера. Типичные страницы выглядят так:

• 50–150 мс: кешированная страница с узла CDN или статический сайт на близком хосте.
• 200–500 мс: динамическая страница с кешем объектов или далёкий, но здоровый origin-сервер.
• 800–1 500 мс: некешированная страница WordPress или WooCommerce, чаще всего из-за плагина или медленного запроса к базе данных.
• Больше 2 000 мс: хост перегружен, либо приложение делает что-то дорогое при каждом запросе.

Один замер — ещё не измерение

Запустите тест три раза, прежде чем верить результату. Первый вызов может попасть на холодный кеш, холодный пул соединений или PHP-воркер, которому нужно стартовать. Настоящую картину даёт распределение. Допустим, 100 проверок: 90 из них по 200 мс и 10 по 3 000 мс. Среднее — 480 мс, медиана — 200 мс, а 95-й процентиль — 3 000 мс. Только процентиль показывает, что у одного посетителя из десяти дела плохи; именно поэтому оповещения по порогу медленной работы лучше, чем оповещения по отдельным замерам.

С регионами тоже осторожнее. Страница перечисляет Амстердам и Лондон, но сервис проверки может ответить только из одного из них за один вызов; строки без ответа показывают н/д. Воспринимайте каждую строку как отдельный замер из этой точки наблюдения.

Отслеживание во времени

Монитор записывает время ответа при каждой проверке и показывает его на графике по регионам, так что регрессия после деплоя или обновления плагина видна как ступенька на линии. На тарифе Free интервал — 5 мин; Starter сокращает его до 1 мин, а Pro и Agency — до 30 с. Оповещения, когда время ответа держится выше выбранного вами порога, входят в тариф Pro за $29 в месяц и выше; об этом рассказывает раздел мониторинг времени ответа. Выбирайте порог по данным за неделю, примерно вдвое выше обычного значения, а не по медиане.