TTFB Troubleshooting Checklist: Is Caching the Bottleneck or the Fix

Overview

TTFB measures how long it takes from the start of the request until the browser receives the first byte of the response. It is not the whole performance story, but it is a useful diagnostic signal because it reveals where waiting happens before content starts flowing. A slow TTFB often points to one of four broad causes:

• Name resolution and connection setup: DNS, TLS negotiation, and network path issues can add time before the request reaches the application.
• CDN and edge behavior: a cache hit can hide origin latency, while a miss can expose it. Misconfigured edge caching can either fix TTFB or make it inconsistent.
• Origin and server caching: reverse proxy cache, page cache, object cache, and PHP worker capacity all affect how quickly the origin can answer.
• Application and database work: dynamic rendering, uncached queries, expensive plugins, and session-dependent logic can turn every request into a slow one.

The practical goal is not to chase a single universal TTFB number. The goal is to determine whether caching is currently helping, being bypassed, or masking a deeper bottleneck. That distinction matters because the fix for a cache miss is different from the fix for CPU saturation, and both are different from the fix for poor DNS performance.

Before you begin, standardize your test conditions:

• Test the same URL repeatedly, including a known cacheable page and a known dynamic page.
• Run tests from more than one region if your audience is geographically distributed.
• Compare first request versus repeated request behavior.
• Record response headers such as cache-control, age, x-cache, cf-cache-status, or host-specific cache indicators.
• Separate anonymous traffic from logged-in or cart/session traffic.

If repeated anonymous requests remain slow, caching may be missing or ineffective. If the first request is slow but subsequent ones are fast, caching may be working as intended. If CDN hits are fast but users still report inconsistent performance, you may be dealing with cache invalidation, regional edge coverage, or dynamic routes that bypass cache.

Checklist by scenario

Use the scenario that best matches what you are seeing. In practice, you may work through more than one.

Scenario 1: TTFB is slow for every page, including static-looking pages

What this usually suggests: the problem may be upstream of the application, or your cacheable content is not actually being cached.

1. Check DNS and connection setup first. If requests are slow before they even reach the server, origin tuning will not fix the whole problem. Confirm that your domain is resolving correctly, that there is no unexpected redirect chain, and that TLS is not repeatedly renegotiating under odd conditions.
2. Inspect whether the response is served from CDN or origin. Look for cache status headers. A pattern of repeated misses on the same URL usually means your cache rules, TTL settings, cookies, or query strings are preventing reuse. If you rely on edge delivery, review your Cloudflare cache rules or equivalent edge policies.
3. Verify origin page caching. On WordPress and PHP sites, check whether page cache is active through Nginx FastCGI cache, Varnish, LiteSpeed Cache, or a managed host's built-in layer. If you are comparing reverse proxy options, see Varnish vs Nginx FastCGI Cache.
4. Confirm the page is actually cacheable. Responses with no-store, private, session cookies, personalized fragments, or cart-related state may bypass caching by design.
5. Compare repeated requests. If the second and third requests are not materially faster, caching is likely not taking effect where you expect.

Scenario 2: Anonymous pages are fast, but logged-in or ecommerce pages are slow

What this usually suggests: caching is working for public pages, but dynamic logic is dominating on personalized routes.

1. Map cache exclusions intentionally. Account pages, checkout, cart, and session-driven routes should usually bypass full-page cache. That is normal. The question is whether too many pages are excluded. On WooCommerce, review route and cookie exclusions against your actual user journeys. Our WooCommerce caching guide is useful here.
2. Differentiate page cache from object cache. Full-page cache helps anonymous traffic most. Logged-in and transactional traffic often benefits more from persistent object cache such as Redis. If page rendering still depends on repeated database lookups, TTFB will stay high for dynamic users.
3. Review plugin and theme overhead. Slow dashboard-like pages, account areas, and filtered catalog views may trigger expensive queries or remote API calls.
4. Check PHP worker pressure. Even a well-cached site can suffer high TTFB for uncached requests if worker capacity is limited and requests queue during bursts.

