What Causes High TTFB? Should You Check the CDN or the Origin Server First?

When a website loads slowly and speed tests show a particularly high TTFB, a familiar argument often follows.

The CDN provider says: “There is no problem with the edge nodes. The origin is what’s slow.”

Server operations says: “The origin responds quickly inside the data center. It must be the CDN route that’s at fault.”

Both sides can produce a screenshot that looks reasonable, yet users still wait two or three seconds before the page appears.

When TTFB is high, should you check the CDN or the origin first? There is no fixed answer.Start with the measurement methodology, then look at cache status, and finally compare using the same URL.

If a cache HIT static asset still has high TTFB, first check the user-to-CDN edge node connection, node scheduling, and edge processing; if HITs are fast while MISSes or dynamic requests are slow, shift the investigation to the origin fetch path, origin application, and database.

Don’t take sides right away. Identify the slow segment first, and the responsibility usually becomes clear on its own.

What exactly is TTFB? It is not just “server processing time”

TTFB stands for Time to First Byte, meaning the time from when a request starts until the first byte of the response arrives.

The catch is that different tools may not define “start” or display the phases in exactly the same way.

At the browser navigation level, TTFB may include:

• Page redirects;

• Service Worker startup;

• DNS resolution;

• TCP or QUIC connection;

• TLS negotiation;

• Request transmission and network round trips;

• CDN edge node processing;

• Origin fetch after a cache miss;

• The origin application preparing the response.

web.devdescribes navigation request TTFB as the time from navigation start to the arrival of the first response byte and explicitly lists phases such as redirects, Service Worker, DNS, connection, TLS, and request waiting.

This means a high TTFB in the browser does not directly equate to “high backend code execution time.”For details, see web.dev’sTTFB documentation.

In Chrome DevTools, the Timing panel for a single request further breaks down queuing, DNS, connection, TLS, request sent, waiting for TTFB, and content download.

Here, “Waiting for server response” is closer to the phase after the request is sent while waiting for the first byte, but it still includes network round trips and the time the server needs to prepare the response. See the Chrome DevTools Network documentation.

So before comparing two TTFB screenshots, confirm what tools they came from, which URL was tested, whether redirects occurred, whether the connection was reused, and whether the measurement covers a full navigation or a single HTTP request.

What TTFB is normal? 0.8 seconds is only a reference line

web.devgives the rough recommendation that most sites can aim to keep TTFB within 0.8 seconds for 75% of users; over 1.8 seconds is generally considered poor.

It also emphasizes that TTFB is not a Core Web Vitals metric, and these thresholds need to be understood in the context of how the site is delivered.

These numbers are useful as a web experience reference, but they should not become a uniform SLA for every business, region, and asset.

For example:

• A small static file served as a cache HIT in the same city should usually be faster than a cross-continent dynamic API;

• A personalized page after login cannot simply be held to the same standard as public static assets;

• A first HTTPS connection and a request over a reused connection take different amounts of time;

• A user in mainland China accessing an overseas origin and a local user accessing the same origin have different baselines;

• A single test reaching 0.7 seconds does not mean the P95 during evening peak is also normal.

More valuable than asking “is it under 0.8 seconds?” is establishing your own baseline: for the same URL, region, carrier, and cache state, what are P50 and P95, and have they changed persistently recently?

Check cache status first; it is the first dividing line between CDN and origin

Resources already cached by the CDN and resources that require an origin fetch take different paths.

When there is a cache HIT

the request is usually answered directly at the edge node without waiting for the origin to process it fully.

If TTFB is still high, check these first:

• Whether the user was routed to a distant node;

• Whether the route between the node and the user’s carrier takes a detour or is congested;

• Whether the DNS, TCP, or TLS phase is taking too long;

• Whether the edge node is under heavy load;

• Whether WAF, bot detection, authentication, or edge functions are adding processing time;

• Whether the request is redirected;

• Whether the speed test tool counts the connection phase in TTFB;

• Whether the so-called HIT comes from the browser’s local cache rather than the CDN edge cache.

On a cache MISS, BYPASS, or dynamic request

the CDN node needs to connect to the origin and wait for a response.

