Measuring TTFB

TTFB, or time to first byte, is how long it takes before your browser receives the first byte of the response. Measuring it the right way means separating a cached LiteSpeed hit from uncached PHP, and separating your origin from a CDN edge. That keeps you from chasing the wrong fix when a page feels slow.

Start with the logged-out homepage against the host users actually hit, then check origin if a CDN sits in front. Next, hit a URL you know is uncached. Then check wp-admin, which stays uncached on purpose. Repeat from a second network so one city’s result does not stand in for the whole internet.

1. curl the homepage while logged out. Note TTFB and the cache header.
2. Bypass cache with a unique query string or a private URL, then measure again.
3. Measure wp-admin. Do not treat that number as the public customer figure.
4. Repeat from another network and ignore a single outlier.

curl -o /dev/null -s -w ‘dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}n’ https://example.com/

In that output, dns is name lookup, tcp is the connection handshake, and tls is certificate setup. The ttfb value is time_starttransfer, which is first byte after those steps. total includes downloading the body. A very low ttfb with a long total usually means a large page body, not a slow origin. A high ttfb on a cache miss often points at PHP and the database. A high ttfb on what should be a cache hit often means the wrong header, a cookie, or you are not hitting the server you think you are.

What a low TTFB does not tell you

A low TTFB only means the first byte arrived quickly. Images, scripts, and CSS still have to load after that. Largest Contentful Paint can still suffer from a huge hero image even when first byte looks fine. wp-admin will almost always look slower than a cached homepage, and that is expected rather than a regression. If you need paint timing, measure LCP on its own. This guide is only about first byte, in a clear order, with the cache header written beside each result.

CDN edges, office Wi-Fi, and wp-admin

If a test from far away shows about 40 ms while curl near the origin shows hundreds of milliseconds on a hit, you are often seeing an edge cache, not LiteSpeed on the origin. That edge number is useful for visitors, but it is not the origin figure you need when PHP is the complaint. Add response headers to the same curl so you can tell whether the HTML came from the CDN vendor or from us.

Office Wi-Fi behind a transparent proxy can inflate TLS time. Phones on cellular can inflate DNS. Write down which of dns, tcp, tls, or ttfb actually moved. A plugin that claims to improve TTFB by injecting preload hints does not change time_starttransfer on the origin. It may help LCP later. That is a different measurement.

A simple order that stays honest

Keep three numbers separate in your notes: cached HTML on LiteSpeed, uncached PHP on origin, and any CDN edge result. On shared hosting here you are on cPanel with LiteSpeed, so a boring low TTFB on a logged-out cache hit is normal. Uncached PHP is the figure that reflects workers and the database. Mixing those three into one screenshot is how people install another cache plugin and make the homepage worse. Measure in order, label the cache header next to each run, and compare regions before you change anything.