How to Improve TTFB and Server Response Time for SEO and Performance

Time to First Byte (TTFB) measures how long it takes from the start of a navigation request until the browser begins receiving the first bytes of the response.

TTFB matters because it happens before the browser can begin processing the initial HTML document. When the first response is delayed, later work such as parsing HTML, discovering resources and rendering content can also begin later.

But TTFB is often misunderstood.

A high TTFB can involve more than PHP or the origin server. Depending on the request, it can include redirects, DNS, connection setup, TLS, network latency, CDN/proxy behavior, server queuing, application processing, database work, cache misses and external APIs.

Last verified: September 21, 2026. Browser timing behavior, CDN caching, hosting stacks and performance guidance can change; verify the actual request path and cache state before applying production changes.

---

---

1. What Is Time to First Byte?

For a page navigation, TTFB is the elapsed time between the start of navigation and the beginning of the response.

Navigation Starts
        ↓
Redirects
        ↓
DNS Resolution
        ↓
Connection / TLS
        ↓
HTTP Request
        ↓
CDN / Proxy / Origin
        ↓
Application / Database / APIs
        ↓
First Response Bytes Arrive

Not every navigation performs every stage. DNS may already be cached, a connection may be reused, or a CDN may respond without contacting the origin.

---

2. TTFB Is Not the Same as PHP Processing Time

A common mistake is to simplify the metric to:

TTFB = Server Processing Time

That is incomplete.

Browser-observed TTFB can include:

• Redirects.
• DNS resolution.
• TCP or QUIC connection setup.
• TLS negotiation.
• Network latency.
• CDN/proxy processing.
• Origin queuing.
• PHP/application execution.
• Database queries.
• External API calls.

---

3. What Is a Good TTFB?

Current web.dev guidance uses roughly 0.8 seconds or less as a useful guideline for good TTFB, around 0.8–1.8 seconds as a range that may need improvement, and above roughly 1.8 seconds as poor.

Those are practical diagnostic guidelines rather than hard requirements or universal hosting guarantees. A site does not need to hit a specific TTFB value in isolation if its real user experience is otherwise healthy.

Importantly:

• TTFB is not a Core Web Vital.
• A lower TTFB does not automatically produce a good LCP.
• A higher TTFB does not automatically mean the host is at fault.
• A single synthetic run does not represent every real visitor.

---

4. Do Not Use Sub-100ms TTFB as a Universal Requirement

Sub-100ms TTFB can occur under favorable conditions such as a nearby CDN edge, warm cache, reused connection or extremely light application work.

That does not make it a reasonable universal requirement for WordPress, WooCommerce or hosting comparisons.

---

5. TTFB vs Core Web Vitals

TTFB occurs before user-facing metrics such as First Contentful Paint and Largest Contentful Paint, so an excessive initial delay can consume part of the page-loading budget.

But TTFB and LCP are different metrics.

After the HTML arrives, LCP can still be delayed by:

• Large images.
• Render-blocking CSS.
• JavaScript execution.
• Font loading.
• Client-side rendering.
• Late resource discovery.

For the frontend side of the problem, use our Core Web Vitals Optimization Guide.

---

6. TTFB Is Not a Standalone Google Ranking Formula

Avoid statements such as:

Lower TTFB = Higher Rankings

That is too simplistic.

The useful objective is to remove unnecessary latency and improve the real loading experience, especially when server or network delay is contributing to poor user-facing performance. Google documents Core Web Vitals and broader page experience as factors its systems may consider, while also stating that good scores do not guarantee top rankings. TTFB itself is not one of the Core Web Vitals and should not be treated as a standalone ranking formula.

---

7. Measure Field Data and Lab Data Separately

Field data

Field data represents real visitors and naturally includes variation in geography, devices, networks, cache state and connection reuse.

Lab data

Lab tests are useful for controlled debugging, before/after comparisons, cache-state testing and geographic diagnostics.

Do not compare two hosting companies using one test from one location and present the result as universal performance.

---

8. Measure TTFB With PerformanceNavigationTiming

Modern browsers expose navigation timings through the Performance APIs.

const nav = performance.getEntriesByType('navigation')[0];

console.table({
  dns: nav.domainLookupEnd - nav.domainLookupStart,
  connection: nav.connectEnd - nav.connectStart,
  requestToResponseStart: nav.responseStart - nav.requestStart,
  ttfb: nav.responseStart - nav.startTime
});

MDN documents responseStart as the point immediately after the browser receives the first byte of the response. On modern pages using an interim response such as 103 Early Hints, that first byte can be the interim response rather than the final 200-class response.

Where browser support allows and you specifically need the final response-header boundary, inspect finalResponseHeadersStart as well. This distinction matters when comparing low-level timing traces.

