Website Response Time Test
Measure how long your website takes to start responding, split into the four phases that make up the wait — DNS, connection, TLS and first byte.
After the report loads, open its 'Technical detail' section — the Timing breakdown draws DNS, TCP, TLS and time-to-first-byte as separate bars, so the slow phase stands out at a glance.
Response time is the wait before your website even starts to arrive — the gap between a visitor hitting Enter and the first byte coming back. Run the test above and PingStuff times that gap in four phases: looking up your domain (DNS), opening the connection (TCP), negotiating encryption (TLS) and waiting for the server to begin answering (time to first byte).
The split matters more than the total, because each phase points at a different culprit. Slow DNS implicates your nameservers. A slow connection or handshake usually means distance or network trouble between the visitor and the server. A slow first byte after a quick handshake means the server itself is grinding — often the application or its database. One number can't tell you which of those you have; four can.
What to do next
- Find the widest bar in the timing breakdown and focus there — improving the dominant phase is the only change that meaningfully moves the total.
- Run the test two or three times before drawing conclusions. The first run can hit cold caches along the way; a pattern across runs is evidence, a single number is an anecdote.
- If every phase looks quick but users say the site feels slow, the delay is in what happens after the first byte — heavy images and scripts — which is a page-weight problem, not a response-time one. Our guide on why websites become slow walks through telling the two apart.
A one-off number tells you about today; the trend tells you the truth. PingStuff monitoring records response time on every scheduled check so you can watch it drift before it becomes downtime, and emails you if the site stops responding — SMS alerts are rolling out. Start monitoring free.
Frequently asked questions
What is a good website response time?
As a rough, honest guide: under 200 ms feels instant, under 800 ms is perfectly fine for most sites, and beyond 3 seconds you are actively losing visitors. Bear in mind any single test is measured from one location — a server far from that vantage point adds real milliseconds that aren't your application's fault.
What is the difference between response time and page load time?
Response time ends when the first byte of the page arrives; page load time ends when the whole page — images, scripts, styles — has been fetched and rendered. A site can respond in 100 ms and still take eight seconds to finish loading heavy assets. This test measures the former.
Why is my response time different every time I run the test?
Some wobble is normal: DNS answers get cached and expire, the server is busier one minute than the next, and internet routes shift. Judge the typical value and the trend rather than any one run — and treat a sudden, sustained jump as the signal worth investigating.
How do I track response time over time?
Re-running a manual test now and then will never show you a trend. PingStuff monitoring checks your site on a schedule, keeps the response-time history, and emails you the moment the site stops responding — and texts verified Canadian mobile numbers.