FAQ Speed & Performance

What is TTFB and why does mine look high?

What the wait before the first byte actually measures, and the short list of things that usually cause it.

Updated 5 min read Beginner

TTFB, Time to First Byte, is the delay between a browser sending a request and receiving the very first byte of the response back. It covers DNS lookup, connecting to the server, and everything the server does to generate the response — but not downloading the rest of the page or rendering any of it. It is a measurement of one specific thing: how long it takes the server side of the equation to start answering.

What a high figure usually means

A handful of causes explain almost every high TTFB reading:

  • The page is not cached. If a page is rebuilt from scratch on every visit — running database queries, executing template logic — that work happens again for every single request instead of being served from a ready-made copy. Caching a site that changes constantly covers how to avoid this without serving stale content.
  • A slow database query. One inefficient query on a busy page can dominate the entire response on its own, especially as a database grows. Finding the query slowing your site down is the direct next step.
  • Too much running on every request. Plugins or middleware executing regardless of what a specific page actually needs add up, particularly where several perform overlapping work.
  • Genuine load on the account. Sustained heavy resource use affects response time across the board, not just on the busiest pages.

Rule out the page before blaming the server

Test a simple, mostly static page on the same site alongside the complex one that prompted the concern. If the simple page responds quickly and only the complex one is slow, the cause is specific to that page — most likely a query or process it runs that a simpler page does not. If both are slow, the cause sits further upstream, and it is reasonable to look at hosting itself. Does hosting actually affect site speed covers how to make that distinction properly.

Google publishes a rough guide for what counts as good

Google's web.dev documentation suggests keeping TTFB under roughly 0.8 seconds as a reasonable "good" target, with higher figures falling into "needs improvement" and "poor" bands. It is a useful reference point rather than a strict pass or fail line — what matters more in practice is whether your own TTFB is consistent across similar pages or spikes unpredictably on specific ones.

What does not affect TTFB

Image size, the amount of CSS or JavaScript on the page, and how many separate files it loads all happen after the first byte has already arrived — none of them are part of this measurement. A page can have a poor TTFB and be otherwise lightweight, or an excellent TTFB and still be slow to fully load because of everything that follows. Do not diagnose an image or script problem based on a TTFB reading; they are unrelated numbers describing different parts of the same page load.

Practical next steps

If TTFB is high on an uncached dynamic page, page or object caching is usually the highest-value fix available, because it removes the need to regenerate the page at all for most visits. If it is high even on simple, cached pages, that points toward the server itself, and how to diagnose a slow first byte goes through the fuller troubleshooting process step by step.

Related reading