TTFB Too Slow: How to Diagnose and Fix It

What this check flags

SEO ProCheck raised this issue because your page's Time to First Byte exceeded 800 milliseconds. That number comes from Google's guidance on web.dev: a TTFB at or below 0.8 seconds is good, anything above 1.8 seconds is poor, and the range in between needs improvement. To be honest about what this metric is: TTFB is not one of the three Core Web Vitals, and Google does not use it directly as a ranking signal. So why flag it? Because TTFB is the floor under Largest Contentful Paint, which absolutely is a Core Web Vital. The browser cannot paint anything until the first byte of HTML arrives. If your server takes 1.5 seconds to respond, your LCP starts its race 1.5 seconds behind the line, and no amount of front-end optimization can claw that back.

What is inside TTFB

TTFB bundles every step between the user pressing enter and the first response byte arriving:

DNS lookup. Resolving your domain to an IP address. Usually fast, but a slow DNS provider adds real latency. Connection and TLS handshake. Setting up TCP and negotiating encryption takes multiple round trips, and each one costs more the farther the user is from your server. Redirects. Every redirect restarts the whole sequence. A hop from HTTP to HTTPS to the www version can quietly triple your effective TTFB, and field data captures this even when lab tools measuring the final URL do not. Server processing. The time your application spends building the response: booting PHP, running database queries, rendering templates. On most dynamic sites this is the largest and most fixable slice.

The usual suspects

A TTFB over the threshold almost always traces back to one of these:

No full-page cache. The server rebuilds the same page from scratch for every visitor when it could serve a stored HTML file in milliseconds. Slow database queries. Unindexed lookups, bloated options tables, or plugins firing dozens of queries per request. Cheap shared hosting. Your site competes with hundreds of neighbors for CPU and disk, so response times swing wildly under load. A far-away origin. If your server sits on one continent and your audience on another, physics alone burns hundreds of milliseconds in round trips. Redirect chains. Old URL structures and stacked plugin redirects nobody has audited in years.

Quick wins in priority order

1. Turn on full-page caching

The single biggest lever for most dynamic sites. Serving a cached HTML response skips the application entirely. On WordPress that means a server-level cache such as LiteSpeed Cache or a well-configured caching plugin. Verify it works by checking for a cache hit header on repeat requests.

2. Put a CDN in front

A CDN terminates TLS close to the user and, if you cache HTML at the edge, serves the whole document from a nearby node. This attacks the connection and distance components that origin tuning cannot touch.

3. Kill redirect hops

Collapse chains so any old URL reaches the final destination in one 301. Make sure internal links point directly at canonical URLs so most visits involve zero redirects.

4. Upgrade your runtime

Newer PHP versions execute the same code substantially faster, so upgrading an outdated runtime is nearly free performance. The same logic applies to Node, Python, or any other backend.

5. Add an object cache

For pages that cannot be fully cached, such as logged-in or personalized views, an object cache like Redis stores query results in memory so repeated lookups skip the database.

How to diagnose it

Start with curl, which breaks the request into its component timings and shows you exactly where the milliseconds go:

curl -o /dev/null -s -w "DNS:        %{time_namelookup}s
Connect:    %{time_connect}s
TLS:        %{time_appconnect}s
TTFB:       %{time_starttransfer}s
Total:      %{time_total}s
Redirects:  %{num_redirects}
" -L https://example.com/

If TTFB is high but DNS, connect, and TLS are fast, the problem is server processing. If the early phases are slow, look at DNS, distance, and your TLS setup. Cross-check with PageSpeed Insights, which reports real-user TTFB from the field. Then dig into your server logs: slow query logs and access logs with response-time fields show which requests are dragging. Our log file analysis guide covers how to mine those logs, including spotting bot traffic that hammers uncached URLs and inflates server load.

Common mistakes

The classic error is buying a CDN to fix a slow application server. If your origin takes 1.4 seconds to build a page and the HTML is not cacheable at the edge, the CDN faithfully delivers that slow response from a closer location, leaving the real problem untouched. Diagnose first, then spend. Other frequent missteps: testing only from your own city while overseas users suffer, caching pages without excluding carts and login flows, and measuring the final URL while real users enter through a redirect chain you never see in lab tools.

FAQ