Scenario 3: TTFB is good on some requests and terrible on others

What this usually suggests: inconsistent cacheability, uneven edge behavior, or origin contention under load.

1. Group URLs by behavior. Static pages, blog posts, category archives, search results, checkout, preview URLs, and API endpoints should not be mixed together in one diagnosis.
2. Check query strings and campaign parameters. Some setups treat every variant as unique; others ignore selected parameters. If marketing links generate low cache hit rates, normalize or exclude harmless parameters.
3. Look at cookies. A single unnecessary cookie can convert a broadly cacheable page into a cache bypass. Audit which cookies are present on anonymous requests.
4. Compare edge region performance. If one geography has slow TTFB while another is fast, the issue may be regional cache fill, edge routing, or a distant origin rather than application logic.
5. Measure cache hit ratio. Inconsistent TTFB often tracks with poor hit ratio. See How to Measure Cache Hit Ratio and Why It Matters for Website Performance.

Scenario 4: TTFB became slow after a deployment, cache change, or hosting migration

What this usually suggests: a behavior change, not a mystery. Start with what changed.

1. Review new headers and rules. Compare response headers before and after the change. A new set-cookie header, stricter cache-control, or altered edge rule can explain a sudden jump.
2. Check purge and invalidation behavior. If content is being purged too aggressively, every burst of traffic may regenerate pages at origin. Our guide to cache invalidation strategies covers the tradeoffs between purge, revalidation, versioning, and stale-while-revalidate patterns.
3. Inspect origin cache warmup assumptions. A new environment may have no warmed cache after deploy, so test cold versus warm performance separately.
4. Confirm the managed host's caching stack. Some managed WordPress hosting plans use opinionated caching layers that interact differently with plugins and custom rules. If you are evaluating hosting tradeoffs, start with Managed WordPress Hosting for Speed.

Scenario 5: CDN is enabled, but TTFB is still high

What this usually suggests: the CDN is either passing too much traffic to origin or is not caching the right assets and pages.

1. Verify what the CDN is allowed to cache. A CDN does not automatically fix slow dynamic HTML unless your rules permit useful edge caching.
2. Check TTL settings. TTL that is too short can keep the edge cold. TTL that is too long can create freshness problems that force emergency purges. Use balanced durations and revisit them over time. See the TTL settings guide.
3. Inspect origin response headers. If the origin marks content as private or uncacheable, the CDN may simply honor those instructions.
4. Review CDN plan and product fit. Different providers expose different cache controls, edge features, and purge workflows. If you are comparing options, our best CDN guide can help frame the evaluation.

Scenario 6: WordPress TTFB is slow and you are unsure whether the cache plugin is helping

What this usually suggests: you need to verify the actual active cache layer rather than assume the plugin is the main factor.

1. Identify the primary page cache layer. Is caching happening at plugin level, web server level, reverse proxy level, or managed host level? Multiple layers can help, but they can also obscure where misses occur.
2. Check whether the plugin duplicates built-in hosting cache. Some hosts recommend specific plugins; others prefer their own stack. Conflicting purges or headers can reduce predictability.
3. Test with and without object cache. Redis object cache can materially improve dynamic request TTFB where database lookups dominate.
4. Evaluate plugin feature overlap. Minification, image optimization, and preload features are useful, but they do not replace correct page caching. For comparisons, see Best WordPress Cache Plugins Compared.
5. If using Nginx, inspect FastCGI cache behavior directly. Our Nginx FastCGI cache setup guide explains what to validate.

What to double-check

This section is the practical center of the checklist: the items that are easy to miss and often explain confusing TTFB readings.

