WordPress TTFB: What good looks like in 2026 (and how to get there)

Time to First Byte (TTFB) is the boring metric that ends up mattering more than any other. It does not show up on a marketing slide, it does not have a satisfying chart, and yet every other performance number — Largest Contentful Paint, Speed Index, Total Blocking Time — sits on top of it like a building on a foundation. If TTFB is bad, everything is bad.

This is the field guide we hand to teams who run BoltAudit and see "TTFB" flagged as the primary bottleneck. It covers what the number actually measures, what good looks like in 2026, and the four-step diagnostic walk we use to take a site from a 1.2-second TTFB to under 200 milliseconds — without changing hosts.

What TTFB actually measures

TTFB is the time between the browser issuing a request and the first byte of the response coming back. That window contains:

• DNS resolution (~10–80ms typical)
• TCP handshake (~one round-trip)
• TLS handshake (~one to two round-trips)
• The HTTP request travelling to the origin
• The origin doing whatever PHP / database / cache work the page requires
• The first byte travelling back

For an uncached WordPress page, the largest slice is almost always the server-side work: PHP execution, database queries, plugin hooks running on init and wp, and any external API calls the theme or plugins make synchronously. The network parts add up to a hundred milliseconds at worst on a healthy connection. The PHP/DB part can run for several seconds if a single hook is misbehaving.

What good looks like in 2026

Google's Core Web Vitals do not have a TTFB threshold directly, but TTFB is part of the Largest Contentful Paint budget. To consistently hit "good" LCP (under 2.5s on mobile), you need TTFB under roughly 600ms on the median request. The bands we use in audits:

TTFB band	Median value	What we say
Excellent	under 200ms	The host and stack are doing their job. Do not touch.
Good	200–500ms	Healthy. Optimize when something else is the bottleneck.
Concerning	500–800ms	Something is taking too long. Investigate the backend.
Poor	800ms–1.5s	Almost always a plugin or query problem. Audit the backend.
Critical	over 1.5s	A single hook or query is dominating. Find it today.

The numbers above are for uncached page loads — what a fresh visitor sees, what Googlebot sees on a cold crawl, and what your slow query log records. Cached page loads will be 30–80ms regardless of how broken the underlying code is, which is why "my site is fast" can be true for return visitors and spectacularly false for the bounce-rate visitors that actually decide your conversion rate.

The four-step diagnostic walk

This is the path we walk on every BoltAudit audit when TTFB is the verdict. The order matters — each step rules out a class of cause before we move to the next.

Step 1: Confirm it is TTFB, not something else

Open Chrome DevTools, Network tab, hard-reload your homepage with cache disabled. Click the document request. Under "Timing", you want the Waiting for server response number. That is your TTFB. If that number is small (under 300ms) and the page still feels slow, your bottleneck is not TTFB — stop reading and go look at LCP image loading or render-blocking resources.

If the number is large, run the same test from a server-side curl to remove your local connection from the variables:

curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} ssl:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}
'   https://yoursite.com/

If ttfb from curl is similar to your DevTools number, the slowness is on the server. If curl is fast and DevTools is slow, the slowness is on the network between you and the origin (CDN edge, ISP path, etc.) — that is a different fix.

Step 2: Cached vs uncached

Run the same curl twice in a row. The second request should be much faster than the first. If both are slow, page caching is broken or disabled. If only the first is slow, page caching is working and your real problem is uncached visitors and bots — in which case the question becomes "how slow is the underlying page when the cache is cold."

To force an uncached path, append a random query string:

curl -s -o /dev/null -w '%{time_starttransfer}
'   "https://yoursite.com/?cache_bust=$(date +%s)"

That bypasses both page cache and CDN cache and gives you the honest origin TTFB.

Step 3: Find the heavy hook

If uncached TTFB is over 800ms, a plugin or theme is doing too much synchronous work. Install Query Monitor temporarily and load any uncached page. The "Hooks & Actions" panel groups time by hook. We commonly see:

• init running for 400–800ms because a plugin hits an external API on every page load (license checks, analytics, A/B testing).
• wp and wp_loaded doing redirect lookups against thousands of stale rows in wp_postmeta.
• Theme's after_setup_theme registering hundreds of widgets or sidebars synchronously.

Once you know which hook is heavy, the next question is which plugin owns the slowest callback inside that hook. Query Monitor shows you. From there: deactivate, audit, replace, or move the work to a background job (wp_schedule_event, Action Scheduler, etc.).

Step 4: Find the heavy query

If uncached TTFB is between 500ms and 800ms and no single hook stands out, the cause is usually one or two queries each running 100–200ms. Query Monitor will show you the top-10 slowest queries. Look for:

• SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' taking over 50ms — your autoload table is bloated. We have a whole post on the autoload trap.
• SELECT * FROM wp_postmeta WHERE post_id IN (...) with hundreds of IN values — a plugin is doing N+1 lookups and needs an index hint or a query refactor.
• Any query against wp_options with LIKE '_transient%' — you have orphaned transients filling up the table.

These are fixable in an afternoon, and the TTFB delta after fixing them is usually 200–600ms.

When the host actually is the problem

About one in seven of the audits we run actually traces back to the host — but it is the seventh case, not the first. Symptoms of a host-side TTFB problem:

• Uncached TTFB is consistently 600–900ms with no heavy hook and no heavy query.
• Adding more PHP workers does not help.
• The host's status page shows recent incidents.
• Other sites on the same shared plan are also slow.

If those check out, switching to a host with PHP-FPM tuned for WordPress and SSD-backed object cache will give you a 200–400ms TTFB win for free. But do the four steps above first — switching hosts because of a runaway plugin moves the problem rather than fixing it.

What BoltAudit does

BoltAudit runs the diagnostic walk above in 90 seconds, picks the layer that is actually limiting your TTFB, and tells you the specific hook, query, or host signal that's responsible. Instead of "your TTFB is slow" you get "this hook in this plugin is adding 480ms to every uncached request." That is the difference between a Lighthouse report and a fix.

Run a free audit — no credit card, takes about 90 seconds, gives you the bottleneck verdict and the ranked fix list.