How to diagnose a slow first byte

Time to first byte, TTFB, measures the gap between a browser requesting a page and the first byte of the response arriving back. It happens entirely before rendering starts — before a single image loads, before any CSS is applied, before JavaScript runs. A slow TTFB means the server itself is taking a long time to think, not that anything downstream is inefficient. That distinction matters, because it rules out an entire category of front-end fixes that won't touch this problem at all.

Measuring it properly

Open browser developer tools, go to the Network tab, reload the page, and click the very first request — the HTML document itself, not an image or script further down the list. The timing breakdown shows a "Waiting for server response" (or "TTFB") figure separately from the time spent downloading content afterwards. As a rough guide, under 200ms is good, 200–500ms is acceptable, and anything consistently above 600–800ms is worth investigating.

What actually happens in that gap

Before the first byte can be sent, the server typically has to: receive the request, run your application's code, query a database one or more times, assemble the resulting page, and hand it back. A slow TTFB means one or more of those steps is taking longer than it should — and finding out which one is the entire job.

The usual causes, in order

1. No page caching

If every request rebuilds the page from scratch — running the full application, querying the database, assembling the HTML — every single time, that entire process happens on every single visit. A page caching layer serves a pre-built copy of the page instead, skipping nearly all of that work for most requests. This is, by a wide margin, the single biggest lever for TTFB on a CMS-driven site. See our guide on what page caching actually does for how it fits together.

2. Slow or excessive database queries

A page that runs dozens of queries, or a handful of genuinely slow ones, spends most of its time waiting on the database rather than doing anything else. This tends to get worse gradually as a site's content grows, since many queries scale with the amount of data they search through. Our guide on optimising the WordPress database covers cleaning up the most common causes of this on WordPress specifically.

3. A slow plugin or piece of middleware

A single badly written plugin — one making an external API call on every page load, or running an expensive calculation that was never cached — can dominate the total response time on its own, even on an otherwise fast, well-configured site. If TTFB got noticeably worse after installing something specific, that's the first place to look. Our guide on finding a slow WordPress plugin walks through isolating exactly which one it is.

4. Insufficient PHP resources for the load

If a server or plan doesn't have enough PHP worker processes to handle concurrent requests, additional visitors queue up waiting for a process to become free rather than being served immediately — which shows up as TTFB that's fine when traffic is low and steadily worsens as it grows. This is a capacity question rather than a code question, and is worth raising with support directly if it correlates clearly with traffic level.

5. No opcode caching

PHP has to compile its code before running it. An opcode cache stores that compiled form so it doesn't need recompiling on every single request. Most modern hosting enables this by default, but it's worth confirming in your PHP configuration if TTFB seems unexpectedly high on a site with otherwise reasonable code and caching in place.

6. An external service the page waits on

A page that calls out to a third-party API, an ad network, or an external analytics or personalisation service before it can finish rendering the response is only ever as fast as that external service. Check whether any such calls happen synchronously — that is, blocking the response — rather than being deferred until after the page has already been sent.

Narrowing it down systematically

1. Test a genuinely static file first

   Load a plain image or a static HTML file on the same domain and check its TTFB. If that's fast while the main page is slow, the delay is in your application's processing, not the server or network generally.

2. Check whether page caching is active

   Confirm a caching plugin or your control panel's caching feature is switched on and actually caching the specific page you're testing — some pages, like a cart or account page, are deliberately excluded from caching.

3. Deactivate plugins one at a time

   Retest TTFB after each deactivation. A significant drop points straight at the plugin you just removed.

4. Review the database query count and timing

   Many performance and debugging plugins can display the number of queries a page runs and how long they took, which is usually enough to spot an obvious outlier.

If nothing you try moves the number

Send support the specific URL, the TTFB figure from your Network tab, and roughly when it started being slow if it wasn't always this way. That's usually enough for us to check server-side resource usage and confirm whether the account's plan is sized appropriately for the load it's under, alongside anything you've already ruled out yourself.