Get in Touch

Reduce TTFB: Diagnose First, Then Apply 5 Quick Wins

Oct 10, 2026

The fastest way to reduce TTFB is to edge-cache your HTML with a CDN, strip out redirect chains and extra connection hops, and fix origin processing with in-memory caching or runtime caches like Redis and OPcache. Each lever targets a different stage of the request, so the order you apply them in matters: cache first, then network, then code. Expect the biggest single jump from moving cacheable pages to the edge.

TL;DR:

  • Measure TTFB with real user and lab tests from the same URL and region, judge the 75th percentile, and use Server-Timing to isolate origin delays.
  • Cache public HTML at the CDN edge, but vary cache keys for personalized or regional responses, then verify delivery through Age and cache status headers.
  • Use 103 Early Hints for pages with resources that block rendering, but measure finalResponseHeadersStart because responseStart may capture only the interim response.
  • Treat 0.8 seconds at the 75th percentile as the field target; Lighthouse’s roughly 600 millisecond threshold applies to its lab audit, not real users.
  • Profile the origin before upgrading hosting; Redis or Memcached can cache queries, sessions, and API responses, while OPcache prevents repeated PHP script compilation.
Webby Website Optimisation
webby.net.au
Improve Your Website’s Response Time
Webby helps local service businesses improve website performance through WordPress design, development, and speed optimization.

Explore Webby’s services

Table of Contents

Quick wins to lower TTFB today

Before touching application code, run through the checks that tend to produce the fastest, lowest-risk gains. These are the fixes most teams can complete in a single sprint without a rewrite.

  1. Edge-cache public pages where safe, then confirm it worked by checking the Cache-Control and Age response headers.
  2. Eliminate same-origin redirect chains and enable HSTS so browsers skip the HTTP to HTTPS hop entirely.
  3. Turn on HTTP/2 or HTTP/3 and TLS 1.3 through your host or CDN to cut handshake round trips.
  4. Enable PHP OPcache and add Redis for session and query caching to shrink origin processing time.
  5. Audit DNS resolution times for the regions your traffic actually comes from, and switch providers if lookups are slow.

Each of these addresses a distinct bottleneck, which is why order matters. A redirect chain adds a full round trip before the server even starts working, and no amount of database tuning fixes that. Caching headers that are set incorrectly can silently void everything else on this list, so verify them after every change rather than assuming a deploy worked.

How to measure TTFB and diagnose the real bottleneck

TTFB is the time between a browser’s request and the first byte of the response, and the right way to measure it in-browser is with performance.getEntriesByType('navigation').responseStart, according to MDN’s definition. When a page uses 103 Early Hints, that same source notes you should check finalResponseHeadersStart instead, since responseStart may only capture the interim response.

  • Collect both real user monitoring (RUM) data and lab data from the same URL and region, and judge results at the 75th percentile rather than the average.
  • Add a Server-Timing header on the backend to expose database, cache, and application durations directly to the browser’s dev tools, as described in MDN’s Server Timing documentation.
  • Use Chrome DevTools, the Lighthouse server-response audit, and WebPageTest to break the request into redirects, DNS, connection setup, TLS, and waiting time.
  • Follow a repeatable loop: measure, identify the dominant component, fix only that bottleneck, then re-measure before moving to the next one.

Pro Tip: Don’t optimize database queries before you’ve confirmed the database is actually the slow part. Connection setup and redirects can dominate TTFB just as often as backend code, according to Smashing Magazine’s analysis.

Network and protocol fixes that cut connection time

A content delivery network lowers TTFB in two separate ways: it physically shortens the distance a request travels, and it can serve a cached copy of the HTML without ever contacting your origin. The guidance from Web highlights serving cacheable HTML from a nearby edge node, paired with correct Cache-Control headers, as one of the highest-leverage fixes available.

  • Enable HTTP/3 and TLS 1.3 wherever your host or CDN supports them, since both protocols reduce the round trips needed to establish a secure connection compared to older versions.
  • Audit your redirect chains with a tool like WebPageTest and collapse any multi-hop sequence (HTTP to HTTPS to www to final URL) into a single hop.
  • Turn on HSTS so returning visitors’ browsers connect directly over HTTPS and skip the redirect entirely on repeat visits.
  • Consider 103 Early Hints for pages with render-blocking resources, but remember to measure finalResponseHeadersStart rather than the interim response when you do.
  • Set cache keys carefully: caching HTML by URL alone can serve the wrong content to logged-in users or regional visitors, so include the variables that actually change the response.

Server-side fixes: caching, database tuning, and runtime changes

Once network and edge fixes are in place, the remaining TTFB usually comes down to how long your origin takes to build the response. Profile the application first: find the slow queries and long-running CPU tasks before you assume you need bigger hosting.

  • Add Redis or Memcached for query results, session data, and API responses using a cache-aside pattern, which can take server-processing time from hundreds of milliseconds down to single digits, per Redis’s own TTFB testing.
  • Enable PHP OPcache so scripts don’t get recompiled on every request, and layer in full-page or fragment caching for pages that don’t change per visitor.
  • Where your framework supports it, consider streaming server-side rendering so the browser receives the first HTML fragments before the entire page has finished generating.
  • Never cache personalized content under a generic key. A cart page or account dashboard served from the wrong cache entry is a correctness bug, not just a performance one.

