Cutting Magento 2 TTFB: A Production Core Web Vitals Playbook

To cut Magento 2 TTFB: enable Varnish full-page cache, move sessions and cache to Redis, run PHP 8.x with OPcache and JIT, and front the site with a CDN. Most slow stores are slow because full-page cache is off, misconfigured, or invalidated too aggressively — fix caching before anything else.

Key takeaways

• Varnish full-page cache is the single biggest TTFB lever — a cache HIT should serve in tens of milliseconds.
• Redis for sessions and the default/page cache removes filesystem and DB contention.
• PHP 8.x + OPcache + JIT cuts CPU time per request meaningfully versus PHP 7.4.
• The hidden killer is cache invalidation: frequent reindex/cron flushes turn every request into a cache MISS.
• A CDN handles static assets and shortens the network leg for global traffic.

Step 1 — Confirm full-page cache is actually working

Run the site behind Varnish and verify cache HITs in production (check the response headers). A surprising number of "slow Magento" cases are stores where FPC is set to the built-in cache, bypassed by a misconfigured header, or flushed constantly. Measure HIT rate before optimizing anything else.

Step 2 — Redis for sessions and cache

Put Magento's default cache, full-page cache backend, and session storage on Redis (ideally separate instances/databases). This removes filesystem locking and database round-trips from the hot path.

Step 3 — PHP 8.x, OPcache, JIT

Run PHP 8.1+ with OPcache enabled and a realistic opcache.memory_consumption. Enable JIT for CPU-bound workloads. On production also set opcache.validate_timestamps=0 and reload PHP-FPM on deploy, so the engine isn't stat-ing files on every request.

Step 4 — Stop fighting your own cache

The most common regression: cron, indexers, or a third-party module flushing the full-page cache on a tight schedule. Set indexers to "Update on Schedule," batch catalog updates, and audit which events trigger cache clears. A high TTFB that spikes periodically is almost always invalidation, not raw compute.

Step 5 — CDN and asset discipline

Serve static assets and images from a CDN, enable HTTP/2+, and pair this with a fast frontend theme (Hyvä) so the cached HTML you serve is also light to render.

What "good" looks like

On a cache HIT, aim for TTFB well under 200 ms and a mobile LCP under 2.5 s. If your TTFB is good but Core Web Vitals still fail, the bottleneck has moved to the frontend — that is a theme problem, not a server problem.

Want the bottleneck found and quantified? System Architecture Audit or request a quote.

Frequently asked questions

What causes high TTFB in Magento 2?

The most common cause is full-page cache being disabled, misconfigured, or invalidated too often, so requests are computed from scratch. Other causes are missing Redis for sessions/cache, running an old PHP version without OPcache, and the absence of a CDN.

Does Varnish improve Magento 2 performance?

Yes, significantly. Varnish serves cached pages in tens of milliseconds instead of executing the full PHP/Magento stack. It is the single biggest TTFB improvement for most stores, provided the cache hit rate is actually high.

Should Magento 2 use Redis?

Yes. Putting the default cache, full-page cache backend, and session storage on Redis removes filesystem locking and database contention from the request path, lowering and stabilizing response times.

What is a good TTFB for Magento 2?

On a full-page cache hit, aim for a TTFB under about 200 milliseconds and a mobile LCP under 2.5 seconds. If TTFB is fast but Core Web Vitals still fail, the bottleneck is the frontend theme, not the server.