Troubleshooting guide · performance · Published 2026-08-15 · 4 min read
Reducing Time To First Byte
Reduce slow Time To First Byte: isolate it with curl, then fix server response time, database queries, caching, and CDN behaviour in order.
- ·Measure first
- ·Find the leg
- ·Fix by cause
Symptoms
The page feels slow to start: the browser stalls on a blank tab before any content appears, and the network tab shows a long wait labeled TTFB. The metric itself measures the time from the request to the first byte that comes back, which covers DNS, connection, and the origin's processing before the first response byte. TTFB is not a Core Web Vitals metric on its own, but it sits inside LCP: a slow first byte pushes the whole timeline out.
Measure first with curl
Never guess before measuring. A single request isolates the server leg from the page's downloads and rendering:
curl -o /dev/null -w "TTFB: %{time_starttransfer}ms Total: %{time_total}ms\n" https://example.com/Run from a machine outside your network, and compare variants:
| Variant | What it isolates |
|---|---|
example.com with cache | The cached fast path |
example.com/?nocache=1 or a key URL | The uncached path |
https://origin.example.com | Skips the CDN entirely |
| Same URL from 2 networks | Edge vs origin issue |
If the CDN variant is fast but the origin is slow, the CDN is fine. If a cached path is fast and the uncached one is slow, the server is doing expensive work per request.
Find the slow lead
Split the answer into these parts:
- DNS and connection: low, usually single digits for a well-configured site.
- Wait on the pool: PHP-FPM or Node keeps the request queued because workers are busy.
- Application time: the request runs the whole stack of bootstrapping, database, template, and cache before writing.
- External time: the origin reaches out to remote services, a payment gateway, an API, or a slow database network.
If the breakdown of a 4-second TTFB is 3.8 seconds of app time, no amount of CDN tuning helps. If it is 3 seconds of queued wait, the CDN is fine but the origin is saturated.
Fix by cause
1. Reduce server response time
Static files and cached pages are almost free. Turn on page cache at your host, plugin, or reverse proxy. For WordPress, the fastest win is a full-page cache that answers uncached outside the PHP bootstrap, described in the WordPress performance route.
2. Slow database queries
Look for the query logger. Typical causes: missing indexes on joins, a LIKE '%...%' scan on a big table, or unbounded SELECT *. Add the index, or cache the expensive result with a small TTL. An autoloaded WordPress object that loads on every request is also a per-request cost.
3. Hosting hot-path
If TTFB stays slow at low traffic, the plan itself is the bottleneck: shared hosting with oversubscribed neighbours, an old PHP version, or a server in a distant region. A geographic test is the quick tell; curl the same URL from the visitor region.
4. Cache headers and the CDN
Even an uncached page only needs a CDN edge for its static assets. Correct HTTP caching for images, CSS, and JS is covered in the HTTP caching guide. For the CDN edge, cache the page itself only when it has no cookies, and express the policy with Cache-Control: no-cache on dynamic HTML and max-age on static assets.
When it stays slow
A permanent wall at the same number for every request points away from caching and toward the stack: an overview now and a profiling run on the origin. If the origin is a managed service, check its status and support queue before dropping new config in. The stable low TTFB end of the project is usually one line in the audit: the first byte arrives in single digits for everything the CDN can cache and double digits for real user pages.