Website Speed: TTFB Optimization in Practice

TTFB (Time To First Byte) is the wait before the user gets the first byte — it determines the starting point of all subsequent speed. When TTFB is high, no amount of frontend optimization can save your first screen. It’s the root you should treat first among all speed problems.

Speed is one of the main threads of technical SEO — the systematic treatment is in the technical SEO handbook‘s speed chapter. This article focuses specifically on how to bring TTFB down.

Here’s the bottom line: TTFB is the starting point of speed; when it’s high, the first screen is bound to be slow. First locate whether the bottleneck is in DNS, connection, or origin server processing. Page caching on the origin and optimizing slow queries are the main battlefield. CDN with nearby edge nodes significantly shortens physical distance.

What TTFB is and why it matters

From the browser sending the request to receiving the first byte from the server — that’s TTFB. It covers DNS resolution, connection establishment, server processing, and generating the response. Frontend optimization only affects the rendering “after the first byte arrives,” while TTFB is the “wait” before that. No great frontend can make up for delay at the start, so it’s the true foundation of speed.

For SEO, TTFB directly affects LCP and overall experience, and it’s a mirror of server health. When it’s high, it usually means the origin is busy, logic is heavy, or the path is far. If these aren’t solved, compressing images later is twice the work for half the result. Treating TTFB as the #1 metric is the highest-ROI mindset in speed work — with the direction right, your effort isn’t wasted.

First locate which layer the bottleneck is in

High TTFB needs cause attribution: is it slow DNS, slow TCP handshake, or slow server processing? Use a waterfall view to see each stage’s timing — if the connection stage is long, the problem is network/infrastructure; if the waiting (server) stage is long, the problem is origin logic. Different causes need completely different solutions; blindly touching the frontend is useless. Test first, then treat.

A common misjudgment is blaming everything on “not having CDN.” If the bottleneck is origin processing (long waiting stage), CDN can only cache results — for uncached requests it still has to go back to origin, so it doesn’t help. Locate clearly, and you’ll know whether to invest in cache, database, or network. Diagnosis first is the premise for TTFB optimization not going off track, echoing the “find the main cause first” of crawl budget optimization.

Origin optimization: caching and queries

For dynamic sites (like WordPress), the most immediately effective thing is page caching: turning “query the database and assemble the page on every request” into “generate once, store static, return directly afterward” brings TTFB from a few hundred milliseconds down to tens. Combined with object caching (caching database query results into memory), repeated requests barely touch the database, and origin pressure drops sharply.

Then investigate slow queries: missing indexes, complex joins, and N+1 queries all drag down response. Use database analysis tools to find the slowest few, add indexes or rewrite them — often a single point cuts most of the waiting. Origin optimization is the main battlefield of TTFB; done well, CDN is just icing on the cake; done poorly, CDN can’t save slow origin-return. The order can’t be reversed.

Use CDN to shorten physical distance

CDN puts content on edge nodes close to users, shortening both the DNS and connection stages; cached content returns directly from the edge, and TTFB drops significantly. For sites with many global or cross-region users, CDN is the most effective way to shorten physical distance — turning “fetch from the other side of the earth” into “fetch from next door” wins at the starting line.

But note: CDN still has to go back to origin for “cache-miss” requests. If the origin is slow, that portion of TTFB is unaffected. So CDN and origin optimization are complementary, not substitutes — make the origin fast first, then CDN pushes the fast result to users’ doorstep. Stack both, and TTFB truly compresses to a healthy line. Relying on only one side hits a ceiling; the combination is the complete solution.

Server configuration and runtime

The runtime environment itself has room to squeeze: enabling persistent connections (HTTP reuse), turning on Gzip/Brotli response compression, and using new protocols (HTTP/2, HTTP/3) to reduce handshake overhead all lower TTFB. For runtimes like PHP, raising OPcache and avoiding recompilation every time also cuts considerable waiting. Most of these are configured at the host level, some at zero cost.

Also watch resource usage: shared-host neighbors stealing resources, insufficient process counts, and memory swapping all slow responses. Upgrading plans or limiting concurrency, and making heavy tasks async, can stabilize TTFB at the runtime level. The server is the engine of speed — tune the engine, and the network and cache ahead of it can perform. Looking at the whole chain together is what works.

Monitoring and red lines

TTFB isn’t something you tune once and forget. Content growth, traffic fluctuations, and new plugins all make it climb back. Set a red line (alert when exceeding a certain number of milliseconds), use real user data to see TTFB distribution by region, and focus on P75 rather than the average. Monitoring surfaces degradation before it affects rankings, instead of investigating only after users complain about slowness.

It’s recommended to include TTFB in the monthly technical checkup, on the same screen as LCP and INP. As the starting-point metric, any rise drags down everything after it, so it deserves the most protective attention. Treating “compress TTFB” as an ongoing state rather than a one-off project gives the site long-term speed assurance, and saves you from repeatedly firefighting ranking declines later.

Trade-offs in real scenarios

TTFB optimization doesn’t require doing every item fully. For small sites with mostly local users, grab the two zero-cost big items first — origin caching and slow queries — which is often enough; CDN can wait. For global sites, CDN is a must. Prioritize by user distribution and budget, spend effort on the longest bottleneck link — it works faster than spreading effort evenly, and avoids doing it just for the sake of doing it.

Another trade-off is cache granularity: full-page caching is the most aggressive but dynamic content is hard to update in real time, needing a cache purge strategy. For frequently changing pages, fragment caching or object caching is the compromise. The essence of the trade-off is balancing speed vs. freshness. There’s no universal config, only config that fits your business. Testing and adjusting as you go is more stable than locking it in once, and matches real ops rhythm.

Don’t overlook connection reuse

A detail often forgotten is connection reuse: enabling HTTP persistent connections and HTTP/2 multiplexing avoids re-handshaking on every request, helping TTFB especially in high-concurrency, small-request scenarios. Like compression and new protocols, it’s a free or low-cost server-side optimization — configure once, benefit long-term. It deserves a spot on your tuning checklist; don’t only stare at the application layer.

Before you start, run through this round’s checklist: use waterfall to locate which layer the TTFB bottleneck is in; enable page caching and object caching; analyze and optimize the slowest database queries; use CDN to shorten physical distance beyond uncached requests; turn on new protocols and compression, and set a TTFB alert red line.