Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article3 min readViews1

How to Measure Website Response Time with curl: Codes, Redirects, and Timing

A quick HTTP check with a timeout: distinguish connection errors from server responses and do not treat cumulative timings as independent stages.

АльбинаCommunity author★ 97Discuss 0
Laptop and stopwatch for response time testing
In this article

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.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.