In addition to the user-to-CDN segment, there are also the CDN origin connection, origin TLS, application processing, and data return.

In this case, you should check:

• The network path from the CDN node to the origin;

• Whether the origin’s region is too far from the edge node;

• Whether the origin connection can be reused;

• Whether the origin firewall or WAF is delaying requests;

• Whether origin CPU, memory, disk, or connection count is saturated;

• Whether application worker processes and connection pools are queuing;

• Whether database queries, locks, and caching are abnormal;

• Whether external APIs are slowing down the entire response;

• Whether cache rules are causing cacheable content to be fetched from the origin frequently.

Different CDNs do not use consistent response headers for cache status. Common values includeHIT,MISS,BYPASS,DYNAMIC,EXPIREDandREVALIDATED, but the specific meaning should follow the current provider’s documentation.

For example, Cloudflare’s official documentation usesCF-Cache-Statusto describe cache results and explains statuses such as HIT, MISS, BYPASS, DYNAMIC, and EXPIRED separately.

This can serve as an example for understanding cache status, but the same set of response header names cannot be applied to every CDN. For details, seeCloudflare cache response documentation.

For detailed guidance on interpreting cache headers, see also“How to Check CDN Cache Hits: Understanding HIT, MISS, and Age”.

Use four comparison tests to identify which segment is slow

Testing the homepage only once makes it hard to distinguish CDN issues from origin issues. A more practical approach is to prepare several types of controllable test targets.

The results can be interpreted as follows:

This table is used to determine the investigation order, not to directly assign blame.

For example, “origin comparison low, CDN MISS high” could also mean the origin responds quickly only to the local test IP, while the CDN origin IP triggers firewall checks or rate limiting.

Step 1: Confirm you are testing the same request

Many CDN-versus-origin disputes end up revealing that the two sides were not testing the same thing at all.

Before making a formal comparison, align the following conditions:

• The full URL must be the same, including path and query parameters;

• The HTTP method must be the same;

• Host, User-Agent, Cookie, and necessary request headers must be the same;

• The final status code and response content must be the same;

• The rule for following 301 and 302 redirects must be the same;

• Keep IPv4 or IPv6 consistent;

• Separate cache HIT, MISS, and dynamic requests;

• Test region, carrier, and time should be close;

• File size and compression method must be the same;

• Each test unit should have a sufficient and similar sample size.

Pay special attention to the final returned content. HTTP 200 does not necessarily mean the correct page was retrieved; WAF verification pages, default sites, and soft error pages can also return 200.

Step 2: Use curl to record connection and first-byte times

The following command outputs response headers, final status code, resolved IP, redirect count, and cumulative time for each phase:

curl -L -sS -o /dev/null -D - \
  -w '\nstatus=%{http_code}\nurl=%{url_effective}\nremote_ip=%{remote_ip}\nredirects=%{num_redirects}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nredirect_time=%{time_redirect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/test.html

The curl official manual defines these fields as follows:

• time_namelookup: from start until domain name resolution completes;

• time_connect: from start until the TCP connection completes;

• time_appconnect: from start until TLS and other connection steps complete;

• time_starttransfer: from start until the first byte is received;

• time_total: the entire operation completes;

• time_redirect: cumulative time consumed by all previous redirects before entering the final request.

You can checkthe curl official manualto verify the field meanings.

Most of these times are cumulative from the start of the request and cannot simply be added together. For example,time_starttransferalready includes the preceding resolution, connection, and waiting processes.

For the same URL, run multiple tests in succession and cover different time periods. If the first result differs greatly from later ones, continue checking connection reuse, DNS cache, and CDN cache status.

Step 3: Break down the time before waiting for TTFB in the browser

Chrome DevTools can help answer a key question: is the high time in DNS, connection, and TLS, or in waiting for a response after the request is sent?

How to do it:

1. Open DevTools and go to Network;

2. SelectPreserve log, preserve redirect records;

3. To simulate a first visit, selectDisable cache;

4. Refresh the page and select the initial HTML document request;

5. Open Timing and check DNS, Initial connection, SSL, Request sent, Waiting, and Content Download;

6. Check the status code, remote address, cache status, and redirect location in Headers.

