Disclosure: This post contains affiliate links; we may earn a commission at no extra cost to you.
Time to first byte is the interval from starting a request until the first response byte arrives. It is often called server response time, but an end-to-end TTFB also includes DNS, connection, TLS, network distance, proxy or CDN work, and application processing.
To measure it responsibly, use several tools, separate cold and warm cache, test from relevant regions, repeat samples, and preserve raw output. One browser result is not a benchmark.
What TTFB contains
A navigation can include:
- DNS lookup
- TCP connection or QUIC setup
- TLS negotiation
- Travel to an edge or origin
- Cache lookup
- PHP and database work after a miss
- Response-header preparation
- First body byte
Different tools may start timing at different points or reuse existing connections. Document the tool and connection condition.
Step 1: select pages
Choose a typical article, homepage, archive, search page, logged-in page, and checkout if applicable. Public pages often cache; personalized pages usually do not.
Keep URLs stable. Record redirects because http to https or root to www adds requests.
Step 2: record the environment
Write down host, plan, data center, DNS, CDN, cache plugin, cache headers, PHP, WordPress, theme, plugins, test date, and page weight.
If comparing changes, make a backup and change one variable at a time.
Step 3: measure with curl
On Windows PowerShell, call the actual curl executable if the curl alias behaves differently:
curl.exe -o NUL -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/
On macOS or Linux, use /dev/null instead of NUL.
time_starttransfer includes earlier phases. Subtracting prior timestamps can help isolate portions, but it still does not expose every internal server stage.
Run from controlled machines in several regions. Save output with timestamps.
Step 4: use browser developer tools
Open a private browser session, load Developer Tools, select Network, disable cache only for a documented cold test, and reload.
Select the document request and inspect Timing. Browsers may show queueing, DNS, connection, SSL, request sent, waiting for server response, and download.
Connection reuse means a repeat navigation may skip DNS, TCP, or TLS. That reflects normal browsing but differs from a first visit. Label both.
Step 5: use WebPageTest
Choose a fixed test location, browser, device, connection profile, and run count. Enable first-view and repeat-view tests when useful.
The waterfall reveals redirects, connection setup, document TTFB, cache headers, and discovery of the LCP resource. Save result URLs or HAR files.
Run at least three browser tests per condition; more are better when results vary.
Step 6: check PageSpeed Insights
PageSpeed Insights combines Lighthouse lab diagnostics with Chrome User Experience Report field data when sufficient observations exist.
Field TTFB represents a trailing real-user window and may show URL or origin scope. Confirm which one appears. A new or low-traffic site may lack field data.
Do not compare a lab TTFB directly with a field percentile as if they were collected under identical conditions.
Step 7: separate cache states
For cold tests, purge the documented page cache and CDN cache, then verify a miss. For warm tests, prime the page and prove a hit through headers.
Record whether HTML came from browser cache, CDN, reverse proxy, server page cache, or WordPress origin. “Cache enabled” is not proof of a hit.
Never publicly cache private account, cart, checkout, or personalized responses.
Step 8: repeat samples
Collect at least 30 command-line samples per URL, region, and cache state across several times of day. Report:
- Median
- 75th percentile
- 95th percentile
- Minimum and maximum
- Failures
- Sample count
Do not remove slow samples without an exclusion rule written before testing.
Step 9: interpret thresholds
Google provides a rough field guide:
- Good TTFB: 0.8 seconds or less
- Needs improvement: over 0.8 to 1.8 seconds
- Poor: over 1.8 seconds
TTFB is not a Core Web Vital. It should be interpreted alongside LCP, INP, CLS, correctness, and uptime.
A page can have fast TTFB and poor LCP because of a large image or blocking CSS.
Step 10: isolate origin processing
Compare nearby and distant locations, edge hits and misses, static files and PHP pages, plus warm and cold application cache.
If a static file is fast but uncached WordPress is slow, investigate PHP, database, plugins, external APIs, locks, and background jobs. If both are slow only far away, examine geography and CDN.
Use application performance monitoring or server logs to break origin work into PHP, database queries, and remote calls.
Step 11: measure under load
Single-user TTFB may look good while dynamic requests queue under concurrency. Use an authorized staging clone and ramp virtual users gradually.
Report median, p95, p99, successful requests, errors, timeouts, cache state, CPU, memory, I/O, and PHP/database indicators.
Stop at predefined limits. Do not load-test shared production without permission.
Results template
| URL | Region | Cache | Median | p75 | p95 | Failures |
|---|---|---|---|---|---|---|
| Article | Near | Warm | Pending | Pending | Pending | Pending |
| Article | Distant | Warm | Pending | Pending | Pending | Pending |
| Search | Near | Bypass | Pending | Pending | Pending | Pending |
| Checkout | Near | Bypass | Pending | Pending | Pending | Pending |
Attach raw curl output, HAR files, headers, and the environment manifest.
Fixing a slow result
Correct unnecessary redirects, choose a nearby origin, enable appropriate page cache, verify CDN behavior, update PHP safely, reduce slow plugins, optimize database queries, limit remote APIs, and schedule heavy jobs carefully.
Retest after each change with the same protocol. Do not attribute an improvement to hosting if the page or test location also changed.
Bluehost example
On Bluehost, record the exact WordPress plan, cache and CDN status, server geography, PHP, and response headers. Compare the same page before and after supported performance changes.
Our top beginner pick: Bluehost
WordPress.org-recommended — free domain for year one, 1-click install, 24/7 support.
Do not use another customer’s result as a promise for your site.
Final verdict
TTFB measurement is a controlled sampling exercise. Use curl for repeat timing, browser and WebPageTest waterfalls for request context, and field data for real-user experience.
Separate DNS, network, cache, and origin work; report percentiles and failures; and keep raw evidence. That turns “server response feels slow” into an actionable diagnosis.
Frequently asked questions
Is TTFB the same as page load time?
No. It ends at the first response byte; the browser still must download and render the page.
How many samples are enough?
Use at least 30 per timing condition and repeat across times and regions.
Why is the first request slower?
It may require DNS, connection, TLS, cache generation, and application work.
Can CDN hide slow hosting?
It can serve cached pages quickly while origin misses remain slow, so test both.
