Disclosure: Disclosure: We may earn commissions from affiliate links in this 2026 guide on measuring TTFB and server response time; this strictly independent review ensures
TTFB is the interval from the start of an HTTP request until the first response byte arrives. Depending on the tool and connection state, it can include DNS lookup, TCP connection, TLS negotiation, server queueing, cache lookup, application execution, and network return time. “Server response time” is often used loosely, so publish the exact fields.
Understand the timing phases
| Phase | What happens | Main owner |
|---|---|---|
| DNS lookup | Domain resolves to an address | DNS provider/resolver |
| Connect | TCP or QUIC path establishes | Network and server/edge |
| TLS | HTTPS security negotiates | Network, certificate, server/edge |
| Request wait | Cache or application prepares response | Host, WordPress, database |
| Transfer | Response bytes arrive | Network and response size |
| Render | Browser builds and paints page | Front-end code and device |
TTFB ends at the first byte. It does not measure complete transfer or visual rendering.
Editor's Pick. Our team's current top recommendation for this category. (Affiliate link coming soon — we only link programs we've vetted.)
Method 1: Browser developer tools
Open an incognito window, launch developer tools, select the Network panel, and load the page. Click the document request, not an image. The Timing panel shows queueing, DNS, connection, SSL, request sent, waiting, and download, although labels vary by browser.
Disable cache only when measuring a cold browser state. Repeat with cache enabled for normal navigation. Close extensions and keep device/network conditions consistent. Export a HAR file when sharing evidence, but inspect it for authentication tokens and personal data first.
Browser measurements are excellent for connecting TTFB to the waterfall. They are less suitable for dozens of repeatable runs unless automated.
Method 2: Command-line timing
An HTTP client such as curl can expose numeric timing fields for name lookup, connection, TLS, pre-transfer, start-transfer, and total. Use a current secure binary and quote the URL. Follow redirects explicitly and record whether the reported start-transfer belongs to the first response or final destination.
Run at least 20 requests and save machine-readable output. Calculate median, p75, p95, and maximum. If you reuse connections, say so; a fresh process commonly creates a new connection, while a benchmark tool may pool them.
Do not disable TLS verification for convenience. A certificate failure is a real availability problem.
Method 3: WebPageTest
WebPageTest runs a real browser with specified location, device, connection, and repeat view. The waterfall separates DNS, connect, SSL, TTFB, and content download. Run at least three tests and use the median result.
This method captures user-facing context, including redirects and service workers. It also adds controlled network throttling, so its TTFB may differ from a nearby command-line probe. Preserve the test URL and settings.
Method 4: continuous monitoring
Use an uptime or synthetic-monitoring service to request a lightweight endpoint every minute or five minutes from several regions. Record percentiles over days and alert on sustained latency or errors.
Monitor both a cacheable page and a safe application endpoint. A CDN can keep the cached homepage fast while the origin database is failing. Multi-region confirmation reduces false alarms from one probe network.
Separate cache states
Warm an anonymous page and confirm a cache HIT through the provider's documented header. Run 20–30 measurements. Then purge the exact URL before each MISS trial. Finally, test a deliberate BYPASS such as WordPress search or a synthetic logged-in route.
Do not use private content in public testing tools. Never append a random query string and assume it creates a valid cache miss; some caches ignore queries while others treat each as a new key.
SiteGround documents x-proxy-cache HIT/MISS/BYPASS. LiteSpeed, Cloudflare, Varnish, and managed hosts expose other headers. Interpret only documented values.
Choose test regions
Use one probe near the origin to isolate server/application work and another near the audience to measure real network distance. For global sites, include North America, Europe, and Asia-Pacific.
Report regions independently. Averaging them conceals a poor geography. If a CDN serves HTML at the edge, identify the edge location and test an origin MISS too.
Calculate percentiles
Sort results. The median is the middle observation; p75 is slower than 75% of observations; p95 exposes tail latency. With only 20 requests, p95 is near the slowest and remains noisy, so use more data for formal claims.
Avoid arithmetic averages alone because one timeout can distort them. Publish request count and errors. Excluding failures creates a falsely fast dataset.
For a light cached page near its serving layer, a stable median under roughly 200–400 ms is a useful target. Google's historical server-response recommendations and tool labels should not be mistaken for a universal hosting pass/fail. Dynamic applications need workload-specific budgets.
Diagnose a slow TTFB
If DNS is slow, review authoritative DNS and resolver path. If connect/TLS is slow only in distant regions, move the origin or use a CDN. If wait time is high on MISS but HIT is fast, inspect WordPress, PHP, database queries, and object caching.
If p95 rises under concurrency, watch PHP workers, CPU, memory, entry processes, database locks, and external API calls. A plugin that waits two seconds for a licensing server will remain slow on better storage.
If all states are slow, verify redirects, CDN routing, IPv6, and server location. A stale AAAA record may send some clients elsewhere.
TTFB and Core Web Vitals
TTFB is not itself one of the three Core Web Vitals, but it consumes time before LCP content can download. Improving TTFB gives the browser more of the 2.5-second LCP budget.
Low TTFB cannot guarantee good LCP, INP, or CLS. Optimize the LCP image and CSS, reduce JavaScript long tasks, and reserve layout dimensions. Use PageSpeed Insights field data when available.
Compare hosts fairly
Use identical WordPress fixtures, PHP versions, regions, CDN states, and cache configurations. Test comparable plan costs. Record the date because platforms change.
Report HIT, MISS, and BYPASS separately with raw values. A $30 edge-managed host and a $3 shared plan can both be useful, but the premium product should be judged on dynamic consistency, global spread, support, and recovery as well as its minimum.
FAQ
Is TTFB the same as ping?
No. Ping measures network round-trip using a different protocol. TTFB includes HTTP connection and server or cache work.
Does DNS affect TTFB?
It may, depending on tool definition and cache state. Publish DNS separately whenever possible.
Why is the second request faster?
DNS, TLS sessions, connections, browser cache, CDN, page cache, PHP OPcache, and object cache may be warm. Both cold and warm states are useful.
How often should I measure?
Run detailed tests after major changes and continuous lightweight monitoring for important sites. Recheck multiple times of day before drawing conclusions.
Recommendation
Measure TTFB with phase-aware tools, at least 20–30 requests per cache state, multiple regions, and percentile reporting. Preserve errors and raw output. Use the waterfall to locate DNS, network, cache, application, or database delay, then change one layer and repeat the identical test.