If DNS, TCP, and TLS are all low while Waiting is notably high, that is when you should focus on CDN processing, origin fetches, and server response preparation.

If the so-called “high TTFB” is mainly spent in DNS or the connection phase, optimizing the database directly usually will not help much.

Step 4: Use multi-region testing to determine whether the problem is local or global

A single local test cannot represent all users. The CDN schedules nodes based on region, carrier, and DNS results, so different users may take completely different paths.

You can useCdnChart website speed testto observe resolved IPs, connection times, TTFB, total time, and status codes across multiple regions and carriers, focusing on the following patterns:

• Whether one carrier is generally higher;

• Whether a certain province is routed to a distant node;

• Whether domestic access is normal and overseas is abnormal, or vice versa;

• P50 normal but P95 clearly high;

• Whether HIT and MISS show different distributions;

• Whether peak hours are noticeably slower than off-peak hours.

If dynamic requests slow down simultaneously across all regions and carriers, the origin or shared origin fetch path is more likely; if only certain regions are abnormal, check node scheduling and regional routes first.

Do not look only at national averages. A few high-performing nodes can dilute a serious anomaly on a major carrier.

Step 5: Perform origin comparison testing safely

The purpose of origin comparison is to bypass the CDN edge layer as much as possible and observe how the origin responds under the same Host, path, and TLS conditions, but this must be done carefully.

Provided you are authorized and the origin allows access from the current test IP, you can usecurl --resolveto temporarily point the domain to the specified origin IP while retaining the correct Host and TLS SNI:

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/test.html

The address203.0.113.10here is only a documentation example address; when actually using it, replace it with your own test origin address.

Keep in mind:

• Do not submit the real origin IP to public speed test platforms;

• Do not leave public access to the origin open long-term for testing;

• Do not remove the security policy that only allows CDN origin IPs to access the origin;

• Prefer testing through VPN, bastion hosts, internal probes, or temporary allowlists;

• Use read-only test paths to avoid triggering orders, logins, or data modifications;

• If the origin already prohibits direct connections, a failed direct test is expected and does not mean the origin is down.
  

An even better approach is to also record request processing time at the origin reverse proxy or application layer.

For example, request time and upstream response time in Nginx logs, or database and external API latency in application performance monitoring. This further separates “network waiting” from “application processing.”

What are common CDN-side causes of high TTFB?

Suboptimal node scheduling

If users do not hit an appropriate regional or carrier node, TCP connection and TLS handshake times increase. Even if the asset ultimately results in a HIT, the first byte can still be slow.

You can useCDN detection toolsto check different resolution results, node IPs, and the CDN likely in use, then combine that with multi-region speed tests to judge whether scheduling is reasonable.

Over-fragmented cache keys

If query parameters, cookies, headers, or device type are all part of the cache key, the same content can be split into a large number of cache versions.

Caching may appear to be configured, yet requests frequently MISS.

Before making changes, confirm which variables actually change the response content. Blindly ignoring query parameters or cookies can also cache personalized content that should not be shared with other users.

TTL too short or frequent cache purges

A cache lifetime that is too short and a release process that frequently purges everything both increase MISSes and origin fetches.

Set TTL based on how often content changes, and prefer targeted purges instead of clearing the entire cache on every release.

Origin fetch node too far from the origin

Users may be close to the edge node, but the edge node must fetch from the origin across regions or even continents. Dynamic requests and cache MISSes both pay the cost of this path.

Consider a more suitable origin region, regional origins, Origin Shield, or tiered caching, but balance consistency, cost, and failover design.

Edge security and compute rules too heavy

Complex WAF rules, bot detection, edge functions, authentication, and multiple internal rewrites can increase processing cost.

You should not disable necessary security capabilities just to shave off a few dozen milliseconds, but you can check for duplicate rules, inefficient logic, or unnecessary site-wide execution.

Redirects occurring at the CDN edge

HTTP-to-HTTPS redirects, bare-domain redirectswww, language redirects, and path normalization, if layered on top of one another, can make users go through multiple round trips before actually requesting content.

The goal is not to eliminate all redirects, but to avoid a chain of redirects that could be combined.

What are common origin-side causes of high TTFB?

