Speed tests report a number called time to first byte, or TTFB. It is the delay between the browser sending a request and receiving the first piece of the answer. People treat it as a measure of server speed, and partly it is, but it contains more than that. Several separate things are added together inside it, and only some of them are your host's doing.
That matters because the advice for a high number depends entirely on which part is high. A site owner who sees a red mark next to TTFB and responds by upgrading the hosting plan will sometimes get a better result, and sometimes spend money to fix the wrong problem. A few minutes with a command line tool usually shows which it is.
This piece breaks the number into its parts, explains what counts as good, and gives a method for finding where the time goes on a typical PHP site.
What is inside the number
When a test tool says the TTFB was 640 ms, it is measuring from the moment it started the request to the moment the first byte of the response arrived. Depending on the tool and on whether the connection was already open, that stretch can include any or all of the following.
- The DNS lookup, if the name was not cached.
- The network round trip to reach your server, including the TCP handshake.
- The TLS setup, if the connection is new. With TLS 1.3 that is one more round trip.
- The time the server takes to produce the response: the web server receives the request, hands it to PHP, PHP loads the site's code, the database answers a series of queries, and the page is assembled.
- The first slice of the reply travelling back.
Only the fourth item is "how fast is the server". The others are mostly geography and connection setup. If you test from the other side of the world, distance alone adds a few hundred milliseconds that no server tuning can remove. Light in fibre covers roughly 200 kilometres per millisecond, so a round trip from Sofia to Sydney cannot come in under about 150 ms, and real routes are longer than the straight line. A new connection pays for that two or three times before any content arrives.
What counts as good
Google's web performance guidance treats under about 800 milliseconds as good, with anything above 1.8 seconds as poor, measured for real visitors at the 75th percentile. That is a generous threshold because it includes the whole journey. A cached page on a decent host often answers in under 200 ms when you test from nearby. If an uncached page takes more than a second even from a nearby location, the server is doing too much work per request.
TTFB is also a means to an end. Visitors do not see it. They see the page appear, and the numbers that track that, such as largest contentful paint, include TTFB as the first part of their budget. A slow first byte leaves less time for everything else to hit its target, which is why people care. A quick TTFB attached to a page full of heavy images still feels slow, so treat it as one part of the picture. The page weight calculator helps with the other part.
How to narrow down the cause
Test from a location near your server. If the number is still high, the work is slow. If it drops sharply, the earlier figure was mostly distance and connection setup, and the fix is a content delivery network or a server closer to your visitors, not a bigger plan.
Then compare a cached page with an uncached one. A cached page is one the server can send without running PHP, such as a static file or a page served by a page cache. An uncached one is a search results page, a logged-in view, or a URL with a random query string such as /?x=12345. If only the uncached version is slow, you need page caching, or you need to look at what PHP and the database are doing. If both are slow, check for resource limits, a slow storage disk, or a crowded server.
Measuring it with curl
A browser's developer tools show the figure, but curl lets you split it into stages and repeat the test from a server in another location. This prints the main timings, all in seconds:
curl -so /dev/null -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nfirst byte %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/The output looks something like this, with illustrative numbers:
dns 0.012
connect 0.041
tls 0.093
first byte 0.488
total 0.511Here the connection and TLS were finished at 93 ms. The first byte arrived at 488 ms, so the server spent roughly 395 ms producing the page. That is the part to investigate. If the same test on a cached URL returns the first byte at 130 ms, you have found a page caching gap. The status code reference and curl -I will also show whether a cache is in play: look for headers such as cache-control, age or a vendor-specific cache status.
What makes the server part slow
On a typical PHP and database site, the time goes to a short list of causes. These are the ones that turn up most often.
| Cause | What you see | What helps |
|---|---|---|
| No page cache | Every visit runs PHP and the database, even for anonymous readers | A page cache plugin or the host's built-in cache |
| Too many plugins doing work on every request | High time even on a simple page | Disable and measure one at a time |
| Heavy or repeated database queries | Slow on archive, search and shop pages | Object cache, query review, tidy old data |
| Outdated PHP version | Everything slightly slow | Move to a current PHP 8.x release |
| Calls to external services during page build | Occasional huge spikes | Cache the results or load them later |
| Slow storage or crowded server | Slow even for static files | Ask the host, or move to a less crowded plan |
| Process limits reached | Delays under traffic, then 503 or 508 errors | Cache more, or a plan with more workers |
The tell for the last two is that static files, which need no PHP at all, are also slow. If a plain image or stylesheet takes half a second to start, the problem sits below your application.
What changes by hosting type
On shared hosting you cannot change the web server or PHP process settings, but the host usually provides a page cache and a PHP version selector, and those two cover most of the improvement available. On a VPS you control everything, including the PHP worker count and the database settings, and a poorly sized setup can be slow in ways a shared plan would not be. On managed WordPress hosting, caching is typically built in and the dominant factors become your theme and plugins. With a CDN in front, cached pages can come from a location near the visitor, which improves TTFB for people far away but does not help uncached or logged-in requests, since those still travel to your origin.
A worked example
A small bakery has a WordPress site with a shop plugin. The owner runs a speed test from a European location and sees a TTFB of 1.4 seconds on the home page, which the tool marks in red. The server is in the same country. Before touching the plan, she asks her host's support to look, and the engineer runs three requests.
The home page, fetched with the curl command above, gives a first byte at 1.3 seconds. The same page with ?x=1 added gives about the same, so the page cache is either off or being bypassed. A static image from the same site answers in 90 ms, so the server and the network are fine. That narrows it to the application.
The engineer turns on the page cache in the caching plugin, and excludes the cart and checkout pages, which must never be cached. The home page now answers at 160 ms for anonymous visitors. Two further problems remain. The shop's product archive is still slow at 1.1 seconds because it makes a lot of database queries, and a plugin that checks a remote service on every page load adds a random 300 ms. Disabling the second one, and moving the first to an object cache, brings the archive down to about 400 ms.
Nothing here needed a bigger plan. The lesson from the three requests is the pattern to copy: one cached, one uncached, one static file. Between them they tell you whether to look at caching, at the application, or at the server.
A tip for testing
Run each test a few times and look at the middle value. The first request after a quiet period can be slower, because caches are cold: PHP opcode caches have been emptied, database buffers have been pushed out, and a page cache may need to rebuild. That first-hit penalty is real for visitors too, so it is worth knowing how large it is for your site. If the first visit is regularly three times slower than the rest, a warm-up request on a schedule, or a cache that rebuilds in the background, will smooth it out.
Test at different times of day as well. A shared server that is fast at 06:00 can be slow when the neighbours are busy at 20:00, and one reading tells you nothing about the other.