21 September 2026 · One command a day
How do I measure a website's response time from the command line?
This command fetches a URL and prints two things: the HTTP status code and how long the whole request took. It discards the page itself, so all you get back is one short line. You reach for it when a site feels slow, or when you want a number to compare before and after a change.
The command
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.comThe -s flag makes curl silent, so it does not draw a progress meter. -o /dev/null sends the downloaded page to nowhere, because you do not want to read it. -w tells curl to write out a format string once the transfer has finished. Inside that string, %{http_code} is the status code the server returned and %{time_total} is the number of seconds from the start of the request to the last byte. The \n at the end adds a newline so your prompt appears on a fresh line. Swap example.com for the site you want to test.
What you will see
200 0.187342The first number is the status code. 200 means the page was served normally. The second is the total time in seconds, so this page came back in under a fifth of a second. For a normal page, anything under half a second is healthy and anything over two seconds is worth looking into. If you see 000 with a tiny time, curl could not connect at all. That usually means DNS, a firewall, or the server being down. Drop -s to see the reason.
When to use it
- A site feels slow. Run the command on the server itself, then from your own machine. If the server is fast but your machine is slow, the delay is in the network rather than your app.
- Before and after a change. Take a few readings, enable caching or restart the app, then take a few more. You now have numbers instead of a feeling.
- Catching intermittent slowness. Wrap it in a loop to take a reading every second and watch for spikes:
for i in $(seq 1 10); do curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com; sleep 1; doneWatch out for
Curl does not follow redirects unless you ask it to. If your site sends visitors from http to https, or from the bare domain to www, you will see 301 and a very fast time. That is the time to the redirect, not to the page. Add -L to follow redirects and the total will cover the whole chain. It is also worth running the command more than once. The first request often includes a DNS lookup and a TLS handshake that later requests skip, so look at the pattern rather than a single reading.
Questions people ask
Can I see where the time goes?
Yes. Add more variables to the -w string, such as %{time_namelookup}, %{time_connect}, %{time_appconnect} for the TLS handshake and %{time_starttransfer} for the time to first byte. Each is measured from the start of the request, so together they form a timeline. If you want the response headers as well, see how to check a website's status code and headers from the command line.
Why is it fast in curl but slow in my browser?
Curl fetches one document and nothing else, while a browser also loads images, scripts and stylesheets. A fast curl time with a slow browser usually means the page's assets are the problem rather than the server.
Running this on the server itself is the quickest way to tell whether the delay is in your app or somewhere on the way to it. That is only possible on a server you control. You can get the same VPS with 20% off at https://asksteves.co.uk/vps. Affiliate link.
Everything on this blog runs on one Hostinger KVM 8. This link takes 20% off the same box.
Affiliate link.