Application worker processes or connection pools queuing

After a request reaches the server, it cannot immediately obtain execution resources and must wait for PHP-FPM, a Java thread pool, the Node.js event loop, or a database connection pool.

Normal during off-peak periods but a sudden rise in P95 during peak periods is common in this situation.

Database query, lock, or cache issues

Missing indexes, slow queries, lock waits, cache stampedes, and connection pool exhaustion can all drag the first byte of a page to several seconds.

You need to look at the duration of specific queries, not just the average database CPU.

External APIs slowing down the entire page

If payment, inventory, recommendation, identity verification, or third-party data APIs use synchronous waiting, the origin cannot return the page promptly whenever any one of them slows down.

Set reasonable connection and read timeouts, and design degradation, caching, or asynchronous processing according to the business requirements.

Server resource saturation

Low CPU does not mean the server has no bottleneck.

Disk I/O, memory swapping, network connection count, file descriptors, container limits, and single-threaded hotspots can all cause queuing.

Checks should cover peak periods and the specific times when slow requests occur, not just daily averages.

Cold starts or runtime initialization

For serverless functions, scaled containers, and application instances after hibernation, the first request may need to initialize the environment, establish database connections, or load dependencies, causing a small number of requests to have very high TTFB.

These issues are usually more likely to appear in P95 or P99 rather than P50.

Origin caching not taking effect

CDN caching and origin page caching are two different cache layers.

Even if dynamic pages are not suitable for public CDN caching, application caching, object caching, or database query caching can still reduce generation time.

Define your goal before fixing; don’t just chase a single lowest value

TTFB optimization is better measured by a stable set of metrics:

• 
  P50 and P95 in core regions and carriers;
  

• Separate statistics for static HIT, MISS, and dynamic requests;

• HTTP success rate, timeout rate, and 5xx ratio;

• CDN origin fetch ratio and cache hit ratio;

• Origin application processing time and upstream response time;

• Difference between peak and off-peak;

• Baselines before and after releases or configuration changes.

If after optimization the best local result drops from 180 ms to 160 ms, but P95 for core users is still over two seconds, the actual problem has not been solved.

Conversely, if the average changes little but timeouts and tail slow requests drop significantly, user experience may already be markedly improved.

Frequently asked questions

Does high TTFB always mean poor server configuration?

Not necessarily.

TTFB recorded by a browser or speed test tool may include DNS, connection, TLS, network round trips, CDN processing, origin fetches, and origin response. Break down each phase first, then determine whether the server is the real bottleneck.

Why is TTFB still high when there is a cache HIT?

A HIT only means the content was served from cache; it does not mean the route from the user to the node is necessarily fast.

Node scheduling, carrier networks, TCP/TLS, edge security rules, node load, and measurement methodology can all affect TTFB.

The origin is fast when tested directly, so why is it slower through the CDN?

First confirm whether the direct test location is fair.

If the direct test machine is in the same data center as the origin while the CDN origin fetch node is in another location, the two are not comparable. Also check origin TLS, connection reuse, origin security checks on CDN IPs, and cache status.

Will adding more CDN nodes reduce TTFB?

Not necessarily.

The number of nodes cannot replace proper scheduling, carrier interconnection, node capacity, and origin fetch design. If the problem lies in the origin application or database, adding edge nodes offers limited help for dynamic requests.

TTFB is already low, so why does the website still load slowly?

TTFB only goes as far as “first byte received.” After that come HTML download, images, CSS, JavaScript, fonts, third-party APIs, and browser rendering.

See also “Ping Is Fast, but the Website Is Slow? Don’t Mistake Latency for Load Speed” to check the download and rendering phases.

Should you contact the CDN or server operations first?

It is more effective to prepare evidence before contacting them: test time for the same URL, region, carrier, resolved IP, status code, cache status, DNS/TCP/TLS/TTFB, P50/P95, and origin logs from the same period.

If HITs remain high in specific regions, have the CDN check nodes and routes first; if MISSes and dynamic requests are broadly high while origin processing time is also elevated, the server and application teams should investigate first.

If origin processing is normal but CDN origin fetch waiting is notably high, both sides should then jointly review the origin fetch path and connection strategy.