What Is TTFB? How to Reduce Server Response Time

Introduction

What is TTFB? Time to First Byte measures how long a browser waits before receiving the first byte of a response from a server after making a request. A high TTFB can indicate delays involving DNS lookup, connection setup, server processing, database queries, or network latency. Understanding these factors helps website owners identify the actual bottleneck and choose the right fixes instead of relying on generic speed optimizations.

Before the browser can start receiving the HTML response, something has to happen behind the scenes: the request has to travel to the server, the connection has to be established or reused, the request has to be processed, and the first byte of the response has to come back.

The time until that first byte arrives is called Time to First Byte, or TTFB.

TTFB is useful because it gives you an early indication of how quickly a server-side request begins producing a response. For navigation requests, it occurs before the rest of the page’s loading process can meaningfully progress.

But there is an important detail that is often missed:

TTFB is not simply “how long the server took to generate the page.”

It can also include connection setup, redirects, network conditions, and whether the response comes from a browser cache, CDN, or origin server.

That distinction matters when you’re trying to fix a slow TTFB.

Quick Answer

TTFB measures the time from the start of a request until the browser receives the first byte of the response.

A high TTFB can be caused by:

• slow server-side processing
• inefficient database queries
• uncached dynamic pages
• slow hosting
• overloaded servers
• redirects
• network latency
• connection setup
• CDN configuration
• cache misses
• application code
• external API calls
• inefficient WordPress plugins or themes

To reduce TTFB:

1. Measure the actual TTFB first.
2. Check whether the delay comes from the network, CDN, cache, or origin.
3. Improve server-side processing.
4. Cache pages and expensive computations where appropriate.
5. Optimize database queries.
6. Reduce unnecessary application work.
7. Use a CDN where it meaningfully reduces distance to users.
8. Avoid unnecessary redirects.
9. Improve hosting or server capacity when infrastructure is the bottleneck.
10. Recheck real-user data after making changes.

What Is TTFB?

TTFB stands for Time to First Byte.

It measures how long it takes for the first byte of a response to reach the browser after a request begins.

A simplified request looks like this:

Browser → Network → Server/CDN → Processing → First response byte → Browser

TTFB represents the time up to that first response byte.

For an HTML navigation request, this happens before the browser can fully process the document and continue with the resources referenced by that document.

That makes TTFB an important foundational performance measurement.

What Does TTFB Actually Include?

This is where many TTFB explanations become misleading.

TTFB isn’t a stopwatch attached exclusively to your web server.

Depending on the request and measurement environment, the time can involve several stages:

• connection establishment
• redirects
• network travel
• server or CDN processing
• cache lookup
• application execution
• database work
• response generation
• delivery of the first byte

Chrome’s CrUX documentation specifically notes that TTFB is not a direct measure of server response time because it can include time before server processing and can be affected by caching, CDNs, redirects, and other factors.

That means a high TTFB doesn’t automatically prove that your server is slow.

You need to find out where the time is being spent.

Is TTFB a Core Web Vital?

No.

TTFB is an important performance metric, but it is not one of the three Core Web Vitals.

The current Core Web Vitals are:

• LCP:Largest Contentful Paint
• INP:Interaction to Next Paint
• CLS:Cumulative Layout Shift

TTFB is better understood as a foundational loading metric.

It can influence how quickly the browser gets started with the page, and a slow TTFB can contribute to slower loading performance, including LCP.

But there is no official Core Web Vital requirement that says a page must have a particular TTFB value.

What Is a Good TTFB?

A commonly used practical target is around 800 milliseconds or less.

That can be useful as a diagnostic benchmark, but it should not be treated as a universal pass/fail threshold.

A website serving users around the world may have different network characteristics from a site serving visitors from a single nearby region.

Likewise, a dynamic application and a static website have very different server workloads.

The more useful question is:

Is TTFB unnecessarily high for this website, its architecture, and its audience?

A TTFB of 500ms may deserve attention on one site while a much larger number could be explained by a particular architecture or measurement environment.

Use the number to identify a potential problem, not as the entire diagnosis.

Why Does TTFB Matter?

For an HTML navigation request, the browser cannot fully begin processing the returned document until the response starts arriving.

A simplified sequence is:

Request → TTFB → HTML processing → resource discovery → resource loading → rendering

If the initial response is delayed, later stages may have less opportunity to begin early.

This is especially relevant when the page’s important content depends on the initial HTML response.

TTFB can therefore be an important part of the overall loading path, even though improving TTFB alone doesn’t guarantee a fast page.

