Что такое время ответа сайта?

Время ответа отвечает на простой вопрос: сколько проходит от обращения к вашему сайту до получения ответа? Система мониторинга обращается так же, как браузер, — HTTP-запросом, — и измеряет ожидание.

Это один из немногих показателей, который выдаёт проблему раньше, чем она станет сбоем. Сайт, который в понедельник отвечает за 300 миллисекунд, а в пятницу за 2 500, всё ещё «работает», но что-то изменилось.

Что происходит во время запроса

Один запрос проходит несколько этапов. Каждый занимает время, и каждый может тормозить по своей причине.

1. DNS-запрос. Имя example.com превращается в IP-адрес. Это быстро, если ответ закеширован поблизости, и медленно, если нет.
2. TCP-соединение. Клиент открывает соединение с этим адресом. Время зависит главным образом от расстояния и качества сетевого пути.
3. TLS-рукопожатие. Для адресов https обе стороны договариваются о шифровании, а клиент проверяет сертификат сервера. Это добавляет ещё несколько обменов.
4. Запрос и обработка на сервере. Запрос отправлен. Прежде чем ответить, серверу, возможно, нужно прочитать файлы, обратиться к базе данных или выполнить код приложения.
5. Первый байт. Приходит первая часть ответа. Время до этого момента называется временем до первого байта (TTFB).
6. Остальная часть ответа. Передаются оставшиеся данные.

Перенаправления добавляют времени. Если адрес отвечает перенаправлением, клиент повторяет все этапы для следующего адреса. Цепочка перенаправлений умножает затраты.

Время до первого байта и общее время

Чаще всего используют два показателя:

• Время до первого байта (TTFB) — это ожидание, пока не придёт первый байт ответа. С какого момента его считают, зависит от инструмента. В рекомендациях по скорости веб-страниц на web.dev оно отсчитывается от начала навигации, то есть включает перенаправления, DNS-запрос, установку соединения, согласование TLS и ожидание сервера. Некоторые инструменты измеряют только с момента отправки запроса, то есть без этапов подготовки. Сравнивая цифры из разных инструментов, проверьте, какое определение использует каждый.
• Общее время ответа — это время до тех пор, пока ответ не получен целиком. Для простой проверки страницы это TTFB плюс передача ответа.

Высокий TTFB при быстрых этапах соединения указывает на сервер или на приложение за ним. Медленный DNS или медленные этапы соединения указывают на сервер имён или сеть.

Время ответа и задержка

Задержка — это промежуток времени, который добавляет сама сеть, в основном то, сколько сигналу нужно, чтобы дойти. Расстояние имеет значение: запрос из Сингапура к серверу во Франкфурте идёт дольше, чем из Берлина, даже если сервер одинаково быстрый. Время ответа включает задержку плюс работу сервера.

Время ответа — это не время загрузки страницы

Проверка мониторинга запрашивает один адрес и измеряет ответ. Она не ведёт себя как браузер, который открывает страницу.

Браузер ещё скачивает изображения, таблицы стилей, скрипты и шрифты, выполняет скрипты и рисует страницу. Показатели этого опыта, такие как largest contentful paint или Core Web Vitals, описывают, что видит посетитель и когда. Для них нужен настоящий браузер.

У страницы может быть быстрый ответ сервера, а ощущаться она всё равно будет медленной из-за тяжёлых скриптов или больших изображений. Возможно и обратное. Поэтому время ответа HTTP лучше читать как меру сервера и пути до него, а не всего, что переживает посетитель. UptimeWire измеряет первое. Он не запускает браузер и не сообщает Core Web Vitals.

Почему время ответа меняется

• Трафик. Чем больше посетителей одновременно, тем больше они борются за одни и те же ресурсы.
• Тяжёлая фоновая работа. Резервные копии, импорт или задачи по расписанию могут отнимать ресурсы у посетителей.
• Медленные запросы к базе данных. Запрос, который был быстрым на небольших данных, может замедлиться по мере их роста.
• Кеширование. Страница из кеша может отдаваться во много раз быстрее, чем собираемая по запросу.
• Изменения на сайте. Релиз, плагин или новый вызов стороннего сервиса могут добавить времени за одну ночь.
• Сеть. Перегрузка и смена маршрутов влияют на время соединения и могут зависеть от времени суток.
• Откуда идёт проверка. Расстояние до сервера имеет значение, как описано выше.

Проверка из разных мест

Одно измерение показывает, как сайт отвечает из одного места. Сервисы, которые проверяют из нескольких мест, могут показать, медленный ответ везде или только в одном регионе. Сервер, который отвечает за 200 миллисекунд рядом со своим центром обработки данных и за 900 с другого края света, ведёт себя нормально. Сайт, медленный повсюду, указывает на сервер.

Сравнивая цифры во времени, держите место и интервал неизменными. Иначе изменение числа может объясняться методом, а не сайтом.

Пример расчёта

Проверка адреса https записывает:

Если считать от начала проверки, ответ начал приходить через 312 миллисекунд, из которых 83 миллисекунды ушло на подготовку (18 + 24 + 41). Оставшиеся 229 миллисекунд — это примерно путь запроса до сервера, подготовка ответа сервером и возвращение первого байта. Если проверка на следующий день покажет для первого байта 1 180 мс при тех же этапах подготовки, то лишнее время ушло на сервере, а не в DNS или сети.

Что считать хорошим

Единого правильного значения нет. В рекомендациях web.dev по TTFB, рассчитанных на страницы, которые посетители загружают в браузере, ориентиром «хорошо» служит 0,8 секунды и меньше, а «плохо» — больше 1,8 секунды. Считайте это ориентиром, а не целью для каждого сайта. API, к которому обращаются другие системы, может требовать гораздо более быстрого ответа. У страницы с тяжёлой работой на стороне сервера допустимо время и побольше.

Полезнее сравнивать сайт с его же нормой: что для него обычно и чем сегодняшний день отличается?

Время ответа в UptimeWire

UptimeWire отправляет HTTP-запрос на каждый настроенный вами адрес сайта и записывает, сколько времени это заняло, вместе с результатом. Первый байт отсчитывается от начала проверки, поэтому включает этапы подготовки и все перенаправления, а общее время охватывает всю проверку.

Разбивка по этапам входит в подробный отчёт о проверке, который доступен начиная с тарифа Starter. На тарифе Free видно время ответа каждой проверки, но без деления на этапы.