Under 200ms TTFB is good, under 100ms is great, under 50ms is excellent — and for a typical WordPress request touching 300–500 PHP files, PHP OPcache alone provides a 50–95% performance improvement by pre-compiling PHP into machine code and keeping it in memory, eliminating repetitive compilation on every single request. Most WordPress installs have OPcache technically enabled by their hosting environment, but very few have it actually tuned to unlock its full benefit.
Realistic 2026 TTFB Targets by Context
| Page type | Target TTFB |
|---|---|
| Cached pages (page cache hit) | Under 200ms |
| Uncached, logged-in pages | Under 600ms |
| WooCommerce checkout specifically | Under 800ms |
The One OPcache Setting Almost Everyone Misses
OPcache’s default validate_timestamps setting is 1, which means PHP checks the file modification time on every single request to see if the cached compiled version is still current — a stat() system call for every PHP file touched in that request. Across 300–500 files per typical WordPress request, that’s 300–500 extra syscalls happening on every page load, purely to check whether files have changed since they were last cached. Setting opcache.validate_timestamps=0 disables those checks entirely, eliminating that overhead completely — at the cost of needing to manually clear or restart OPcache after deploying any code change, since it will no longer notice file updates automatically.
PHP-FPM Process Management
Switching from pm = ondemand to pm = dynamic or pm = static in your PHP-FPM pool configuration keeps worker processes alive in memory rather than spawning and killing them fresh on every connection — spawning a new PHP-FPM worker has real overhead, and ondemand mode pays that cost repeatedly under normal traffic patterns where dynamic/static mode avoids it by keeping a pool of workers warm and ready.
What to Actually Do, in Priority Order
- Start with page caching first, if you’re not already running it — nothing else on this list matters nearly as much if basic page caching isn’t in place for a typical visitor.
- Confirm OPcache is actually enabled and check
validate_timestamps— setting it to0on production (with a documented process to clear OPcache after every deploy) is where most of the remaining gain sits. - Review your PHP-FPM pool’s
pmsetting and switch fromondemandif that’s your current configuration. - Move to database tuning and object caching next for high-traffic sites, once the PHP-layer gains above are captured — see our separate coverage of Redis/Memcached object caching for that next step.
This pairs with WordPress Object Caching: Redis vs Memcached in 2026 and WordPress Hosting Uptime. Want your server’s TTFB profiled and tuned? Get in touch.
Frequently Asked Questions
Can I set opcache.validate_timestamps=0 without breaking my deploy workflow?
Yes, but it requires discipline — you need a reliable process to clear or restart OPcache after every code deployment, since with this setting the cache won’t automatically detect file changes on its own.
Do I need server/hosting access to make these changes?
Yes — both OPcache tuning and PHP-FPM pool configuration are server-level settings, not something adjustable through wp-admin or a typical WordPress plugin; you’ll need SSH/hosting panel access or your host’s support team.
Is this worth doing if I already have a good caching plugin?
Yes — page caching and OPcache/PHP-FPM tuning address different layers. Page caching helps anonymous, cacheable requests; OPcache and PHP-FPM tuning improve every PHP request, including the ones page caching can’t serve from cache at all.
Featured image: original illustration.