Common Causes of High TTFB

There isn’t one universal cause.

The most useful way to troubleshoot TTFB is to separate the problem into categories.

1. Slow Server-Side Processing

The server may simply take too long to generate the response.

Possible causes include:

• expensive application logic
• inefficient database queries
• excessive calculations
• large amounts of data processing
• unnecessary API calls
• poorly optimized code
• overloaded application workers

A dynamic page may require several operations before the server can produce HTML.

If those operations take 1.5 seconds, the first byte cannot arrive before that work is sufficiently complete.

2. Database Queries

Database performance can have a significant effect on dynamic websites.

A request might need to:

1. load content
2. query categories
3. retrieve related items
4. check user information
5. fetch settings
6. generate the final response

One poorly designed query can become a bottleneck.

Look for:

• slow queries
• missing indexes
• unnecessary queries
• repeated queries
• large result sets
• inefficient joins
• queries executed on every request when the result could be cached

Database optimization can produce substantial improvements when the database is genuinely responsible for the delay.

3. Lack of Page Caching

If every visitor causes the application to generate the same page from scratch, the server may be doing unnecessary work.

Consider a public article page.

If the content changes only occasionally, there may be little reason to execute the complete application stack for every visitor.

A page cache can allow a previously generated response to be reused.

That can dramatically reduce the work required to produce subsequent responses.

4. Slow Hosting

Sometimes the application is reasonably efficient but the infrastructure is not.

Possible infrastructure limitations include:

• insufficient CPU
• insufficient memory
• overloaded shared hosting
• slow storage
• limited database resources
• too many concurrent processes
• noisy neighbors on shared infrastructure
• poorly configured server software

If the same application performs substantially better on a stronger environment, infrastructure may be part of the problem.

5. Cache Misses

Caching can make a response fast.

But a cache miss may require the request to travel all the way to the origin server.

For example:

Visitor → CDN → cache miss → origin → application → database → response

The first request may therefore take significantly longer than subsequent requests.

This is not necessarily a configuration failure.

You need to understand whether the measured TTFB represents:

• a cached response
• a cache miss
• an origin response
• a request after an established connection

Real-user data can contain all of these situations.

6. Redirects

Redirects add another step before the final response can be received.

For example:

http://example.com

        ↓

https://example.com

        ↓

https://www.example.com

        ↓

https://www.example.com/page

Every unnecessary redirect introduces additional work and latency.

A cleaner request path is:

https://www.example.com/page

Avoid redirect chains wherever possible.

One necessary redirect is different from several unnecessary redirects.

7. Network Distance

A visitor in one geographic region may experience a different TTFB from someone much farther away.

The request and response have to travel across the network.

This is one reason TTFB should not automatically be interpreted as server processing time.

A server can be responding efficiently while a distant visitor still experiences higher latency.

8. CDN Configuration

A CDN can reduce latency by serving content from a location closer to the visitor.

But simply having a CDN does not guarantee a lower TTFB.

Potential problems include:

• low cache hit rates
• incorrect cache rules
• dynamic content bypassing the CDN
• poor geographic coverage
• requests repeatedly reaching the origin
• misconfigured routing

A CDN should be evaluated based on actual request behavior.

9. External API Calls

A server-side application may depend on external services.

For example:

Visitor

   ↓

Website server

   ↓

External API

   ↓

Response

   ↓

Website server

   ↓

Visitor

If the external API takes 700ms, your server may be forced to wait before generating the response.

External dependencies can therefore become hidden TTFB bottlenecks.

Ask whether the external request is:

• necessary
• performed on every page
• cacheable
• required before HTML can be generated

10. Heavy WordPress Processing

WordPress sites can generate TTFB problems through the combination of:

• themes
• plugins
• database queries
• page builders
• dynamic widgets
• third-party integrations
• uncached pages

This doesn’t mean WordPress inherently has poor TTFB.

The architecture and workload matter much more than the CMS label.

How to Diagnose High TTFB

Don’t start by replacing your hosting provider.

Start by identifying where the delay occurs.

Step 1: Measure the URL

Use tools such as:

• PageSpeed Insights
• Chrome DevTools
• Lighthouse
• WebPageTest
• CrUX data where available

Run more than one test when results appear inconsistent.

Step 2: Check the Network Waterfall

Open Chrome DevTools and inspect the document request.

Look at the timing information for the HTML request.

You want to determine whether the delay appears to be associated with:

