Disclosure: This article may contain affiliate links that help support our work at no extra cost to you; we maintain full editorial independence and honesty regarding all h
Time to First Byte is the delay between starting an HTTP request and receiving the first byte of the response. It is the earliest measurable sign that a website is answering, but it combines network and server work. A low TTFB helps pages start sooner; it does not guarantee that the page becomes visible or interactive quickly.
What TTFB contains
Depending on the tool and connection state, TTFB can include DNS lookup, TCP or QUIC connection, TLS negotiation, request travel, edge/cache lookup, server queueing, PHP execution, database queries, and response travel.
If a browser reuses an existing connection, DNS, TCP, and TLS may disappear from that request. If a command-line tool creates a new connection each time, those phases return. This is why two tools can report different TTFB without either being wrong.
TTFB is not load time
After the first byte, the browser still downloads HTML and discovers CSS, JavaScript, images, fonts, and embeds. It must build the DOM and CSSOM, execute scripts, calculate layout, and paint.
| Metric | Ends when | Main influences |
|---|---|---|
| TTFB | First response byte | Network, cache, server, application |
| LCP | Largest visible element renders | TTFB, resource priority, CSS, image/font |
| INP | Interaction receives visual response | JavaScript and browser main thread |
| CLS | Layout stability is assessed | Dimensions, injected content, fonts |
| Full load | Load event/requests complete | All page resources |
Editor's Pick. Our team's current top recommendation for this category. (Affiliate link coming soon — we only link programs we've vetted.)
TTFB consumes part of the LCP budget. Improving a two-second server wait creates room for the hero to render, but lowering TTFB from 150 to 100 ms will not rescue a 4 MB image.
Cache state changes the meaning
A full-page cache HIT returns stored HTML without running WordPress. A MISS generates the page and often fills cache. A BYPASS intentionally skips page cache for logged-in, personalized, cart, checkout, or excluded content.
Publish the state with every number. A host can show excellent HIT TTFB and weak BYPASS performance; both results are real for different visitors. Use documented headers to verify state.
Object cache is different. Redis or Memcached stores reusable database objects but still allows WordPress to execute. CDN cache can serve assets or HTML near visitors. Browser cache affects returning navigation.
What is a good TTFB?
For a lightweight cached page tested near its serving layer, a stable median below roughly 200–400 ms is a useful practical target. Distant or uncached requests may be higher. p95 and error rate matter more than the single fastest response.
Do not turn one threshold into a universal pass/fail. A global edge HIT, local origin MISS, and authenticated checkout are not equivalent. Define a response budget for each workload and audience.
Measure 20–30 requests per state and report median, p75, p95, maximum, and failures. With enough continuous data, examine hourly and regional percentiles.
Why hosting affects TTFB
The host determines origin location, network connectivity, server queueing, CPU, memory, storage, PHP workers, database configuration, cache layers, and account isolation. Shared hosting can vary under pooled demand; managed and cloud platforms can provide clearer resources but still require correct sizing.
Hostinger and GreenGeeks integrate LiteSpeed page caching. SiteGround uses NGINX Dynamic Cache. Bluehost documents automatic page caching, Redis object caching on eligible WordPress plans, and Cloudflare. Rocket.net emphasizes edge full-page delivery. Each can produce fast HITs; dynamic capacity must be tested separately.
Why WordPress affects TTFB
On a cache MISS, WordPress loads core, active plugins, theme code, and requested data. Slow database queries, autoloaded options, remote API calls, excessive hooks, and PHP errors extend wait time. Scheduled jobs or backups can create contention.
Use Query Monitor in staging, the host's application monitoring, or New Relic-compatible tools where available. Identify the slow transaction rather than assuming more storage or a CDN will fix it.
Current PHP versions can improve efficiency, but test plugin compatibility before changing production. OPcache avoids recompiling scripts. Object cache can reduce repeat database queries. Database indexes help specific query patterns.
Network and DNS effects
A visitor far from the origin adds round-trip delay, especially during connection setup. A CDN can terminate near the visitor and serve cached content. Dynamic requests may still travel to the origin.
DNS is usually a small share after caching, but slow or unreliable authoritative service affects initial connections. Redirect chains add complete request/response cycles. Configure one canonical HTTPS hostname with a single redirect at most.
IPv6 and IPv4 can take different paths. A stale AAAA record may route some users to an old server. Test both protocols when regional reports disagree.
How to measure it
Use browser developer tools to connect HTML wait time to the waterfall. Use command-line timing for repeated phase-separated measurements. Use WebPageTest for controlled browser locations and repeat views. Use multi-region monitoring for long-term percentiles.
Keep URL, region, page content, PHP version, and tool settings fixed. Test HIT, MISS, and BYPASS. State whether connections are fresh or reused. Save raw output and include errors.
For host comparisons, clone the same fixture and match plan price, region, CDN state, and resource tier. One homepage run on different themes is not a benchmark.
Improving TTFB in order
- Remove redirect chains and confirm DNS routing.
- Place the origin near dynamic users or use appropriate edge delivery.
- Enable the host-supported full-page cache and verify HIT.
- Exclude personalized routes correctly.
- Update compatible PHP and enable OPcache through the host.
- Profile slow plugins, queries, and remote calls.
- Add object cache when the workload benefits.
- Schedule backups/imports away from peak periods.
- Upgrade when resource graphs and load tests prove saturation.
Do not install multiple page-cache plugins. Purge server, CDN, and browser layers after changes, then rerun the identical test.
TTFB and uptime
Latency can deteriorate before a complete outage. Monitoring p95 TTFB alongside errors can reveal saturation or routing problems. Monitor an uncached health path carefully, but do not create heavy database work every minute.
A CDN may return cached HTML while origin health fails. Add a safe application check and alert separately on DNS, TLS, timeout, and status-code problems.
FAQ
Is TTFB a Google ranking factor?
TTFB is not one of the three Core Web Vitals. It affects how soon content can begin loading, while search ranking uses many signals and field user experience.
Does a CDN always lower TTFB?
It lowers TTFB for eligible edge-cached responses and may improve connection distance. Cache misses and dynamic requests can still reach the origin, and an extra hop may not help near-origin traffic.
Why is wp-admin slower than the homepage?
The homepage may be served from full-page cache. wp-admin is authenticated and dynamic, so PHP, database queries, and object cache determine response.
Can a plugin fix TTFB?
A supported cache plugin can improve anonymous HITs. It cannot fix every dynamic query, overloaded server, network path, or external API delay.
Recommendation
Use TTFB as a layered diagnostic, not a complete speed grade. Measure percentiles in several regions, label HIT/MISS/BYPASS, and connect the wait to WordPress profiling and resource graphs. Improve caching and application work first; upgrade hosting only when sustained evidence shows capacity or network limits.
Related: bluehost review