How to Reduce Time to First Byte (TTFB) on a Slow Website: A Developer’s Diagnostic Guide

/ Uncategorized

How to Reduce Time to First Byte (TTFB): Diagnose Before You Fix

If your website feels slow before a single pixel appears on screen, the culprit is almost always a high Time to First Byte. TTFB measures how long the browser waits between sending a request and receiving the first byte of the HTML response. According to Google’s own guidance, a healthy TTFB should sit at 0.8 seconds or less, while anything above 1.8 seconds is considered poor.

Most guides jump straight to fixes like “install a caching plugin” or “switch hosts.” This guide takes a different approach: diagnose first, fix second. Below you will find a developer-focused walkthrough for measuring TTFB with real tools, identifying the real bottleneck, and applying targeted fixes that actually move the needle.

website speed dashboard

What Exactly Is TTFB (and What It Isn’t)

TTFB is the sum of three distinct phases:

  1. Redirect time (if any HTTP redirects occur)
  2. Connection setup (DNS lookup, TCP handshake, TLS negotiation)
  3. Server processing time (application code, database queries, response generation)

A common mistake is confusing TTFB with total server response time. TTFB includes network overhead, which means a fast server in Frankfurt can still deliver a slow TTFB to a user in Sydney. Keep this distinction in mind when interpreting your measurements.

Step 1: Measure TTFB Accurately

You cannot optimize what you do not measure. Here are the tools we recommend, ranked by usefulness for developers.

Chrome DevTools

Open DevTools, go to the Network tab, reload the page, click the document request, and check the Timing tab. Look at the “Waiting for server response” value. This is your TTFB.

WebPageTest

WebPageTest runs tests from real browsers in real locations. It breaks down TTFB per region, which is invaluable for identifying geographic latency issues.

curl (command line)

For repeatable, scriptable measurements:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://yourdomain.com

DebugBear, SpeedCurve, or PageSpeed Insights

These give you field data from real users (RUM), not just lab measurements. Field data is what Google uses for Core Web Vitals ranking signals.

Tool Best For Data Type
Chrome DevTools Quick local checks Lab
WebPageTest Multi-region testing Lab
curl Automated monitoring Lab
DebugBear / PSI Real-user monitoring Field
website speed dashboard

Step 2: Isolate the Bottleneck

Once you have baseline numbers, narrow down where time is being lost. Ask these questions in order:

  • Is DNS lookup slow? (Check with dig or nslookup)
  • Is TLS handshake time excessive? (Consider TLS 1.3, session resumption)
  • Is the server processing time itself the issue?
  • Are there redirects adding round-trips?

If server processing dominates, dig into your application. Enable slow query logs on MySQL/PostgreSQL, add APM tracing (New Relic, Datadog, or open-source alternatives like OpenTelemetry), and profile the actual request lifecycle.

Step 3: Fix the Root Causes

1. Add or Improve Caching Layers

Caching is the single highest-leverage improvement for TTFB. Consider these layers, from closest to the user to closest to the database:

  • Edge caching / CDN: Cloudflare, Fastly, or Bunny CDN can serve cached HTML from a POP near the user, often bringing TTFB below 100 ms
  • Full-page cache: Varnish or nginx proxy_cache in front of your app server
  • Object cache: Redis or Memcached for expensive query results
  • Opcode cache: OPcache for PHP applications

2. Optimize Database Queries

Slow queries are the second most common cause of high TTFB. Run these checks:

  1. Enable the slow query log with a threshold of 100 ms
  2. Use EXPLAIN on suspicious queries to identify missing indexes
  3. Add composite indexes for common WHERE + ORDER BY patterns
  4. Kill N+1 queries with eager loading or batch fetching
  5. Consider read replicas for read-heavy workloads

3. Tune Your Server Stack

  • Upgrade to HTTP/2 or HTTP/3 to reduce connection overhead
  • Enable TLS 1.3 with session resumption to cut handshake time
  • Use Brotli compression instead of gzip where possible
  • Tune worker processes and pool sizes to match your traffic profile
  • Move to a faster runtime when applicable (PHP 8.3+, Node.js LTS, Go)

4. Reduce Third-Party Bloat on the Origin

Server-side calls to external APIs during page render are TTFB killers. If your backend calls an analytics API, a CRM, or a recommendation engine synchronously, that latency adds directly to TTFB. Move these calls to background jobs or client-side execution wherever possible.

5. Get Closer to Your Users

If your audience is global but your origin server is in one region, TTFB will vary wildly. Options include:

  • Deploying multiple origins with geo-routing
  • Using edge compute platforms (Cloudflare Workers, Vercel Edge Functions, Deno Deploy)
  • Enabling HTML edge caching with smart purge rules
website speed dashboard

A Realistic Before/After Example

Here is a typical progression we see on client projects:

Stage TTFB (p75) Change Applied
Baseline 2,400 ms Untuned LAMP stack
Step 1 1,100 ms Added indexes, killed N+1
Step 2 480 ms Redis object cache + OPcache
Step 3 90 ms CDN HTML edge caching

Common Mistakes That Keep TTFB High

  • Installing a caching plugin without verifying cache HIT ratios
  • Blaming the host when the real issue is application code
  • Ignoring TTFB variance by region
  • Measuring only from a single fast connection
  • Optimizing frontend assets before fixing the backend

Frequently Asked Questions

What is a good Time to First Byte in 2026?

Google still recommends aiming for 0.8 seconds or less at the 75th percentile. Values above 1.8 seconds are considered poor and will hurt Core Web Vitals scores.

Why is my TTFB so high on WordPress?

The usual suspects are: unoptimized database (missing indexes, bloated wp_options autoload), too many active plugins, no full-page cache, cheap shared hosting, and synchronous third-party API calls in themes or plugins.

How do I check TTFB in Chrome?

Open DevTools, go to the Network tab, reload the page, click the top document request, and look at the Timing tab. “Waiting for server response” is your TTFB.

Does a CDN always reduce TTFB?

Only if it caches the HTML document itself. A CDN that only caches static assets (images, CSS, JS) will not improve TTFB for the initial HTML request. Configure HTML edge caching to see real TTFB gains.

Is TTFB the same as server response time?

No. TTFB includes DNS, TCP, and TLS overhead in addition to server processing. Server response time is only the processing portion. Both matter, but they are optimized differently.

Final Thoughts

Reducing TTFB is not about applying every optimization trick you read online. It is about measuring, isolating the real bottleneck, and applying the right fix at the right layer. Start with real measurements, work from the biggest contributor down, and re-measure after every change. A methodical approach will consistently outperform shotgun optimization, and your Core Web Vitals will thank you.