• Cold cache versus warm cache: Always label your tests. A cold request may be legitimately slower if it triggers generation and fill. A warm request should usually be much faster for cacheable content.
• HTML versus static assets: Slow HTML TTFB points to routing, CDN, or origin issues. Static assets often follow different cache rules and may look healthy even when pages are not.
• Authenticated versus anonymous traffic: Do not treat a fast cached homepage as proof that your application is healthy for customers using carts, dashboards, or account sessions.
• Header consistency: Compare cache-control, vary, set-cookie, and cache status headers across templates. One template family may silently bypass the stack.
• Redirect chains: HTTP to HTTPS redirects, www/non-www canonicalization, locale routing, and trailing slash normalization can make TTFB appear worse than the underlying page generation actually is.
• Query parameter handling: Decide which parameters should create unique cache entries and which should be ignored. This matters for analytics, campaign tags, filters, and search pages.
• Database and upstream services: If your application calls external APIs before responding, caching may not help enough unless those calls are cached or deferred as well.
• Benchmark method: Browser tests, synthetic tests, command-line requests, and real user conditions can all produce different numbers. Use more than one lens and compare trends rather than fixating on a single measurement.

A useful mental model is this: page cache reduces generation time for cacheable pages; object cache reduces repeated computation and query cost for dynamic requests; CDN cache reduces distance and shields the origin; DNS performance reduces time before the request can even be sent to the right place. TTFB improves most when these layers work together rather than when one layer is tuned in isolation.

Common mistakes

Many TTFB investigations stall because teams change too much too quickly or interpret cache behavior too loosely. These are the mistakes worth avoiding.

• Assuming every slow TTFB issue is an application problem. Sometimes the delay is at the DNS, TLS, or CDN layer.
• Assuming a CDN guarantees fast TTFB. If the edge is not serving hits, you are still paying origin latency.
• Treating page cache and object cache as interchangeable. They solve different problems. This is especially important in the page cache vs object cache discussion for dynamic sites.
• Testing only the homepage. Product pages, category pages, account pages, search results, and API endpoints often behave differently.
• Ignoring cache exclusions created by cookies. Marketing, A/B testing, personalization, and consent tooling can unintentionally reduce cacheability.
• Purging too broadly. Over-purging keeps caches cold and can make TTFB unstable during traffic spikes.
• Setting TTLs without a freshness plan. Short TTLs reduce staleness but can undermine hit ratio; long TTLs require clearer invalidation strategy.
• Stacking too many overlapping cache controls. Multiple plugins, host-level rules, and CDN overrides can make troubleshooting much harder than necessary.
• Using one test run as proof. TTFB should be evaluated over repeated requests, multiple routes, and ideally more than one region.

If you reach the point where all cacheable pages are fast but business-critical dynamic routes remain slow, caching may no longer be the primary bottleneck. That is often the moment to inspect application profiling, database indexes, queueing under load, and hosting capacity rather than endlessly adjusting cache headers.

When to revisit

TTFB troubleshooting is not a one-time project. It should be revisited whenever the inputs to your delivery path change. A practical review cadence keeps small regressions from turning into expensive performance incidents.

Revisit this checklist in these situations:

• Before seasonal planning cycles: traffic spikes expose weak cache hit ratio, low worker capacity, and over-aggressive purge behavior.
• When workflows or tools change: new deployment patterns, security tools, consent platforms, edge rules, cache plugins, or host migrations can all alter TTFB.
• After major theme or plugin changes: especially on WordPress, where rendering logic and cookie behavior can shift quickly.
• After CDN, DNS, or proxy reconfiguration: edge caching and domain DNS speed should be revalidated after any routing change.
• When Core Web Vitals or monitoring trends worsen: even if front-end metrics look like the problem, slow TTFB may be contributing.

For an action-oriented review, keep a lightweight recurring worksheet with these five checks:

1. Test one anonymous cacheable page cold and warm.
2. Test one logged-in or transactional page.
3. Record cache status headers and TTFB for both.
4. Check cache hit ratio trends and purge frequency.
5. Note any recent changes to hosting, DNS, CDN, plugins, or application code.

If you use this checklist consistently, you will usually answer the important question faster: is caching the bottleneck, or is caching the fix? Sometimes the answer is that the cache is absent or bypassed. Sometimes it is present but hiding an origin problem. And sometimes it is doing exactly what it should, while the real work lies deeper in the application or infrastructure stack. The discipline is in separating those cases before you act.