Time to first byte is how long from asking until the first byte of the answer arrives. It contains DNS, the connection, the handshake and the server thinking - and curl prints each part separately, so you can see which.
curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://yourdomain.com/Reading it
- dns large - a slow resolver, or a very low TTL forcing a lookup every time.
- connect large - distance. A server on another continent cannot be fixed with code.
- tls minus connect large - the handshake. An incomplete certificate chain makes the browser fetch the missing part.
- ttfb minus tls large - the server building the page. This is the one you can fix.
What is good
- Under 200ms - the server is not your problem. Look at the browser.
- 200-500ms - normal for an uncached dynamic page.
- Over 800ms - something specific is slow, and it is worth finding rather than caching over.
Measure the same URL several times. The first request after a deploy is slow for reasons that will never affect a visitor - cold caches, opcache empty - and one measurement of that tells you nothing.
Measure from where your visitors are
TTFB from the server itself excludes the network entirely and is always excellent. It is also not what anyone experiences.
If TTFB is fine and the page still feels slow, stop optimising the server. The time is in the browser and no amount of caching will change it.