How to Fix Slow TTFB and Improve Site Performance

Visitors feel delay long before they see your page.

Time to First Byte (TTFB) measures how quickly your server starts responding once a browser asks for a page. When TTFB is slow, your whole site feels sluggish, even if everything else is optimized. The good news: TTFB is measurable, diagnosable, and very fixable. This guide shows you how to pinpoint the bottleneck and improve results with a clear, step-by-step plan that works across platforms and budgets.

What TTFB Actually Measures

TTFB is the elapsed time from the moment a client sends an HTTP request until it receives the first byte of the response. It includes:

Network travel from the visitor to your edge or server
Connection setup (TCP/QUIC) and encryption (TLS)
Any waiting in queue at your edge or origin
Application work at the origin (routing, queries, templates, API calls)
The first byte leaving the server and arriving back at the client

Because it blends network and server work, TTFB acts like an early warning beacon. If it’s slow, you’re delaying everything that follows: HTML parsing, render-blocking requests, images, and scripts.

What is a “good” TTFB

Targets vary by stack and audience geography, but practical ranges are:

Global consumer site on a CDN: 100–300 ms for cached HTML
Regional small business site: 200–500 ms
Heavier dynamic pages (cart, dashboard): under 800 ms during normal load

Focus on consistency. A page that returns in 200 ms sometimes and 2 seconds at other times still feels slow.

How to Measure TTFB Correctly

You fix what you can see. Use multiple angles.

1) Command-line measurements

Use curl to isolate server timing without browser noise:

curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/

Run from different regions (or a cloud VM) to compare geography.

2) Browser developer tools

In Chrome DevTools, the Waterfall “Waiting (TTFB)” phase shows request-level TTFB. Test an incognito window to avoid extensions.

3) Synthetic monitoring

Use a reputable synthetic test to run scheduled checks from multiple locations. Track TTFB and total time side by side. Trend lines reveal regressions early.

4) Real user monitoring (RUM)

If your platform supports it, capture server-timing and network metrics from real users. RUM shows what your audience actually experiences across devices and networks.

5) Break out handshake timing

Measure DNS, TCP/QUIC, TLS, and TTFB separately. When the handshake is fast but TTFB is slow, the origin is the bottleneck. If handshake dominates, fix DNS, TLS, or routing first.

Diagnose by Layer: A Practical Decision Tree

Follow this sequence to narrow the cause.

Is HTML cached at the edge?
If cached pages return fast while dynamic pages are slow, the origin is the culprit.
Are slowdowns regional or global?
Only one region slow points to routing or a thin edge. Global slowness suggests origin compute or upstream dependencies.
Is the slowdown time-of-day specific?
Peaks during business hours indicate capacity ceilings, queueing, or noisy neighbors on shared hosting.
Do API calls inside page render dominate?
If templates wait on external services, TTFB climbs. You need caching, async patterns, or fallback content.
Do database queries spike?
Check index coverage, N+1 queries, and long transactions. Database latency shows up directly in TTFB.
Is TLS adding hundreds of milliseconds?
Old cipher suites, no session resumption, or cold caches at the edge can waste time.
Do you see connection reuse?
Lack of keep-alive or HTTP/2 multiplexing forces new handshakes for each request.

Answering these quickly tells you where to spend your next hour.

Fixes That Usually Move the Needle First

Start with changes that cost little and pay fast.

Put HTML behind an edge cache

Cache whole pages that are the same for all users. If personalization is required, cache the shell and fill user-specific fragments with AJAX or ESI-style includes. Even a short TTL (30–120 seconds) wipes out most origin hits during spikes.

Serve from closer locations

Use a CDN with a footprint near your users. Anycast routing and well-placed points of presence reduce latency and smooth load. If your audience is local or regional, pick a provider strong in those metros.

Tune TLS

Enable modern protocols and features:

TLS 1.3 with session resumption or 0-RTT when safe
HTTP/2 or HTTP/3 to reuse connections and multiplex requests
OCSP stapling to avoid certificate status lookups on the client side

These shave hundreds of milliseconds on first connections, especially on mobile.

Reduce origin work per request

Profile your page render path. Remove redundant queries, cache computed fragments, and move heavy tasks off the request thread. If a page must call an upstream API, cache the API result for an appropriate window and add a timeout plus graceful fallback.

Keep the database honest

