What is Response Time?
Website response time is how long a browser waits for a web server to begin returning a requested page or resource. It is commonly measured as time to first byte (TTFB), which includes connection, network, and server-processing delays. TTFB ends at the first byte, not after the full response downloads or the page renders.
More About Response Time
Factors that affect response time
The biggest factors are the web server's processing power, how much traffic it's handling, the complexity of the request, and the distance between the visitor and the server. A static file can be sent back almost immediately. A dynamic page that runs database queries before it can answer takes longer, and every extra network round trip adds to the wait.
Slow responses cost real visitors. In a 2006 experiment described by Google's then-VP Marissa Mayer, search results pages that took half a second longer to generate saw a 20% drop in traffic. Speed affects your search visibility too: page speed, including how fast the server responds, is a ranking factor in Google Search.
Good response-time targets
Aim for a TTFB of 0.8 seconds or less. Google's web.dev guidance (last updated November 18, 2025) counts 0.8 seconds or less as good and anything over 1.8 seconds as poor. Treat both numbers as a rough guide rather than a pass-fail test: a site that renders full pages on the server can get away with a slightly higher TTFB, while a site that relies on JavaScript to fill its pages with content needs the lowest TTFB it can manage.
Response time vs. page load time
Response time ends when the answer starts arriving; page load time runs until the page is fully rendered. Speed tools report response time as TTFB (time to first byte), and the name is literal: the clock stops at the first byte, not when the download finishes.
- Response time (TTFB): everything up to the moment the first byte of the response arrives, including any redirect, the DNS lookup, connection and TLS setup, and the server's processing.
- Page load time: the whole journey until the page is rendered, including downloading and running every image, stylesheet, and script.
If your TTFB looks fine but the page still feels slow, the delay is happening after the first byte, in the front end.
Measuring response time
Open the Network panel in Chrome DevTools and read the TTFB on the document request, or run a free WebPageTest scan. For field data (what real visitors experience over time), use the Chrome User Experience Report or the web-vitals JavaScript library. Test from multiple locations: a fast result from your own city says nothing about visitors on another continent.
Improving response time
Start with the fixes that shorten the wait for the first byte:
- Cache full pages: a full-page cache stores the finished HTML so the server can skip rebuilding it for repeat requests.
- Optimize dynamic pages: if a page takes seconds to generate, profile its slow database queries first.
- Cut unnecessary redirects: each redirect adds a full round trip before the final page's first byte can arrive.
A CDN improves response time only when it caches or serves the requested page or file at the edge, closer to the visitor. If it only delivers your images, stylesheets, and scripts, it speeds up page loading after the first byte; the HTML document's TTFB still depends on your origin server. Turn on full-page caching at the edge if your CDN offers it.
For step-by-step instructions, start with our guide 10 Ways to Optimize Your WordPress Website for Speed.
Frequently Asked Questions
- Narrow it down first. If a single page is slow, suspect that page's database queries or plugins. If the whole site is slow even at quiet times, raise it with your host. Slowness only during traffic spikes points to capacity or missing caching.
- Mostly cache state and location. The first request after a cache clears is far slower than repeat requests served from the cache, and a test server near your host reports faster times than a distant one. Run each test several times and note whether the page was cached.
- Yes, 100 ms is fast: Jakob Nielsen's 2010 response-time limits put 0.1 seconds as the point a response feels instantaneous. But a fast TTFB doesn't guarantee a fast page. Test cached and uncached requests, then check downloads, rendering, and later server requests before ruling out a problem.
- No. Monitor response time is how quickly a pixel changes from one color to another, a display spec measured in milliseconds. It has nothing to do with how fast a web server answers a browser's request.
Web Hosting
Our Web Hosting plans offer a user-friendly interface and flexible options to fit your needs, with a 30-Day Money-Back Guarantee.
Web Hosting Plans