Performance · 2026-06-12 · 7 min
Magento TTFB: from 1.8s to 180ms, step by step
A UK retailer's warm-cache TTFB was stuck at 1.8 seconds. Here is the exact diagnostic order and the four fixes that brought it down 10×.
A warm-cache TTFB above 800ms on Magento 2 is not a hardware problem. It is a configuration problem, and it is almost always one of the same four culprits. This is the order I check them in, taken from a real engagement where we went from 1.8s to 180ms.
1. Confirm Varnish is actually serving the page
Half of the "slow Magento" stores I audit have Varnish installed and bypassed. Check the X-Magento-Cache-Debug header (or Age in production). If category and product pages show MISS on repeat requests, your hit rate is the problem — look for cookies or cache-busting query params fragmenting the cache, and for modules that mark blocks uncacheable. One cacheable="false" in a default-handle layout XML disables full-page cache for the entire site.
2. Find the EAV join trap
On this store, category pages spent 900ms in MySQL before rendering started. The slow log pointed to a layered-navigation module joining catalog_product_entity_* tables per attribute, per request. Moving attribute filtering to OpenSearch and letting the engine do what it is built for removed the join entirely.
3. Right-size Redis
Redis with default maxmemory and no eviction policy silently degrades: the config cache gets evicted mid-traffic, Magento regenerates it, and every request pays. Give the cache instance enough memory for the compiled config plus block cache, separate sessions into their own instance, and set allkeys-lru only on the cache database — never on sessions.
4. Put Cloudflare in front, properly
Edge-cache static assets and media aggressively, pass HTML through to Varnish, and enable early hints. The final stack served HTML in 180ms at the origin and under 80ms at the edge for repeat visitors.
The numbers
- TTFB (warm cache): 1.8s → 180ms
- Lighthouse mobile: 45 → 95+
- Hosting bill: ~30% lower after right-sizing the over-provisioned servers that had been compensating for the misconfiguration
None of this required a replatform, a theme rebuild, or a bigger server. Measure first, fix the stack, then talk about frontend.