Add missing indexes for common filters and joins. Replace N+1 loops with eager queries. Cap slow query logs at strict thresholds so noisy queries surface daily, not quarterly.

Close noisy plugins and modules

Plugins that run early (before content output) inflate TTFB. On CMS platforms, audit what loads at bootstrap. Disable non-essential components and move analytics to the client side when acceptable.

Warm critical routes

Pre-fetch or pre-warm your most-visited pages at the edge after deploys. Warmed caches make first visitors happy and reduce origin thrash.

A Step-by-Step TTFB Improvement Plan

Use this as your repeatable playbook.

Step 1: Establish a clean baseline

Measure TTFB for top templates: home, category, post, search, cart, and account pages. Collect by region and on both cold and warm cache. Record DNS, connect, TLS, TTFB, and total time.

Step 2: Separate network from compute

Run curl with --resolve to force DNS and test different edges. If TTFB remains slow with a direct origin test on the same network, the application is at fault; if origin is quick but public TTFB is slow, edge or routing is off.

Step 3: Add or tighten edge caching

Cache public HTML with sensible TTLs. Use cache keys that reflect only what changes the markup (for example, language, device class). Don’t vary on unnecessary headers.

Step 4: Optimize TLS and connection reuse

Enable HTTP/2 or HTTP/3, keep-alive, and session resumption. Confirm these are actually negotiated by testing from the command line and the browser.

Step 5: Profile the render path

Instrument server-side timing: template render time, DB query counts, external API time, and cache hit ratios. Use a lightweight APM or framework timers. Delete work you don’t need before you try to speed it up.

Step 6: Fix the database hot spots

Add indexes, rewrite queries, and break long transactions. If writes block reads, consider read replicas for heavy pages that don’t require strict immediacy.

Step 7: Cache fragments and API responses

Choose lifetimes that match business reality. Many “live” components can be cached for 30–120 seconds with no user downside. Staleness budgets buy you performance and resilience.

Step 8: Right-size compute and concurrency

If you’re CPU bound during peaks, scale up or out. Tune PHP-FPM, Node, or your runtime pool sizes to match CPU cores. Avoid over-provisioning workers that thrash the database.

Step 9: Add rate limits and queues for hot endpoints

Search, login, and report builders can throttle under load. Token buckets and short queues prevent the entire app from stalling.

Step 10: Re-measure and lock wins

Re-run your baseline. If a change helps, document it and add a guardrail (test, alert, or dashboard) so regression is unlikely.

Platform-Specific Pointers

WordPress

Use full-page caching at the edge. If that’s not possible, use a proven cache plugin with careful purging.
Limit autoloaded options in the database. Large autoload payloads inflate every request.
Audit the “must use” folder and early hooks. Remove anything heavy that runs before output.
For WooCommerce, bypass full-page cache only where necessary (cart, checkout, account). Everything else should cache.

PHP in general

Tune OPcache to avoid cold compiles.
Use PHP-FPM with process limits that fit memory and CPU.
Profile with a sampling profiler during peak hours to spot code paths that dominate.

Node/JavaScript back ends

Avoid synchronous work in request handlers.
Pool database connections and reuse them.
Cache SSR results when content doesn’t change per user.
Use a worker queue for CPU-heavy transforms.

Ruby, Python, and others

Keep application servers stateless and small.
Push background jobs to a queue.
Cache ORM results and precompute hot views.

DNS and Routing Optimizations

TTFB suffers when requests wander.

Use authoritative DNS with strong global presence.
Turn on DNSSEC only after you confirm resolver performance stays healthy.
Keep TTLs balanced: low enough for controlled changes, high enough to reduce cache misses at resolvers.
For multi-region origins, use anycast or smart load balancing so users hit the nearest healthy region.

TLS and Protocol Best Practices

First contact should be quick.

Prefer TLS 1.3 with session tickets and resumption.
Enable OCSP stapling and a modern certificate chain.
Support HTTP/2; adopt HTTP/3 where your audience benefits.
Avoid weak ciphers that force negotiation retries.

Caching Strategies That Don’t Break Personalization

You can cache and still respect user context.

Cache key discipline: include only headers or cookies that change markup.
Hole-punching: cache the page shell and render small user widgets client-side or via fast edge functions.
Stale-while-revalidate: serve a slightly stale response immediately while you refresh in the background.
Canary purges: avoid purging the entire cache when a single article changes; purge precise keys.