Interpret individual traces carefully because cached DNS, connection reuse, proxies, redirects and browser behavior can change the timing breakdown.

---

9. Use DevTools to Inspect the Main Document

In Chrome DevTools, inspect the main HTML document in the Network panel.

Ask:

• Is there a redirect chain?
• Was DNS lookup required?
• Was a new connection created?
• How long was the browser waiting for the document response?
• Was the response served from CDN cache or origin?
• Are cache headers behaving as expected?

A waterfall is usually more useful than one isolated score because it shows where time is being consumed.

---

10. Distinguish Browser TTFB, Edge TTFB and Origin Work

The same URL can produce very different timing depending on where the response is generated.

• Browser-observed TTFB: what the user agent measures across the complete navigation path.
• Edge/cache response: the CDN or reverse proxy serves a stored response without waiting for the application to regenerate it.
• Origin response: the request reaches the web/application server and may trigger PHP, database queries or other backend work.
• Application processing time: only one component of the full browser-observed TTFB.

Do not compare an edge-cache hit with an uncached origin request and label the difference as a hosting benchmark.

---

12. Compare Cached and Uncached Requests Separately

WordPress can follow very different execution paths depending on cache state.

Full-Page Cache Hit
        ↓
Serve Existing Response
        ↓
Minimal PHP / Database Work

Cache Miss
        ↓
PHP Executes
        ↓
WordPress Loads
        ↓
Database / Plugins / Theme / APIs
        ↓
HTML Generated
        ↓
Response

Comparing a cached request on one platform with an uncached request on another produces a misleading result.

---

12. Diagnose Redirect Latency First

Redirect chains add extra work before the final document can load.

Prefer:

Old URL → Final URL

instead of:

Old URL → Redirect A → Redirect B → Final URL

---

13. Diagnose DNS Separately

DNS can contribute to startup latency when a lookup is required, but fixed rules such as “every DNS lookup must be under 20ms” are not appropriate globally.

Observed DNS time varies with:

• User location.
• Recursive resolver.
• Resolver cache state.
• Authoritative DNS architecture.
• Network path.
• Anycast routing.

For record configuration and DNS troubleshooting, use our DNS Configuration Best Practices Guide.

---

14. Connection and TLS Latency

Secure connections can require network round trips.

The real cost depends on:

• Protocol.
• Connection reuse.
• Network distance.
• TLS behavior.
• HTTP/2 or HTTP/3 support.
• Proxy/CDN architecture.

Do not use a fixed global threshold for TLS negotiation without test context.

---

15. Diagnose WordPress PHP Execution

If DNS and connection setup are reasonable but uncached document requests remain slow, profile application execution.

Common WordPress causes include:

• Slow plugins.
• Expensive hooks.
• Large autoloaded option sets.
• Repeated database queries.
• External HTTP requests.
• Heavy theme logic.
• Background work triggered during page requests.

Do not assume that more CPU will automatically fix inefficient application behavior.

---

16. PHP Workers and Queueing

Dynamic requests require available PHP workers.

If all workers are busy, new requests may wait before application execution begins.

Worker exhaustion is more likely under:

• Traffic bursts.
• Slow uncached requests.
• Long-running API calls.
• Heavy WooCommerce sessions.
• Insufficient process capacity.

If you manage your own VPS and need to tune worker modes or sizing, use our PHP-FPM Tuning Guide.

---

17. Database Query Delays

Uncached WordPress requests can involve many database operations.

Investigate:

• Slow queries.
• Missing indexes.
• Large option tables.
• Excessive metadata queries.
• Plugin-generated query loops.
• Database resource pressure.

An object cache can help suitable workloads, but it does not make every query free and does not replace full-page caching.

---

18. External API Calls Can Dominate TTFB

Server-side HTTP requests can block page generation while WordPress waits for another service.

Examples include:

• Payment APIs.
• License servers.
• CRM integrations.
• Remote feeds.
• Shipping APIs.

Measure these dependencies before migrating hosts. The same slow external service can follow the application to a new server.

If the backend delay progresses into upstream failures or gateway timeouts, use the Nginx 502/504 Troubleshooting Guide to isolate the failing upstream.

---

19. Full-Page Caching vs Object Caching

Full-page caching

Can bypass much of PHP and database generation for cacheable pages.

Object caching

Can reduce repeated application/database work while PHP still executes.

They solve different problems.

For a mostly public content site, page caching often produces a larger TTFB improvement than object caching alone.

Object caching is useful only when the application workload benefits from repeated cacheable object/database lookups; it should be evaluated separately from full-page caching.

---

20. CDN and Edge Caching

A CDN can reduce network distance and origin load for content it can cache.

It does not automatically fix high backend time for:

• Checkout.
• Logged-in sessions.
• Private dashboards.
• Uncached APIs.
• Personalized pages.

