Time to first byte is how long a page takes to start answering
Time to first byte, or TTFB, is the time between a visitor asking for a page and the first byte of the response arriving. It measures the server, not the screen: how fast the site begins to answer, before any text, image or script has loaded. On a WordPress site it is usually the first number worth fixing, because every later step waits for it.
By Rish Sadh, founderUpdated
Definition
Time to first byte is the time from the start of navigation to the arrival of the first byte of the response. It includes any redirects, the DNS lookup, the connection and security setup, and the wait for the server to produce the page. It is not full page load time, and it says nothing about how the page looks once it arrives.
What counts as a good time to first byte?
The published guide from web.dev is 0.8 seconds or less for a good value and anything above 1.8 seconds for a poor one. The same page calls these a rough guide and notes that time to first byte is not one of the Core Web Vitals, so it is a diagnostic rather than a score to chase.
That is why it is worth reading as a cause. A slow first byte pushes everything after it back by the same amount, and no amount of image compression recovers a wait that happened before the first image was requested.
0.8 s
The rough guide for a good time to first byte is 0.8 seconds or less, and values above 1.8 seconds are poor. web.dev calls these a rough guide and notes that time to first byte is not a Core Web Vitals metric.
web.dev, Time to First Byte (TTFB)Why are WordPress sites often slow to the first byte?
WordPress builds a page when it is asked for one. Unless something stops it, every visitor triggers the same database queries and template work, and nothing is sent until that work is done. On a site with a page builder and a shop plugin installed, that wait can run to several seconds before the first byte.
Page caching removes it. The first request builds the page and keeps a ready copy, and later visitors who are not logged in are handed the copy. The wait drops from the time it takes to build the page to the time it takes to read a file. Hosting, redirects, DNS and a distant server all add to the figure as well, which is why the first step is measuring, not guessing.
The first byte is the one number every later number has to wait for.
What does it not tell you?
It does not tell you the page is fast. Fonts, scripts and images still have to arrive and be drawn, and on a typical WordPress site they take longer than the first byte did. Fully loaded pages can still take several seconds after the server has answered in half of one.
It also changes with who is asking. A logged-in user usually bypasses the cache. The first visit after a change rebuilds the page. Pages that cannot be cached, such as login, search, basket and checkout, are always built on request. A figure that does not say which of these it covers is not yet a measurement.
How do you measure it fairly?
Take the median of several runs, as a visitor who is not logged in, from a location near the people you are building for. State where it was measured, because a connection closer to the server flatters the result and one farther away punishes it. Then state what the number is: a first byte, not a page load.
Reidify did exactly that in a one-week pilot on a UK manufacturer's WordPress site. With page caching switched on, the median first byte on six key pages fell from between 2.6 and 4.3 seconds to about half a second, and the full-page load, still several seconds, was recorded as the next stage rather than quietly left out. The case study shows each page with the caveats beside it.
Common questions
What is a good time to first byte?
web.dev gives 0.8 seconds or less as a rough guide to a good value, and anything above 1.8 seconds as poor. Treat both as a guide, not a pass mark: they say how quickly the server answers, not how quickly the page is usable.
Is time to first byte the same as page load time?
No. It stops when the first byte of the response arrives. Everything after that, the fonts, scripts, images and rendering, is still to come, so a page can have an excellent first byte and still take several seconds to load in full.
Why is time to first byte often slow on WordPress?
Because WordPress builds each page on request unless something stops it. Every visitor triggers the same database queries and template work before a single byte goes out. Page caching keeps a ready copy and removes that wait for visitors who are not logged in.
How should I measure it?
Use the median of several runs, not one, as a logged-out visitor, from a location close to where your visitors are. A single run can land on a cold cache, and a measurement from the wrong country can flatter or punish the result.
Websites
The studio's website work, from build to ongoing care.
A UK telematics manufacturer, WordPress care
A measured before and after for first byte, with the caveats shown.
What is a WordPress care plan
Who keeps a WordPress site updated, backed up and fast, and how it is recorded.
Does site speed affect AI visibility
What speed changes for crawlers and answer engines, and what it does not.
Find out what your site's first byte is, and what is holding it back.