Pro Tip: Fix the dominant bottleneck first. If Server-Timing shows your database query taking 400ms out of a 450ms TTFB, OPcache alone won’t move the needle.

Choosing hosting and deployment patterns that keep TTFB low

The right infrastructure choice depends on whether your bottleneck is origin capacity or network distance. Scale CPU and RAM only after profiling confirms the origin itself is the slow part. If most requests can be served from cache, adding server capacity fixes the wrong problem.

  • Proximity to the origin only matters for requests that actually reach it, so global audiences benefit most from a CDN that can serve cached HTML from many regions at once.
  • Managed edge platforms, serverless functions, and autoscaling origin servers all handle bursty traffic differently, and the right pick depends on how predictable your traffic spikes are.
  • Check CPU load, memory pressure, disk or I/O wait times, request queueing, and network bandwidth on your current host before deciding whether to upgrade or migrate.
  • Shared hosting environments often show higher and less consistent TTFB than dedicated or managed infrastructure, since you’re competing with other tenants for the same resources.

A practical WordPress checklist for lower TTFB

WordPress sites tend to accumulate the same TTFB problems: too many plugins querying the database on every request, no object cache, and caching plugins that are misconfigured rather than absent. We’ve worked through this exact sequence on client sites often enough to trust the order.

  1. Run Query Monitor to find which plugins and queries are actually slow, and fix those specific issues before deactivating anything blindly.
  2. Enable PHP OPcache on the server and add a Redis object cache so repeated queries stop hitting the database every time.
  3. Layer in full-page caching or edge-cache integration, and check that cookies set by plugins (carts, consent banners) aren’t quietly disabling the cache for every visitor.
  4. Set a purge strategy that clears the right cache keys on deploy, not the entire cache, so you’re not serving a cold site to everyone after every update.

For a deeper breakdown of common speed problems beyond TTFB, our guide to website speed issues covers the adjacent fixes worth checking at the same time. If you manage a WordPress site and want this handled rather than DIY’d, our WordPress speed optimisation work follows this same checklist end to end.

How to verify your fixes actually worked

Rerun both RUM and lab tests after every change, and test cold cache (first visit) and warm cache (repeat visit) separately, since they tell you different things. Track TTFB at the 75th percentile and watch whether First Contentful Paint and Largest Contentful Paint improve downstream, since that’s the real point of the exercise.

  • Check Server-Timing entries to confirm database and application durations actually dropped, not just the total.
  • Use the Lighthouse server-response audit’s roughly 600ms threshold as a lab guide, and web.dev’s 0.8-second, 75th percentile field target as the real-world bar, per Lighthouse’s own documentation.
  • Watch Age and X-Cache headers after a deploy to confirm the CDN is actually serving from cache and not silently falling back to origin.
  • Add a regression check to your deploy pipeline so a future change doesn’t quietly reintroduce a redirect chain or break the cache key.

Why most TTFB advice skips the diagnosis step

Most TTFB guides jump straight to “add a CDN” or “enable OPcache” without ever asking which stage of the request is actually slow. That’s backward. A redirect chain adds latency a cache can’t fix, and a slow database query won’t improve no matter how many edge nodes you add.

The habit worth building isn’t a specific fix, it’s the sequence: measure the components, find the one actually dominating your TTFB, fix that one thing, then measure again. Teams that skip straight to code changes often spend a week optimizing a query that was never the bottleneck in the first place.

— Steve Doig

Get a diagnosis instead of guessing

If you’d rather have someone run this diagnostic workflow on your actual site than piece it together yourself, our Website Audit is built for exactly this: a report that identifies which stage of your TTFB is the real bottleneck and what to fix first, with current pricing listed on our website.

Webby Website Optimisation

For WordPress sites that need the fix applied and maintained over time, our Monthly Maintenance plan covers the ongoing caching and technical upkeep that keeps TTFB from creeping back up after a deploy, with current pricing listed on our website.

FAQ

What is server response time?

Server response time is the portion of TTFB spent on your origin actually generating the response, separate from DNS lookup, connection setup, and network travel. It’s one component among several, which is why the Lighthouse server-response audit flags it specifically once it passes roughly 600 milliseconds.

How can I improve server speed?

Start by profiling your application to find slow database queries and long CPU tasks, then add caching, in the form of an object cache like Redis or a runtime cache like PHP OPcache, rather than guessing at hardware upgrades. Redis’s own testing shows cache-aside patterns can cut server-processing time from hundreds of milliseconds to single digits.

What causes high TTFB?

High TTFB can come from slow origin processing, but connection setup, TLS handshakes, and redirect chains frequently dominate the total just as much, according to Smashing Magazine’s TTFB analysis. Measuring each component with Server-Timing and browser dev tools is the only reliable way to tell which one applies to your site.

What TTFB should I be targeting?

Web.dev recommends aiming for about 0.8 seconds at the 75th percentile as a field target, and treats anything above 1.8 seconds as poor. Lighthouse uses a separate, stricter lab threshold of around 600 milliseconds for its server-response audit, so expect the two numbers to differ.

Sources

Do you need help with problems this article has raised? Click here