• connection
• redirects
• waiting for the server
• response delivery

Step 3: Check Response Headers

Inspect:

• Cache-Control
• CDN-related headers
• server headers
• cache status headers
• Age
• ETag
• other platform-specific headers

These can reveal whether a response was served from a cache or generated by the origin.

Step 4: Compare Cached and Uncached Requests

If your architecture allows it, compare:

• a cache hit
• a cache miss
• an origin request

This can tell you whether caching is making the expected difference.

Step 5: Test From Different Locations

A server located in one region may produce different TTFB results around the world.

If possible, test from locations that represent your actual audience.

A geographically diverse audience makes regional testing particularly useful.

TTFB Is Not the Same as Server Processing Time

This deserves repeating because it causes so much confusion.

Imagine a request has this simplified timing:

• connection and network: 180ms
• server processing: 250ms
• response begins: 430ms

The measured TTFB may be around 430ms.

That doesn’t mean the server spent 430ms processing the request.

Likewise, if a request is served from a nearby cache, the TTFB may be much lower without the origin application becoming faster.

This is why infrastructure changes should follow diagnosis rather than precede it.

How to Reduce TTFB

Once you’ve identified the bottleneck, optimization becomes much more straightforward.

1. Enable Appropriate Page Caching

For public pages that don’t need to be generated for every request, full-page caching can be one of the most effective ways to reduce server work.

Instead of:

Request

→ PHP/application

→ database

→ HTML generation

→ response

a cached page can behave more like:

Request

→ cached HTML

→ response

The exact architecture depends on the platform.

The important idea is to avoid regenerating identical content unnecessarily.

2. Improve Database Performance

If database work is responsible for the delay:

• identify slow queries
• add appropriate indexes
• remove unnecessary queries
• avoid fetching data that isn’t used
• reduce repeated database operations
• cache expensive results where appropriate

Don’t optimize the database blindly.

Profile it first.

3. Reduce Application Work

Look for operations that happen during every request but don’t need to.

Examples include:

• rebuilding data that rarely changes
• making unnecessary API calls
• generating expensive calculations repeatedly
• loading unused components
• executing redundant queries

Moving expensive work away from the critical request path can reduce TTFB.

4. Cache Expensive Computations

Not everything needs full-page caching.

You can also cache:

• database results
• API responses
• configuration
• generated fragments
• expensive calculations

This is especially useful for dynamic sites where complete page caching isn’t possible.

5. Reduce Redirects

Make the final URL the URL visitors actually request.

Check:

• HTTP → HTTPS
• www → non-www
• non-www → www
• old URL → new URL
• unnecessary tracking redirects

A redirect may be necessary.

A chain of redirects usually isn’t.

6. Use a CDN Strategically

A CDN can help with geographically distributed audiences and cacheable content.

It is particularly useful when:

• visitors are far from the origin
• static resources are large
• public HTML can be cached
• the CDN has good coverage for your audience

But don’t assume putting a CDN in front of an uncached dynamic application automatically solves high TTFB.

Measure cache hits and origin requests.

7. Improve Hosting When Infrastructure Is the Bottleneck

If profiling shows that your server is consistently constrained, upgrading infrastructure may be appropriate.

Potential improvements include:

• more CPU
• more memory
• faster storage
• better database resources
• dedicated resources
• improved server configuration
• better geographic placement

Don’t upgrade simply because a performance tool displays a high TTFB.

Upgrade when evidence points toward infrastructure capacity or responsiveness.

8. Keep the Server Software Efficient

Server configuration can affect response time.

Depending on the environment, review:

• HTTP/2 or HTTP/3 availability
• TLS configuration
• compression
• connection reuse
• PHP/runtime versions
• worker configuration
• database configuration
• web server configuration

The exact settings depend heavily on your hosting stack.

Avoid applying configuration changes without understanding the workload.

9. Avoid Server-Side Third-Party Dependencies Where Possible

If every request requires a third-party API before the HTML can be generated, the external service becomes part of your response path.

If the data doesn’t need to be real-time, consider:

• caching it
• refreshing it asynchronously
• storing it locally
• generating it ahead of time

The fastest external request is often the one you don’t have to make before sending the page.

10. Generate Static HTML When the Content Allows It

Some websites don’t actually need dynamic HTML generation for every visitor.

Blogs, documentation sites, marketing pages, and other mostly static content can sometimes be pre-generated.

The architecture becomes:

Build process

→ generate HTML

Visitor

→ cached/static HTML

→ response