Database Health Checklist

Long-running queries under a strict threshold, logged and reviewed weekly
Proper indexes on foreign keys and frequent filters
Query plan checks after schema changes
Read replicas for heavy list pages and reports
Connection pools sized to avoid thundering herds

TTFB rises quickly when a database waits on locks or scans large tables.

Third-Party Dependencies: Don’t Let Them Own Your TTFB

Server-side requests to payment, search, or inventory APIs can stall your first byte.

Timeouts: set practical, short timeouts with fallback behavior
Caching: cache stable responses for a short window
Bulk fetch: batch where possible instead of many small calls
Circuit breakers: disable non-critical features when an upstream degrades

Design pages to degrade gracefully; never pin TTFB on a fragile dependency if the content can load without it.

Capacity, Queueing, and Noisy Neighbors

If you’re on shared infrastructure, TTFB can spike when neighbors get busy. Signs include:

Sudden global TTFB climbs with no code changes
High iowait or CPU steal metrics
Support tickets from your host about resource limits

Mitigations include moving to a plan with dedicated resources, using a managed platform with autoscaling, or deploying read-heavy pages to the edge.

Monitoring and Alerting That Keeps You Honest

Set alert thresholds for:

TTFB by template and region
Handshake timings (DNS, connect, TLS)
Cache hit ratio for HTML and APIs
Error rates and queue depth at the origin
Database slow query counts

Keep dashboards simple and visible. If you don’t look at them weekly, you’ll find out about regressions from customers, not your graphs.

Common Pitfalls to Avoid

Purging the cache on every publish. Purge precisely; let edge caches do their job.
Blocking edge caching with needless cookies. Don’t set cookies on pages that don’t need them.
Serving massive HTML. A 500 KB document is slow to generate and slow to send.
Leaving keep-alive off. New connections for every request waste time.
Chasing front-end micro-optimizations while TTFB is 1.5 seconds. Fix the biggest blocker first.
Ignoring mobile networks. High RTT exaggerates handshake costs; test on throttled profiles.

A 90-Minute TTFB Sprint (Copy This)

Baseline top 6 pages with curl and synthetic checks
Enable or tighten HTML caching on the edge
Turn on HTTP/2 or HTTP/3 and confirm TLS 1.3
Profile a slow template; remove one expensive query or API call
Add a 60-second cache to that query or API response
Re-measure; if TTFB drops, ship and document

Repeat weekly. Small, consistent wins compound.

Final Takeaway

TTFB is the earliest, clearest signal of a healthy site. Improve it by shortening the distance to users, reducing handshake costs, and cutting server work before the first byte leaves your origin. Cache what you can, compute only what you must, and measure the whole path from DNS to database. When you follow a simple, repeatable plan—edge cache, modern protocols, lean queries, short-lived API caches—you turn a slow first byte into a fast first impression that lifts everything that follows.

Frequently Asked Questions

Does TTFB include DNS and TLS time

Yes. TTFB starts after the request is sent and includes connection and encryption setup plus server processing until the first byte returns.

Is a CDN always required to fix TTFB

Not always, but a CDN usually helps by moving content closer to users and absorbing traffic spikes. For regional or low-traffic sites with a strong host, origin tuning alone can be enough.

Can aggressive caching break dynamic features

It can if you cache the wrong thing. Cache public pages and fragments, not user-specific data. Use careful cache keys, short TTLs, and bypass rules for carts, checkouts, and dashboards.

Why is TTFB worse on mobile

Mobile networks add latency and variability. Handshakes take longer and packet loss is higher. Protocol improvements (HTTP/3, TLS 1.3) and nearby edge locations reduce the penalty.

Should I upgrade servers before optimizing code

Start with measurement. If you’re CPU bound during normal traffic or see queueing, scale is reasonable. Often, simple query fixes and caching reduce load enough to delay hardware upgrades.

How often should I re-measure

Track TTFB continuously with synthetic checks per region and review weekly. Add alerts for significant deviations so you catch regressions soon after deploys.

References

HTTP/2 and HTTP/3 protocol overviews and best practices
TLS 1.3 handshakes and session resumption explained
Resource Timing API and measurement guidance for web performance
General caching strategies and stale-while-revalidate patterns
Database indexing and query optimization primers
Browser developer tools documentation on network waterfalls