TTFB Won't Go Down? Server-Side Culprits Beyond the Theme

You put the site behind a CDN, trimmed the theme, deferred scripts, and still watch Waiting (TTFB) eat the PageSpeed Insights waterfall. The next ticket proposes a bigger hosting plan. In our experience that upgrade often treats the symptom while the origin keeps doing too much work per uncached request, or background jobs steal capacity when real visitors arrive.

When DNS and TLS are already short, high Time to First Byte is almost always origin processing: PHP execution, database queries, remote calls inside the page build, or contention from other jobs on the same machine. A page cache can hide this until a logged-in session, cart cookie, or query-string variant bypasses the edge. Lab tests then look slow while marketing reports that the CDN is on.

Server-side checklist we walk before the next hosting invoice:

• Disable request-driven WP-Cron; trigger due events from system cron on a fixed interval, then compare TTFB at :05 and :55 past the hour

• Confirm OPcache, sensible PHP worker counts, and warm critical URLs after deploy so cold workers are not the whole story

• Add Redis or Memcached object cache; audit fat wp_options autoload rows and N+1 queries on the uncached path

• Watch admin-ajax volume in access logs; move backup and scanner plugins off peak in the site traffic timezone

• Re-test the same priority URL on an uncached miss, not only the cached marketing homepage

TTFB is not a Core Web Vital, but it still gates LCP because the main content cannot paint until HTML arrives. Fix origin compute on the miss path before doubling RAM.

Read more: reduce TTFB when CDN and theme fixes fail