This can remove substantial server-side work from the request path.

It isn’t appropriate for every application, but when the content model allows it, static generation can be extremely effective.

11. Use Browser and CDN Caching Together

Browser caching and CDN caching solve different parts of the delivery problem.

A browser may avoid requesting a resource entirely because it already has a fresh copy.

A CDN can serve a resource without contacting the origin.

A useful architecture can therefore look like:

Visitor

   ↓

Browser cache

   ↓

CDN cache

   ↓

Origin server

Each layer can prevent unnecessary work farther down the chain.

For HTML and dynamic content, the caching rules need to be designed carefully.

TTFB and LCP

TTFB is particularly relevant to LCP because the initial HTML response comes before many of the resources the browser needs to render the page.

A slow initial response can delay:

• HTML parsing
• discovery of important resources
• CSS processing
• image discovery
• rendering

But TTFB is only one part of the LCP timeline.

A page can have:

Good TTFB + poor LCP

if the LCP resource is discovered late, downloaded slowly, or rendered late.

It can also have:

Poor TTFB + relatively good LCP

under certain conditions where the rest of the page becomes ready quickly after the response begins.

This is why TTFB should be optimized as part of the loading path rather than treated as the complete explanation for LCP.

TTFB and Caching

Caching deserves special attention because it can dramatically change TTFB.

Consider an uncached request:

Visitor

→ CDN

→ Origin

→ Application

→ Database

→ HTML

Now compare that with a cache hit:

Visitor

→ CDN

→ Cached HTML

The second path can be dramatically shorter.

But field data may contain both scenarios.

This is one reason real-user TTFB can be more variable than a simple lab test suggests. Chrome’s CrUX documentation notes that field TTFB can include cached page loads, cold loads, and established connections.

TTFB in Lab Data vs Field Data

This distinction is important.

Lab TTFB

A lab tool runs a controlled test under specified conditions.

It is useful for:

• debugging
• reproducing problems
• comparing changes
• inspecting waterfalls

Field TTFB

Field data represents actual user experiences.

It can vary according to:

• location
• connection
• device
• cache state
• CDN behavior
• connection reuse
• server conditions

CrUX specifically notes that TTFB field data includes different loading situations and therefore should not be interpreted as a pure server-processing metric.

For a real performance strategy, use both.

How to Fix High TTFB on WordPress

If you’re running WordPress, use a structured troubleshooting process.

First, check page caching

If public pages are being generated dynamically on every request, determine whether full-page caching is appropriate.

Next, inspect plugins

Don’t disable plugins randomly.

Instead, look for plugins that:

• perform expensive database queries
• make external API requests
• generate dynamic content
• add complex page-builder functionality
• run unnecessary processing on every request

Then check the database

Look for slow queries and excessive database operations.

Check hosting

If the application and database are reasonably optimized but response times remain high, infrastructure may be the limiting factor.

Finally, check the CDN

Verify whether pages and resources are actually being cached as intended.

A CDN that is configured but rarely produces cache hits won’t provide the same benefit as an effective edge-cache strategy.

What If TTFB Is High Only in One Region?

This is an important diagnostic clue.

If visitors near your origin see low TTFB while users on another continent see much higher values, network distance or delivery architecture may be contributing.

Potential solutions include:

• CDN edge caching
• regional infrastructure
• improved routing
• reducing redirects
• caching public HTML
• serving static resources from an appropriate edge location

Don’t immediately rewrite application code if the problem is primarily geographic.

What If TTFB Is High Everywhere?

If TTFB is consistently high across regions, investigate the origin path more closely.

Look at:

• server processing
• database queries
• application code
• cache hit rates
• hosting resources
• external APIs
• server configuration

A globally high TTFB is stronger evidence of an origin-side bottleneck than a problem limited to one geographic area.

What If TTFB Is Good but the Website Is Still Slow?

This is common.

TTFB only describes the beginning of the response path.

The page can still be slow because of:

• large images
• render-blocking CSS
• excessive JavaScript
• slow LCP resources
• third-party scripts
• web fonts
• large downloads
• long main-thread tasks
• layout shifts

This is why improving TTFB should not become the entire performance strategy.

A fast first byte does not guarantee a fast page.

Common TTFB Optimization Mistakes

Mistake 1: Treating TTFB as pure server processing time

It isn’t.

Connection, network, redirects, cache behavior, and other factors can contribute.

Mistake 2: Changing hosting immediately

A hosting upgrade may help, but only if infrastructure is actually responsible.

