To reduce Magento time to first byte, start with three high-impact changes: enable and size OPcache, put full page cache on Varnish, and use Redis or Valkey for sessions and backend cache. Those three alone bring most stores under the 800 millisecond threshold that PageSpeed treats as a passing server response. After that, tune PHP-FPM workers, fix slow database queries, and audit third-party modules that add server-side work to every request.
TTFB is the time from a shopper’s request to the first byte of response arriving. It is your server’s thinking time, and it caps every other speed metric, because nothing on the page can start rendering until that first byte lands. A fast Hyva frontend cannot rescue a slow backend. This guide covers the fixes in priority order, from the changes that move the needle most to the deeper tuning that squeezes out the rest.
Why TTFB matters more than it looks
A slow TTFB is uniquely damaging because it delays everything. Largest Contentful Paint cannot happen until the HTML arrives, and the HTML cannot arrive until the server responds. So a 1,500 millisecond TTFB adds 1,500 milliseconds to every Core Web Vital, no matter how well built the frontend is.
Google’s guidance treats a server response time under 800 milliseconds as passing. Above that, you are leaving speed, and conversion, on the table. The good news is that Magento TTFB is very tunable, because most of the delay comes from a handful of well-understood causes that have well-understood fixes.
The three high-impact fixes
Before any deep tuning, confirm these three are in place and configured correctly. They resolve the majority of TTFB problems on their own.
| Fix | What it does | Impact on TTFB |
|---|---|---|
| OPcache | Caches precompiled PHP bytecode in memory | Can cut PHP processing time by half or more |
| Varnish full page cache | Serves cached pages from memory, skipping PHP | Massive on cacheable pages |
| Redis or Valkey | Fast storage for sessions and backend cache | Removes database load for cache and sessions |
OPcache: size it correctly
OPcache stores precompiled PHP bytecode in memory so the server does not parse and compile scripts on every request. For Magento’s large codebase this is essential, and it can reduce PHP processing time by half or more. The critical detail is memory: the default opcache.memory_consumption of 128MB is not enough for Magento and causes cache evictions that quietly slow every request. Set it to 512MB so the entire codebase stays cached. An OPcache that is enabled but under-sized is a common hidden cause of slow TTFB.
Varnish: cache the cacheable pages
Varnish serves cached pages from memory without touching PHP at all, which is the single biggest TTFB win on public pages. We cover the configuration in detail in Magento full page cache and Varnish on Hyva. For TTFB specifically, the point is that a Varnish cache hit responds in single-digit milliseconds, while a cache miss pays the full render cost. Raising the cache-hit ratio directly lowers your average TTFB.
Redis or Valkey: take load off the database
Using Redis or Valkey for session storage and backend cache removes that work from the database and serves it from fast in-memory storage. This matters for the pages Varnish cannot cache, cart, checkout, customer account, because those still run through PHP and need fast session and cache access to respond quickly.
PHP-FPM tuning
Once the caches are right, PHP-FPM worker configuration determines how well the server handles concurrent uncached requests. Each PHP-FPM worker uses roughly 50 to 100MB of memory, so on an 8GB server, 50 to 60 workers is a reasonable target, leaving headroom for the database and other services.
The failure modes are at both ends. Too few workers and requests queue during traffic spikes, spiking TTFB exactly when you have the most shoppers. Too many workers and the server runs out of memory and starts swapping, which is even worse. Size the worker count to your available memory, and monitor for queuing under peak load. Running a current PHP version also helps, because each recent PHP release has improved performance, and staying current is part of routine Magento development hygiene.
Fixing slow database queries
After caching and PHP-FPM, the database is the next TTFB frontier. Uncached pages run queries, and a slow query on a hot path drags TTFB up for every shopper who hits that page. The usual culprits:
- Inefficient queries from custom code or extensions. A poorly written module can run an expensive query on every page load. Enable the MySQL slow query log to find them.
- An undersized buffer pool. The InnoDB buffer pool should hold your working data set in memory; too small and the database reads from disk constantly.
- Missing indexes on custom tables. Custom features that query their own tables need proper indexes, or those queries scan full tables.
Profiling is the key discipline here. Do not guess which query is slow; measure it with the slow query log or an application performance monitoring tool, then fix the specific offender.
Auditing third-party modules
Third-party modules are the most common cause of a TTFB that crept up over time. Every module that runs logic on page load, adds an observer, or injects a layout block adds server-side work. A store that installed a dozen extensions over two years can carry significant hidden TTFB from code that runs on every request.
The audit approach: disable non-essential modules one at a time on staging and measure the TTFB change, or use profiling to see which modules consume the most time per request. Remove or replace the ones whose cost outweighs their value. This is often the highest-return TTFB work on an older store, because it removes work rather than just caching around it.
Hosting and infrastructure
Software tuning has limits set by the hardware underneath it. A store on undersized shared hosting will hit a TTFB ceiling that no amount of OPcache tuning can break, because the CPU and memory simply are not there. For a real Magento store, dedicated or properly provisioned cloud hosting with enough CPU cores and memory is the foundation everything else sits on.
Two infrastructure choices matter most for TTFB. First, keep your database on the same fast, low-latency network as your application server, because every uncached page makes multiple database round trips and network latency between them multiplies. Second, size the server to your real traffic, including peaks, not your average, since TTFB degrades exactly when traffic is highest and workers start queuing. Under-provisioning to save money is a false economy when the cost is a slow store during your busiest hours.
A content delivery network helps too, though indirectly for TTFB. A CDN mainly speeds asset delivery, but by terminating connections closer to the shopper and offloading static requests, it frees the origin to answer dynamic requests faster.
Measuring TTFB correctly
You cannot improve what you measure wrong. Two mistakes are common. The first is measuring a cached page and declaring victory, when the real problem is the uncached cart and checkout pages that never hit Varnish. Always test both cached and uncached paths, because shoppers experience both. The second is measuring from a fast location near the server, which flatters the number; test from where your actual customers are.
Use a consistent tool and test the same pages before and after each change, so you are comparing like with like. Real-user monitoring captures what shoppers actually experience across devices and networks, while a synthetic test gives you a repeatable benchmark for tuning. Both have a place: synthetic for isolating a specific fix, real-user for understanding the true field experience. Track TTFB at the 75th percentile, the same threshold Core Web Vitals uses, so a few fast requests do not hide a slow tail that most shoppers actually feel.
A TTFB reduction checklist
Work these in order:
- Confirm OPcache is enabled and sized to 512MB. Check for evictions.
- Verify Varnish is caching with a high cache-hit ratio.
- Confirm Redis or Valkey handles sessions and backend cache.
- Tune PHP-FPM workers to your server memory, and watch for queuing.
- Profile and fix the slowest database queries using the slow query log.
- Audit third-party modules and remove or replace expensive ones.
- Stay on a current PHP version for the performance gains.
Measure TTFB before and after each step with a real tool, so you know which change delivered the improvement.
Frequently asked questions
What is a good TTFB for a Magento store?
Google treats a server response time under 800 milliseconds as passing in PageSpeed Insights. Aim for that or lower. Above 800 milliseconds, TTFB is adding delay to every Core Web Vital and costing you conversion, because nothing on the page can render until the first byte arrives.
What is the single biggest cause of slow Magento TTFB?
Usually caching that is missing or misconfigured: OPcache disabled or under-sized, Varnish not actually caching, or the database handling sessions instead of Redis. Fixing those three resolves most TTFB problems before you need deeper tuning.
How much OPcache memory does Magento need?
Set opcache.memory_consumption to 512MB. The default of 128MB is too small for Magento’s large codebase and causes OPcache evictions that slow every request. An enabled but under-sized OPcache is a common hidden cause of slow response times.
How many PHP-FPM workers should I run?
Each worker uses roughly 50 to 100MB, so on an 8GB server, 50 to 60 workers is reasonable, leaving memory for the database. Too few workers queue requests under load; too many exhaust memory and cause swapping. Size to available memory and monitor for queuing.
Can a fast frontend fix a slow TTFB?
No. TTFB is server thinking time, and it happens before the frontend does anything. A fast Hyva theme cannot start rendering until the first byte arrives, so a slow backend caps every speed metric regardless of how well built the frontend is. Fix TTFB at the server.
Where this fits
Reducing Magento TTFB is a priority stack: get OPcache, Varnish, and Redis right first, then tune PHP-FPM, fix slow queries, and audit third-party modules. Each step is measurable, and together they take most stores comfortably under the 800 millisecond threshold, which lifts every other speed metric and, with it, conversion.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a deep technology partner ecosystem across hosting, caching, and performance tooling. We tune server response, caching, and code on Hyva and Magento builds, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we approach Magento performance.
External references: Magento TTFB optimization tips, a guide to reducing Magento server response time, and a detailed Magento 2 TTFB optimization walkthrough.
