How to reduce server response time — TTFB: Decompose It Before You Try to Cut It

An afternoon, worked in order, with a measurement after each change. The order matters more than the individual techniques: cache first, runtime second, queries third, external calls fourth.

PHP version switching per site, OPcache, Redis object caching and NVMe-backed MySQL are all available here, and PHP X-Ray on CloudLinux Pro on the Nitro tier will name the slow function rather than leaving you to bisect.

When the LiteSpeed page cache answers a request, neither PHP nor MySQL is involved: the response comes out of the server's own store. No other single change reliably takes a response from hundreds of milliseconds into double digits, which is why cache verification comes before tuning. Confirm it with curl -sI and look for x-litespeed-cache: hit on a repeat request.

Then size the remaining problem by comparing cached and uncached. TTFB logged out is a cache hit; TTFB logged in is your application running in full. If the logged-out number is already fine, your work is entirely on the uncacheable path, and that is a much narrower problem than it felt like an hour ago.

First, the unindexed query. A plugin that stores its own data in its own table and queries it without an index will scan the lot on every page load, and the cost grows with your content. Query Monitor in the browser or PHP X-Ray at server level will name it; adding the index, or removing the plugin, is usually a small change with a large number attached.

Second, the blocking external call. A synchronous request to a payment, feed, licensing or social endpoint during page render holds your entire response hostage to somebody else's latency, and when their service has a bad afternoon so do you. Cache the payload with a sensible lifetime, or move the fetch to a cron job and read the stored result during render. Either way, it leaves the request path.