Mistake 3: Installing more caching plugins

More caching layers don’t automatically mean faster responses.

Conflicting configurations can make troubleshooting harder.

Mistake 4: Using a CDN without checking cache hits

A CDN that continually forwards requests to the origin may provide little benefit for cacheable content.

Mistake 5: Ignoring database queries

A slow database can make an otherwise capable server appear slow.

Mistake 6: Ignoring redirects

Multiple redirects can add latency before the final response is reached.

Mistake 7: Optimizing only for lab TTFB

A good lab result doesn’t necessarily mean every real visitor has the same experience.

Mistake 8: Treating 800ms as a hard failure

Practical thresholds are useful for diagnosis, but context matters.

A Practical TTFB Troubleshooting Workflow

Use this order instead of changing everything at once.

Step 1: Measure

Record TTFB for the affected page.

Step 2: Compare

Test multiple times and, when possible, from different locations.

Step 3: Inspect the waterfall

Determine where the delay appears.

Step 4: Check redirects

Remove unnecessary hops.

Step 5: Check cache behavior

Determine whether the response is coming from:

• browser cache
• CDN cache
• server cache
• origin

Step 6: Profile the origin

If the request reaches the server, investigate:

• application processing
• database queries
• external APIs
• server capacity

Step 7: Apply one major change

For example:

• enable page caching
• optimize a database query
• remove an unnecessary API call
• improve CDN caching

Step 8: Retest

Compare the new result with the original.

Step 9: Check field data

If real-user data is available, monitor whether the improvement appears outside the lab environment.

TTFB Optimization Checklist

Measurement

• Measure the actual document request.
• Test more than once.
• Compare different locations where relevant.
• Check both lab and field data.

Network

• Remove unnecessary redirects.
• Check connection behavior.
• Consider geographic distance.
• Verify CDN routing where relevant.

Caching

• Enable appropriate page caching.
• Check CDN cache hits.
• Cache expensive computations where appropriate.
• Avoid unnecessary origin requests.

Server

• Check CPU and memory constraints.
• Review server configuration.
• Keep runtime software current.
• Investigate overloaded workers.
• Check storage and database performance.

Application

• Identify slow application code.
• Reduce unnecessary processing.
• Remove unnecessary API calls.
• Cache expensive operations.
• Reduce repeated database queries.

Database

• Identify slow queries.
• Check indexing.
• Remove unnecessary queries.
• Reduce repeated lookups.
• Cache appropriate results.

Final validation

• Retest the same URL.
• Compare before and after.
• Check LCP separately.
• Monitor real-user performance where possible.

Final Verdict

TTFB is one of the most useful early indicators when investigating a slow website, but it is also one of the easiest performance metrics to misunderstand.

A high number doesn’t automatically mean:

“My server is slow.”

It means:

“The first byte of this response took a long time to arrive.”

The cause could be the server, application, database, CDN, cache state, redirect chain, network distance, or several of these factors together.

That is why the best TTFB optimization process starts with measurement.

Find out where the delay is happening.

Then remove unnecessary work from the request path, cache what can be cached, optimize the application and database, reduce redirects, use infrastructure appropriate for your audience, and verify the result with both lab and real-user data.

And remember that TTFB is only the beginning of the page-loading journey.

A faster first byte is valuable.

But the real objective is a page that becomes useful quickly and remains responsive throughout the experience.

Related Guides

• How TTFB Affects LCP
• What Is LCP? Largest Contentful Paint Explained
• Lighthouse vs CrUX: Lab Data vs Real-World Data
• Browser Caching and Cache-Control Explained
• Website Speed Optimization Checklist
• How to Eliminate Render-Blocking Resources
• Third-Party Scripts and Core Web Vitals
• Image Optimization: WebP, AVIF, Sizing and Lazy Loading
• How to Improve INP: JavaScript, Event Handlers and Long Tasks

Recommended Resources

For further reading on TTFB measurement and server performance, explore these authoritative resources:

• web.dev: Time to First Byte (TTFB): Learn what TTFB measures, how it is calculated, and which factors can affect it.
• Google Search Central: Core Web Vitals: Understand how website performance metrics contribute to user experience.
• Google PageSpeed Insights: Test a page and review available lab diagnostics and real-world performance data.
• Chrome for Developers: Lighthouse: Learn how to audit website performance and investigate potential issues.
• Cloudflare Learning Center: What Is a CDN?: Explore how content delivery networks can reduce latency for eligible requests.