How to Reduce TTFB and Make Your Website Respond Faster

To reduce TTFB, first separate DNS and connection time from CDN and origin time. Then serve safe responses from a nearby edge, remove unnecessary redirects and backend work, optimize slow queries and dependencies, and validate the result with measurements from real regions. TTFB is not a Core Web Vital, but it is a valuable diagnostic signal because a late first byte delays HTML parsing and can push LCP later.

What TTFB includes

Time to first byte is the elapsed time between starting a request and receiving the first response byte. The exact breakdown depends on the browser and measurement tool, but the request path commonly includes:

• DNS resolution for the hostname.
• TCP connection and TLS negotiation, unless an existing connection is reused.
• Network transit from the visitor to the edge or origin.
• CDN lookup, cache hit or miss processing, and any edge logic.
• Queueing and application work at the origin.
• Database calls and requests to other services.
• The first response bytes traveling back to the client.

The number in a waterfall is therefore a symptom, not a diagnosis. A global site can have a good origin response but a poor TTFB for users far from the delivery network. A local site can have fast DNS and still be slow because every request waits on a database.

Step 1: Measure the breakdown

Use browser DevTools, curl -w, server timing headers, CDN logs, and your real-user monitoring data. A generic command for a first comparison is:

curl -sS -o /dev/null -w \
  'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/page

Run it more than once and keep the cache state visible. Inspect Age, ETag, cache status headers, response status, redirects, and Server-Timing. A CDN hit and an origin miss are different tests. If the response varies by cookie, authorization, language, or device, record those request headers too.

Field data is essential for the distribution of actual experiences. Lab data is better for controlled comparisons and regression tests. Track TTFB by route, region, device, and cache status rather than publishing one site-wide average.

Step 2: Improve DNS and connection setup

Use authoritative DNS that answers reliably from a suitable network and keep the DNS chain short. A slow or failing DNS provider delays every visit before the browser can connect. Optimi's managed DNS guide explains Anycast DNS and redundancy as delivery concerns, not just domain administration.

Reduce redirects. An HTTP-to-HTTPS redirect is often necessary at the edge, but a chain of host, locale, tracking, and application redirects adds round trips. Normalize the canonical URL once and redirect directly. Use HTTP/2 or HTTP/3 where your clients and delivery stack support them, keep connections reusable, and avoid forcing unnecessary cross-origin handshakes for critical resources.

Do not add preconnect hints for every third-party origin. A preconnect can save time for a genuinely critical connection, but too many hints compete for sockets and work. Measure the critical path first.

Step 3: Get cacheable work off the origin

The most direct TTFB improvement is a cache hit that answers near the user. Cache versioned CSS, JavaScript, fonts, images, and other immutable assets for a long time. Consider caching public HTML or API responses only when the response is identical for all requests sharing the cache key and its freshness policy is acceptable.

For a public response whose shared-cache lifetime differs from its browser lifetime, use explicit directives:

Cache-Control: public, max-age=60, s-maxage=600
ETag: "catalog-2026-07-14-42"

The browser can reuse the response for 60 seconds while a shared cache can reuse it for 10 minutes. This is a policy choice, not a universal recommendation. Confirm that Cloudflare, Fastly, or an equivalent CDN respects the origin policy or document the edge rule that overrides it. See CDN caching explained for cacheability decisions.

Avoid caching responses that contain a user's account details, cart, checkout state, or sensitive data. Set-Cookie, Authorization, and a broad Vary policy can cause bypasses or cache fragmentation. For personalized content, cache a public shell and fetch private data separately when that architecture is safe and useful.

Step 4: Reduce origin computation

Profile slow server transactions rather than increasing timeouts. Common causes include:

• Database queries without the right indexes or with unnecessary joins.
• N+1 queries generated by a template or API resolver.
• Synchronous calls to payment, search, recommendation, or inventory services.
• Cold starts, thread pool exhaustion, connection pool waits, or lock contention.
• Rendering an entire page when only a small fragment changed.
• Cache misses that stampede the same expensive work.

Set budgets for dependencies and fail gracefully when a non-critical service is slow. Reuse database and upstream connections. Precompute content that does not need request-time computation. Use background jobs for work that does not belong before the first byte. Add a request identifier so an edge log, application trace, database trace, and browser timing can be joined.

Step 5: Protect the origin from avoidable load

Origin shielding, request collapsing, and carefully designed cache keys can prevent many edge locations from requesting the same object simultaneously. Warm critical objects after a deployment only when you understand the load and freshness implications. Rate-limit abusive traffic and separate health checks from expensive application routes.

Caching is not a substitute for capacity planning. A site can look fast under warm-cache testing and fail during a purge, a new release, or a traffic spike. Test miss behavior and observe origin saturation while testing.

Common TTFB mistakes

Do not interpret TTFB as pure server processing time. Do not move the origin closer to one test location and assume global users improved. Do not cache all HTML to make a synthetic score smaller. Do not add a second CDN without a routing and cache-consistency plan. Do not use a long TTL without versioning or a tested purge process. Do not optimize DNS while an application is waiting seconds on a remote API.

Validation checklist

After a change, compare the same URL with a cold request and a warm request from the same regions. Check DNS, connection, TLS, TTFB, total time, status, redirects, Age, cache status, ETag, and Server-Timing. Confirm that anonymous, authenticated, localized, and cookie-bearing requests receive the correct representation. Watch origin CPU, queueing, database latency, error rates, and cache hit ratio during the rollout.

For the browser metrics that TTFB influences, read Core Web Vitals explained. For a broader sequence of performance work, use the 2026 slow-website checklist and technical SEO and GEO.

There are only two hard things in Computer Science: cache invalidation and naming things.