Как измерить ответ сайта через curl: код, перенаправления и время
Короткая проверка HTTP с ограничением времени: отделяем ошибку соединения от ответа сервера и не принимаем накопительные тайминги за независимые этапы.
В этой статье
Страница открывается медленно, но непонятно, где задержка: при поиске адреса, подключении или ожидании ответа приложения. curl помогает получить повторяемый замер без интерфейса браузера. Это проверка одного HTTP-запроса; она не измеряет загрузку всех ресурсов страницы и выполнение JavaScript.
Подготовьте адрес и границы проверки
Нужен установленный curl. Выберите обычную публичную страницу, чтение которой не изменяет данные. Не используйте адрес выхода из аккаунта, подтверждения заказа или административного действия. После команды ниже введите полный адрес страницы:
read -r TARGET_URL
Затем выполните ограниченный по времени запрос:
curl -sS -o /dev/null --connect-timeout 10 --max-time 30 -w 'code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' "$TARGET_URL"
Тело ответа не сохраняется. Ошибки остаются видны, а общий срок выполнения ограничен. Команда делает обычный GET-запрос; изменение метода на HEAD может дать другой ответ приложения и не всегда подходит для сравнения с браузером.
Сначала прочитайте код и ошибку
HTTP-код показывает ответ сервера, если он получен. Ошибка DNS, TLS или соединения находится на другом уровне: при ней обычного ответа HTTP может не быть. Не объявляйте сайт исправным только потому, что утилита завершилась без транспортной ошибки: сервер мог вернуть страницу с ошибкой.
Команда не следует перенаправлениям автоматически. Это полезно для первого шага: можно увидеть, что исходный адрес возвращает перенаправление. Для проверки всей цепочки добавляют -L и разумный предел, например --max-redirs 5, сохраняя общий тайм-аут. Следуйте только ожидаемой цепочке своего сайта.
Тайминги считаются от начала запроса
Показатели DNS, соединения и первого байта — временные отметки от старта операции, а не отдельные длительности, которые нужно складывать. Полное время уже включает предыдущие этапы. При перенаправлениях и повторном использовании соединений интерпретация становится сложнее.
Пример: первый байт появляется заметно позже установления соединения. Это основание изучить обработку запроса и сетевой путь, но не готовое доказательство медленного SQL. Между клиентом и приложением могут находиться TLS, прокси, CDN и другие компоненты.
Проведите несколько сопоставимых измерений
Повторите запрос небольшое число раз с той же машины и к тому же адресу. Первый ответ может отличаться из-за прогрева кэша. Не превращайте проверку в бесконечный цикл: это изменит нагрузку, которую вы пытаетесь измерить.
Зафиксируйте время, точку проверки, код, наличие перенаправления и разброс задержки. Если сравниваете разные машины, учитывайте их сети и DNS. Успешный запрос из дата-центра не гарантирует ту же скорость у посетителя из другого региона.
Краткая карта проверки
Сигнал | Первый вопрос | Следующая проверка |
|---|---|---|
Нет HTTP-ответа | На каком этапе произошёл отказ? | DNS, соединение и TLS |
Перенаправление | Ожидается ли другой адрес? | Цепочка с ограничением переходов |
Поздний первый байт | Где проходит запрос до приложения? | Прокси, приложение и зависимости |
Быстрый HTTP, медленный интерфейс | Какие ресурсы загружает браузер? | Сеть браузера и клиентский код |
Что проверять после исправления
Повторите исходный запрос с теми же ограничениями, затем откройте страницу в браузере. Если HTTP-ответ стал быстрым, но интерфейс всё ещё долго загружается, следующая задача относится к ресурсам страницы и клиентскому коду. Не отключайте проверку сертификата ради красивого результата: это меняет условия запроса и скрывает отдельную проблему HTTPS.
The page opens slowly, but it is unclear where the delay occurs: during address lookup, connection, or waiting for the application response. curl helps obtain a repeatable measurement without a browser interface. This checks a single HTTP request; it does not measure loading all page resources or executing JavaScript.
Prepare the address and check boundaries
You need curl installed. Select a standard public page whose reading does not change data. Do not use an address for logging out, order confirmation, or any administrative action. After entering the command below, type the full page address:
read -r TARGET_URL
Then execute a timed request:
curl -sS -o /dev/null --connect-timeout 10 --max-time 30 -w 'code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' "$TARGET_URL"
The response body is not saved. Errors remain visible, and the total execution time is limited. The command performs a standard GET request; changing the method to HEAD may yield a different application response and is not always suitable for comparison with a browser.
First, read the code and error
The HTTP code shows the server response if one was received. DNS, TLS, or connection errors occur at a different level: in such cases, a standard HTTP response may be absent. Do not declare a site fixed simply because the utility finished without a transport error: the server may have returned an error page.
The command does not follow redirects automatically. This is useful for the first step: you can see that the original address returns a redirect. To check the entire chain, add -L and a reasonable limit, such as --max-redirs 5, while keeping the overall timeout. Follow only the expected chain for your site.
Timings are counted from the start of the request
DNS, connection, and first-byte metrics are timestamps from the operation start, not separate durations to be summed. The total time already includes previous stages. With redirects and connection reuse, interpretation becomes more complex.
Example: the first byte appears noticeably after the connection is established. This is a reason to examine request handling and the network path, but not proof of slow SQL. Between the client and the application may sit TLS, proxies, CDNs, and other components.
Perform several comparable measurements
Repeat the request a small number of times from the same machine to the same address. The first response may differ due to cache warming. Do not turn the check into an infinite loop: this changes the load you are trying to measure.
Record the time, check point, code, presence of a redirect, and delay spread. If comparing different machines, account for their networks and DNS. A successful request from a data center does not guarantee the same speed for a visitor from another region.
Quick verification checklist
Signal | First question | Next check |
|---|---|---|
No HTTP response | At what stage did the failure occur? | DNS, connection, and TLS |
Redirection | Is another address expected? | Chain with redirect limits |
Late first byte | Where does the request go before reaching the application? | Proxy, application, and dependencies |
Fast HTTP, Slow Interface | What Resources Does the Browser Load? | Browser Network and Client-Side Code |
What to check after the fix
Repeat the original request with the same constraints, then open the page in a browser. If the HTTP response is fast but the interface still loads slowly, the next task concerns page resources and client-side code. Do not disable certificate verification for a pretty result: this changes the request conditions and hides a distinct HTTPS issue.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.