Webpage Response Time Checker

What the batch reports

Paste a list of addresses and the checker requests each one from the server. Every row shows the URL, the response time in milliseconds and a speed band. The status tab shows the HTTP code, and the size tab shows the downloaded bytes.

The summary adds the average response time, the success rate, the total size and a distribution of status codes. That makes the page useful for comparing a group of templates, a sitemap sample or a set of endpoints after a release.

The average is not a ranking

An average is sensitive to one outlier. If nine pages answer in 200 milliseconds and one takes five seconds, the average looks poor even though most of the site is healthy. Read the individual rows before you quote the average.

The success rate counts 2xx and 3xx responses as successful. A redirect is therefore not a failure, but it is also not the final page. Check the status column when the success rate and the response times tell different stories.

Comparing pages on one site

Use the same host, the same protocol and the same URL style for every row. Mixing www and non-www, http and https, or trailing-slash variants adds redirects and makes the comparison noisy.

If one page is consistently slower, look at what is different: a heavier database query, a larger HTML document, a missing cache, a third-party call made on the server or a page that is generated on every request. The checker tells you where to look, not why the page is slow.

Run the batch more than once. A single run after a deploy may hit cold caches and compiled templates, which makes every page look slower than it will be a minute later.

Comparing different sites

Cross-site comparisons are rough. Distance, peering, CDN placement, TLS setup and server capacity all differ. A nearby small site can beat a distant large one without being better engineered.

All requests originate from one location, so the result describes the path from that location, not from your users around the world. Use it for a sanity check, not for a global performance verdict.

Cache and repeat runs

The first request to a page may populate a server cache, a CDN edge or an opcode cache. The second request can be much faster. Decide whether you are measuring the cold path or the warm path, and keep that choice consistent.

Do not average a cold run with a warm run and present the result as a single number. Label the runs, or discard the warm-up and report the steady state.

What it does not measure

It does not render the page, load images, execute JavaScript or measure layout. It does not break the timing into DNS, connect, TLS and time to first byte. It does not simulate concurrent users or test from multiple regions.

It sends a simple request without your cookies or authentication. A page that behaves differently for logged-in users will not be measured in its personalised state.

Step by step

1. Paste up to ten URLs, one per line.
2. Press the check button and wait for the batch to finish.
3. Read the response tab first, then the status and size tabs.
4. Open the summary for the average and success rate.
5. Repeat the same list once to separate cold from warm results.
6. Investigate the slowest row, not just the average.

Privacy and limits

The URLs are sent to the server for checking. The tool does not require an account and does not keep a history. Do not submit internal hostnames, admin paths or URLs with secret query parameters.

Each address must be a public HTTP or HTTPS URL of up to 2,048 characters. The checker accepts at most ten per run and does not support custom headers, POST bodies or authentication.

Reading the three tabs together

A slow response with a 200 status and a small document points to the server or the network. A fast response with a 301 and a tiny body is a redirect doing its job. A fast 500 is still a failure; speed does not rescue an error.

Use the status tab to confirm the response is the one you expected, then the size tab to see whether a large document explains the time. If the status is a redirect, the measured time covers the redirect response, not the destination page.

Building a simple baseline

Pick five to ten representative URLs: the homepage, a category, a product or article, a search page and a checkout or contact page. Run them at roughly the same time of day and save the table. Repeat the same list after a release or a hosting change.

Compare medians rather than single runs, and note the date, the server option and whether the cache was warm. A baseline with no context becomes a misleading screenshot three months later.

Common false alarms

The first request after a deploy can be slow because caches are cold. One outlier can drag the average up. A VPN, a corporate proxy or a CDN edge under load can change the path without any change to the site.

A bot challenge can return a small block page very quickly, which looks like an improvement. Check the status and size before celebrating a sudden drop in response time.

Reporting the result

State the URL list, the date, the server location, the number of runs and whether the cache was warm. An average without that context is not reproducible, and a colleague cannot tell whether a change is real or a different path.

Do not present the batch average as user-perceived page speed. It covers only the document response; the browser still has to load and render everything else.

Keep the saved table with the release note, so the next comparison starts from the same list. Repeat it after the next deploy to see whether the change moved the median.

Label the warm-up run and exclude it from the comparison.

Frequently Asked Questions