Always identify whether the measured response came from edge cache or the origin.

---

21. Server Location Still Matters

If most users are far from the responding infrastructure, network latency can contribute to TTFB.

Possible responses include:

• Choosing a more appropriate region.
• Using CDN caching for suitable content.
• Using regional architecture for larger applications.

Distance is only one variable; routing, peering, caching and application work also matter.

---

22. Shared Hosting vs VPS vs Cloud

Hosting architecture affects isolation, available resources, control and scaling, but those labels do not map to fixed TTFB values.

A well-cached site on modest shared hosting can respond efficiently, while a poorly configured VPS can perform badly.

For architecture trade-offs, read our Shared vs VPS vs Cloud Hosting Guide.

---

23. When a Hosting Upgrade Actually Makes Sense

Consider changing or upgrading hosting when measurements show infrastructure is genuinely limiting the workload.

Examples include:

• Sustained CPU saturation.
• Insufficient RAM.
• Frequent PHP worker exhaustion.
• Database resource constraints.
• I/O bottlenecks.
• Resource throttling.
• Inability to use required caching or services.
• An inappropriate server region.

If the diagnosis shows the problem is specifically your managed WordPress hosting environment rather than application code, use our Best WordPress Hosting guide to compare provider fit.

---

24. How to Compare Hosting TTFB Fairly

A credible comparison should control at least:

Do not invent these values. If no controlled test was performed, keep the comparison documentation-based.

---

25. Common TTFB Optimization Mistakes

• Targeting sub-100ms universally: network distance and workload differ.
• Blaming hosting immediately: redirects, APIs, plugins, queries or network latency may be responsible.
• Comparing cached and uncached requests: they are different execution paths.
• Running one synthetic test: one run cannot represent global users.
• Calling TTFB a Core Web Vital: it is not one.
• Equating low TTFB with good LCP: frontend work can still dominate rendering.
• Adding Redis automatically: object caching must benefit the workload.
• Increasing PHP workers without checking RAM: concurrency requires resources.
• Ignoring external APIs: server-side requests can block generation.
• Migrating hosts before profiling: application bottlenecks can follow you.

---

26. TTFB Optimization Checklist

• Measure both real-user and controlled lab data where available.
• Run multiple tests.
• Use consistent test locations.
• Check redirect chains.
• Inspect DNS and connection setup separately.
• Determine whether the response comes from CDN cache or origin.
• Separate cached and uncached results.
• Profile WordPress/PHP execution.
• Inspect database queries.
• Check external API calls.
• Monitor CPU, RAM, workers and database resources.
• Use page caching where appropriate.
• Use object caching when the workload benefits.
• Place infrastructure appropriately for your users.
• Change one variable at a time and measure again.

---

Summary: How to Improve TTFB Correctly

TTFB is most useful as a diagnostic metric, not an isolated website-performance score.

Measure
   ↓
Identify the Slow Stage
   ↓
Change One Variable
   ↓
Measure Again
   ↓
Verify Real-User Impact

Do not choose a hosting provider solely from a promised TTFB number. Choose infrastructure that matches the workload, then measure the complete request path.

---

Frequently Asked Questions

What is TTFB?

Time to First Byte measures the time between the start of a page navigation and the browser beginning to receive the response. Depending on the request, it can include redirects, DNS, connection setup, TLS, network delay, proxy/CDN behavior and backend processing.

What is a good TTFB?

Current web.dev guidance uses roughly 0.8 seconds or less as a useful guideline for good TTFB, around 0.8–1.8 seconds as a range that may need improvement, and above roughly 1.8 seconds as poor. Treat these as diagnostic guidance rather than hard requirements or hosting guarantees.

Is TTFB a Core Web Vital?

No. The Core Web Vitals are LCP, INP and CLS. TTFB is a foundational diagnostic metric that occurs before later loading work.

Does lower TTFB guarantee higher Google rankings?

No. Lowering excessive initial response delay can improve page delivery, but TTFB is not a direct ranking formula.

Should every site target sub-100ms TTFB?

No. Results depend on geography, connection state, caching, CDN behavior, workload and infrastructure.

Can Redis reduce TTFB?

It can reduce repeated database/application work for suitable workloads when object-cache hits occur. It does not guarantee a specific TTFB and does not replace full-page caching.

Can changing hosting improve TTFB?

Yes, when the existing infrastructure is the measured bottleneck—for example worker exhaustion, CPU contention, memory limits, I/O constraints, database limits or poor geographic placement.

Why is cached TTFB usually faster?

Full-page caching can serve a previously generated response and avoid much of the PHP and database execution needed by an uncached WordPress request.

How should I compare two hosts?

Use the same application, cache state, location, workload and test method. Run multiple measurements and document the exact configuration.