TTFB Optimisation for Magento

Time to First Byte (TTFB) is the duration between a browser issuing a request and receiving the first byte of the response. For Magento it is the single metric most predictive of overall store quality — slow TTFB is associated with slow Largest Contentful Paint, slow interaction-to-next-paint, and the quality issues Google's Core Web Vitals report flags.

A reasonably-configured Magento 2 store should produce a TTFB of 100–300 ms for fully-cached pages. Stores in the 1000–3000 ms range are within the normal Magento misconfiguration band. Stores above 3000 ms almost always have a specific named cause — most often a hosting environment too small for the catalog or a full-page cache that isn't actually serving from cache.

The TTFB diagnostic ladder

Diagnose TTFB problems in this order, because each step is cheaper than the next and each one rules out a substantial fraction of cases:

1. Confirm the page is hitting the full-page cache. Check the X-Magento-Cache-Debug response header. If it reports MISS for what should be a cacheable page (a category, product, or CMS page in customer-anonymous state), nothing else you do will help — the page is being rendered from scratch on every request.
2. Check OPcache is enabled and sized. The opcache.memory_consumption setting in php.ini should be at least 512 MB for a Magento 2 store; the opcache.max_accelerated_files setting should be 130000 or higher. Stores running on default OPcache sizes (often 64 MB) are recompiling PHP files on every request.
3. Verify Redis is doing the caching. Run php bin/magento cache:status and check that all caches are enabled. Then run redis-cli info keyspace to confirm Redis actually contains Magento cache data. Stores that 'have Redis configured' but are still serving cache from the file system because of configuration drift are a common source of mysterious slowness.
4. Check PHP-FPM pool configuration. Default Apache mod_php or undersized PHP-FPM pools queue requests under modest concurrency. A pool with pm.max_children = 5 will queue every sixth concurrent request — making every concurrent visitor's TTFB worse without any easily-identifiable cause.
5. Verify hosting matches catalog size. A 50,000-SKU Magento store on shared hosting will be slow regardless of configuration. The MySQL working set for catalog data alone runs into multiple gigabytes for stores that size, and any RAM constraint produces page-render-time amplification because the database starts hitting disk on every query.

What good Redis configuration looks like

Magento's recommended Redis configuration uses three separate Redis databases — one for the default cache, one for the page cache, and one for sessions:

php bin/magento setup:config:set \
  --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-db=0 \
  --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 \
  --page-cache-redis-db=1 \
  --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-db=2

Running all three on database 0 — the default if the redis-db parameters aren't specified — produces hash-key collisions and degraded cache performance. Storefront builders new to Magento often miss this.

When TTFB still isn't fixed

If you've confirmed full-page cache hits, OPcache, PHP-FPM, and Redis and TTFB is still above 500 ms, the remaining causes are almost always: (a) Varnish in front of Magento not actually being used, (b) a slow MySQL query because of stale indexers or a missing index, (c) hosting that's structurally undersized for the catalog. Each of these has its own dedicated guide on this site.