Time to first byte (TTFB) measures how long a browser waits before receiving the first part of a response. This guide gives you a repeatable workflow to diagnose slow TTFB, separate DNS, network, origin, database, and CDN delays, and verify whether each change actually improves website speed.
Overview
TTFB is not a single server-speed metric. It is the result of several stages: DNS resolution, connection setup, request routing, edge processing, origin processing, and the delivery of the first response bytes. A slow result may come from any one of these stages, or from several small delays occurring together.
For a cached page, the request may be answered by a nearby CDN point of presence without reaching the origin. For an uncached page, the edge may need to connect to the origin, run application code, query a database, and generate the response before sending it back. This distinction is essential when you are trying to improve TTFB: optimizing the origin will not fully solve a request that is spending most of its time in DNS or network setup, while changing CDN settings will not fix an inefficient database query.
Start by measuring the same URL under controlled conditions. Record the test location, protocol, device or connection type, cache state, response status, and relevant headers. Compare a cache hit with a cache miss where possible. A useful baseline might include the homepage, a representative content page, a logged-in or personalized route, and an API endpoint if the site depends on one.
Step-by-step workflow
1. Confirm what is actually slow
Use a browser waterfall, a command-line request, and a field or synthetic performance tool. Look for the interval before the first response byte rather than treating total page load time as TTFB. A page can have acceptable TTFB but still load slowly because of render-blocking resources, large images, third-party scripts, or inefficient client-side code.
Test from more than one geographic location. A result from a machine near the origin can hide problems experienced by visitors on another continent. Repeat each test several times because connection reuse, cache state, and temporary server load can change the result.
2. Separate DNS and connection time from server processing
Run a DNS speed test or inspect the browser waterfall to determine whether lookup time is disproportionate. Check that the hostname resolves consistently to the intended provider and that the DNS configuration is not sending visitors through an unnecessary chain of records or routing layer. DNS changes should be evaluated separately from origin changes so that you can identify which adjustment produced an improvement.
Also distinguish DNS lookup, TCP connection, TLS negotiation, request transmission, and waiting for the response. A slow TLS handshake may point to connection placement or network conditions rather than application code. HTTP protocol support, connection reuse, and geographic routing can affect these stages, but they should be measured rather than assumed to be the cause.
3. Measure the origin directly
Request the origin through a controlled hostname or monitoring path, while preserving the same URL and request method. Compare the direct origin response with the CDN response. If the origin is slow even when tested close to its hosting region, investigate application execution, database work, external API calls, filesystem access, and server resource pressure.
For WordPress, review plugin execution, uncached page generation, object-cache availability, and slow queries. For other applications, inspect request traces and database timings. A reverse proxy cache can reduce repeated work, but it should not conceal a broken or consistently overloaded origin. Address long-running work where practical, and move nonessential processing out of the critical request path.
4. Check CDN and reverse proxy behavior
Confirm whether the response is a cache hit, miss, bypass, or revalidation. The exact header names vary by platform, so use your CDN documentation and response headers as the source of truth. A low cache hit ratio can force the origin to handle more requests than expected, increasing TTFB during traffic spikes.
Review cache rules for HTML, static assets, and APIs separately. Static files can generally use long-lived caching when their URLs are versioned. HTML needs a deliberate freshness and invalidation policy. Personalized pages, checkout routes, account areas, and responses containing private data should not be cached publicly without a carefully tested design. For a broader policy framework, see the Cache-Control headers guide and the guide to browser, CDN, and origin caching.
Check whether cookies, query strings, authorization headers, or response directives are causing unexpected bypasses. Verify that the CDN can reach the origin efficiently and that the origin is not rate-limiting legitimate edge requests. After changing a rule, perform a deliberate cache purge when required, then test both the first request and subsequent requests.
5. Improve geographic delivery
If visitors are distributed across regions, an edge delivery network can reduce the distance between users and cached content. Test from the regions that matter to your audience, not only from the data center where the site is hosted. A CDN can improve TTFB for cacheable responses while leaving uncached, dynamic requests dependent on the distance to the origin.
When comparing providers, evaluate the actual routing model, cache controls, origin connection options, observability, purge behavior, and configuration complexity. A CDN comparison such as Cloudflare, Fastly, Bunny, and KeyCDN can help structure that evaluation without treating one provider as universally best.
6. Measure after every meaningful change
Keep a simple change log containing the date, URL, test locations, cache state, configuration change, and before-and-after results. Re-test under similar conditions and compare distributions or repeated runs rather than relying on one unusually fast request. Use Core Web Vitals tools for user-facing evidence, but retain lower-level waterfall and header checks for diagnosis.
Tools and handoffs
A practical investigation usually uses several tools, each answering a different question:
- Browser developer tools: Use the Network panel to inspect DNS, connection, TLS, waiting time, redirects, response headers, and waterfall order.
- Command-line requests: Use tools such as curl to compare direct origin and CDN paths, request headers, response headers, and repeated cache behavior.
- DNS utilities: Query records from different resolvers and locations to identify inconsistent resolution, unexpected records, or routing changes.
- Performance testing tools: Use synthetic tests and field data to compare geographic conditions and real-user outcomes.
- Server and application logs: Match slow requests with web-server timing, database duration, upstream calls, status codes, and resource usage.
- CDN analytics: Review cache hit ratio, origin request volume, cache status, bandwidth, error rates, and purge activity.
Define ownership before making changes. DNS, hosting, application, and CDN settings may be managed in different systems. A handoff should include the exact hostname or route, current behavior, evidence, proposed change, rollback method, and validation test. This prevents a vague request to “speed up the server” from turning into untracked configuration changes.
Quality checks
Before declaring the work complete, verify that the optimization did not trade speed for correctness:
- Test anonymous, authenticated, and personalized requests separately.
- Confirm that cache headers match the intended privacy and freshness policy.
- Check HTML, CSS, JavaScript, images, redirects, APIs, and error responses.
- Test cache misses, cache hits, purges, expired objects, and origin failures where safe.
- Compare several geographic locations and more than one network condition.
- Check that DNS changes resolve consistently and that certificates cover every hostname.
- Review origin CPU, memory, database, connection, and queue usage during representative load.
- Confirm that improvements to TTFB do not introduce stale content, leaked private data, broken sessions, or incorrect redirects.
If the CDN appears slower than the origin for a particular request, investigate cache status, routing, request headers, and origin connection reuse before removing it. A CDN is not automatically beneficial for every uncached dynamic response. The right configuration depends on the content, audience, origin location, and invalidation requirements.
When to revisit
Revisit TTFB after changing hosting, DNS, CDN providers, cache rules, TLS or protocol settings, WordPress plugins, application code, database structure, or major content templates. New geographic markets and traffic patterns are also valid reasons to repeat the assessment.
Set a recurring review based on how often the site changes, and keep the original baseline so trends remain visible. At minimum, investigate when field data worsens, cache hit ratio falls, origin traffic rises unexpectedly, or users report slow first responses in a particular region.
For the next review, choose a small representative test set, record cache-hit and cache-miss results, inspect DNS and origin timings, and compare the findings with the previous change log. If edge caching is the main opportunity, continue with the guide to reducing TTFB through edge caching and origin optimization. If misses are unexplained, use the CDN cache-miss troubleshooting checklist before changing providers. A repeatable measurement process is more valuable than a one-time tuning exercise because TTFB changes as infrastructure, content, and traffic change.
