TTFB is a hosting performance metric that records the milliseconds between a browser's initial HTTP request and the arrival of the first response byte from the origin server. Time to First Byte covers everything that happens before a single character of the response reaches the browser: DNS resolution, connection setup, and whatever server-side work the request actually requires. For a WordPress site, four layers determine how much of that time is avoidable: PHP-FPM worker capacity, page caching, object caching, and CDN edge caching, and each one intercepts the request at a different point before it becomes the byte a browser measures. None of the four substitutes for another, since each removes a different cost from the path, and the order they intercept a request in also determines which layer is worth diagnosing first.
What TTFB Actually Measures
TTFB measures a narrow but consequential window: everything between the moment a browser sends its request and the moment the first byte of the response arrives, before any part of the page has started to render. The Mozilla Developer Network (MDN) glossary entry for Time to First Byte states that the measurement includes the DNS lookup, the TCP handshake, and, for an HTTPS connection, the TLS handshake, so the network setup cost is baked into the number before the origin server does any work of its own. web.dev sets a rough guideline of 800 milliseconds as reasonable performance for a typical site, and is direct about what happens above that mark: "high TTFB values add time to the metrics that follow it." The most exposed of those is Largest Contentful Paint (LCP): a browser cannot begin painting the page's largest visible element until the HTML describing it has arrived, so a slow TTFB pushes the entire render timeline back by the same margin. First Contentful Paint (FCP) inherits the identical delay for the identical reason, and the same delay compounds directly into a slower Largest Contentful Paint score, since TTFB sits upstream of every Core Web Vitals metric rather than just one. Chrome DevTools shows a rough version of this breakdown in its Network panel, but the more precise diagnostic is the Server-Timing header, a standard response header a backend can use to report which internal phase consumed the time, whether that turns out to be DNS resolution and its contribution to page load latency or something deeper in the chain.
What Happens Before the First Byte Arrives
Time to First Byte is the sum of several discrete stages, and a slow number almost always traces back to one specific link in that chain rather than the entire system running slow. web.dev's guidance on the Server-Timing header names four candidate measurement points that make up a typical backend request: database queries, server-side rendering time, disk seeks, and edge server cache hits or misses. For a typical WordPress request behind PHP-FPM, the sequence runs in order:
- DNS lookup and the TCP and TLS handshakes complete first, a network cost that sits entirely outside the hosting stack's control.
- The web server, whether Nginx, Apache, or LiteSpeed, accepts the connection and hands the request to PHP-FPM.
- A PHP-FPM worker picks up the request and runs the WordPress bootstrap: loading the autoloader, initializing active plugins, and resolving the requested route.
- WordPress executes its WP_Query calls and any further lookups against MySQL or MariaDB, including whatever disk I/O those queries need, to assemble the data the template requires.
- PHP compiles the result into HTML and the server sends the first byte back to the browser, closing the TTFB window.
A Server-Timing header on the response would show exactly which of these five stages is consuming the time, rather than leaving the diagnosis to guesswork. Kinsta and WP Engine both point to stages three and four as the ones a site owner can actually influence, since everything before that is network physics; that is where PHP-FPM worker capacity, and the PHP bytecode OPcache keeps resident in memory, becomes the binding constraint.
PHP Workers: The Concurrency Bottleneck
Running out of PHP workers is a more common cause of a high TTFB number than any single slow database query, because every uncached request on a WordPress site competes for the same fixed pool.
- PHP worker
- A process that handles one uncached PHP request at a time. Per WP Engine's support documentation, each uncached page request to a website is handled by a PHP worker.
- PHP-FPM pool
- The configured set of PHP-FPM worker processes available to a site, sized by the hosting plan rather than by the codebase running on it.
- Worker queue
- The backlog of requests waiting for a free worker once every PHP-FPM worker is already busy.
- Worker backlog
- Per WP Engine, forms when workers cannot finish requests more quickly than new ones arrive, and every request sitting in it adds directly to TTFB.
The constraint is strictly one worker per uncached request, and Kinsta's documentation makes the tradeoff explicit: cached content does not require PHP threads, because they are really only needed once a request has to query the database. Shared hosting typically fixes the PHP worker count at a small, non-negotiable ceiling; a VPS or a managed WordPress hosting plan from Cloudways, WP Engine, or Kinsta allows that ceiling to rise, though more PHP workers always costs more memory. WP-Cron tasks and WooCommerce cart and session processing both consume workers outside normal page views, which is why a WooCommerce store running Nginx on a Gridpane-managed VPS can see TTFB spike during a traffic surge even though the page itself has not changed. Any request that produces a cache miss also joins that same worker queue, competing for a limited pool of PHP-FPM workers.
Page Caching: Bypassing PHP Entirely
Page caching is the single change most likely to move TTFB the furthest, because it removes PHP execution and the database roundtrip from a request entirely. WordPress.org's own caching documentation calls page caching "the fastest way to improve performance," noting that plugins such as W3 Total Cache, WP Super Cache, and Cache Enabler install easily and cache WordPress posts and pages as static HTML files, a change WordPress.org says can improve performance "several hundred times over for fairly static pages."
- W3 Total Cache, WP Super Cache, and Cache Enabler: plugins that generate and serve static HTML in place of a full PHP page render.
- Nginx FastCGI cache and LiteSpeed Cache: server-native full-page cache systems that intercept a request before PHP-FPM is ever invoked.
- WP Engine Evercache and similar proprietary layers such as Varnish: full-page caching built directly into a managed host's stack rather than installed as a plugin.
WordPress.org draws a separate line around browser caching, noting it can "help to reduce server load by reducing the number of requests per page," but that mechanism only affects a visitor's repeat requests and does nothing for a first, uncached hit against the origin. A page cache hit skips PHP-FPM and MySQL completely for that request; a cache miss falls straight back into the worker queue described above.
Object Caching with Redis and Memcached
Object caching closes a different gap in TTFB than page caching does: it speeds up the PHP execution that page caching bypasses entirely, rather than skipping PHP altogether. WordPress.org describes object caching as "the act of moving data from a place of expensive and slow retrieval to a place of cheap and fast retrieval," which in practice means storing database query results and API responses in memory instead of re-fetching them on every request.
- WP_Query post and page results, so a repeated lookup skips a MySQL query entirely.
- WordPress's transients API, the mechanism behind time-limited cached values such as external API responses and menu registrations.
- WooCommerce session data and cart fragments, which change on nearly every request for a signed-in shopper.
- Taxonomy and term caches used to render categories, tags, and navigation menus.
None of this persists without a persistent object cache, backed by Redis or Memcached, sitting behind WordPress's built-in WP Object Cache: without one, the in-memory cache is scoped to a single request and discarded the moment it ends. Kinsta, Cloudways, and Hostinger all include Redis in their managed plans specifically to close that gap. Object caching is not a substitute for page caching: a WooCommerce cart page, or any other page a page cache genuinely cannot serve, is exactly the case where the database round trips object caching eliminates matter most.
OPcache and PHP Bytecode Acceleration
OPcache attacks a cost that page caching and object caching both leave untouched: the CPU time TTFB loses to PHP compiling its own source files on every request. Every PHP request normally parses the requested file, and anything it includes, into bytecode the Zend Engine can execute, repeating that parsing on every single request unless something intervenes. OPcache intervenes by compiling that PHP bytecode once and holding it in shared memory, so later requests fetch the compiled version instead of re-parsing source from disk. WordPress.org states the effect plainly: adding an opcode cache "will improve PHP's performance by many times."
| Without an Opcode Cache | With an Opcode Cache |
|---|---|
| PHP re-parses every requested file on every request | Bytecode compiles once and is served from memory |
| Compiled bytecode is discarded after the request ends | Bytecode stays resident in shared memory, sized by opcache.memory_consumption |
| CPU overhead is the full parse and compile cost | Overhead drops to a memory fetch |
| Effect on TTFB is the unoptimized baseline | Meaningful reduction on every PHP-FPM worker cycle |
OPcache is bundled with PHP 8.x releases, including PHP 8.2, but it has to be loaded through the zend_extension directive in php.ini, so it is worth confirming that a host has it active (the WordPress.org guidance also names WinCache as the IIS equivalent). It operates as a server-level setting rather than a WordPress plugin, so there is nothing to install on the site itself, only opcache.ini values worth confirming with a host.
CDN Edge Caching and Cloudflare APO
TTFB has one more layer above the origin server entirely: the network path a request takes to reach it, and a CDN shortens that path before the origin is ever involved.
- Standard CDNs such as AWS CloudFront, Fastly, and BunnyCDN cache static assets, CSS, JavaScript, and images, at edge nodes close to the visitor, cutting round-trip distance without touching dynamic HTML.
- Cloudflare APO (Automatic Platform Optimization) extends that caching to the HTML itself for WordPress sites, a distinct product from Cloudflare Workers, Cloudflare's separate edge-compute platform.
- WordPress.org's optimization guidance frames a CDN's core job as mirroring static files, like images, across geographic regions so every visitor gets a copy from a nearby edge node.
Cloudflare's APO documentation describes caching dynamic content, including HTML, removing round trips to the origin server and reducing time to first byte directly, a meaningfully different job from a standard CDN's static asset caching and the reason Cloudflare APO appears specifically in WordPress performance guidance rather than general CDN guidance. Two follow-on resources cover the setup itself: how content delivery networks reduce latency, and configuring Cloudflare for WordPress performance, including the APO toggle described above. The four layers stack in the order they intercept a request: CDN edge first, then page cache, then object cache, then opcode cache, and a TTFB investigation that starts at the wrong end of that stack fixes the wrong bottleneck first, the same order worth checking whenever a Core Web Vitals report flags TTFB as the constraint behind a slow Largest Contentful Paint score.
Further reading
Frequently Asked Questions
What exactly is TTFB and when is it considered high?
TTFB is the milliseconds between a browser sending an HTTP request and receiving the server's first response byte, including DNS lookup, TCP handshake, and TLS negotiation time. web.dev uses 800 ms as a rough target; above that threshold, every downstream Core Web Vital (Largest Contentful Paint in particular) takes the same delay hit, compressing the time budget available for rendering and interactivity.
Do PHP workers matter if my site uses a page cache?
A well-configured page cache serves most visits as static HTML without involving PHP at all, so the majority of traffic bypasses the worker pool entirely. PHP workers become the binding constraint only for requests the cache cannot serve: logged-in sessions, WooCommerce cart pages, live search queries, and WP-Cron background tasks that regenerate cache entries.
What is the difference between object caching and page caching?
Page caching stores the fully rendered HTML output of a URL so the next visit skips PHP and the database completely. Object caching (typically backed by Redis or Memcached) stores individual database query results and API responses in memory, so PHP still executes but expensive database round trips are eliminated; object caching primarily benefits dynamic pages that page caching cannot fully serve.
