Magento 2 Time-to-First-Byte: Diagnosing and Cutting TTFB on Slow Stores

Time-to-First-Byte (TTFB) is the time between a browser sending a request and receiving the first byte of the response. In Magento 2 stores it is routinely the single biggest component of perceived slowness — and the part developers most often misread as a "network" problem. This is a measured, layer-by-layer guide to finding where your TTFB actually goes and reducing it.

Why TTFB matters more than you think

Lighthouse and Core Web Vitals shine a spotlight on Largest Contentful Paint (LCP), but LCP can rarely beat TTFB by much. A 1.2-second TTFB on a product page caps your LCP regardless of how aggressively you bundle JavaScript or serve compressed images. Google has measured that a 100ms reduction in TTFB reliably improves conversion, so it is worth treating TTFB as a first-class metric, not a side effect.

Before optimizing, log TTFB accurately. The Chrome DevTools Networking panel reports it, but for repeatable numbers use a scripted check that curls the page across several runs, warm and cold:

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" \
    https://example.com/product.html
done

The gap between TTFB and total time is download time (dominated by payload size, static assets, and compression). The gap between connection time and TTFB is server-side latency — that is what this article tackles.

Break TTFB into its layers

TTFB decomposes roughly as: DNS → TLS handshake → reverse-proxy accept → PHP-FPM queue/wait → PHP frame (router, bootstrap, layout, FPC/BFC hit) → database/Redis/Elasticsearch calls → first byte out.

Profiler output is the fastest way to see the split. The built-in Magento profiler (Mage::setIsDeveloperMode(true) plus dev/debug/profiler in the DB) prints a flat/grouped profile to the page. For production, an APM like New Relic or Blackfire shows the same breakdown without giving customers profiler output. If TTFB is high but the PHP profile is clean and fast, your latency is upstream — TLS, proxy, or queueing.

1. TLS and connection setup

Each HTTPS request pays for a TLS handshake. Two quick wins:

• Enable TLS 1.3 and session resumption. TLS 1.3 cuts the handshake to one round trip and, with session tickets, allows resumption on subsequent connections. Make sure session_tickets and OCSP stapling are enabled at Nginx level.
• Keep connections alive. keepalive 64; in the upstream block and HTTP/2 both let one browser connection serve many requests, amortizing handshakes across JS, CSS and image requests. A store that does this can drop its median TTFB noticeably on repeat visits without touching PHP at all.

2. Reverse proxy and PHP-FPM queueing

A very common failure is not a slow PHP process but PHP-FPM having no free worker to serve the request. Check the queue:

watch -n 2 "pgrep -c php-fpm"
# and inspect the Nginx error log for "max_children reached"

If you see the slow log filling (configure request_slowlog_timeout and slowlog in php-fpm.conf), workers are busy long past their budget. The remedy is usually pm.max_children too low for the traffic mix, or a handful of pathological requests monopolizing workers. Raising max_children without checking memory (pm is dynamic, each child consumes its memory_limit) can swap instead of speeding up.

Two structural fixes for queue health:

• Health checks and drain. Route health-checked traffic to Nginx upstreams so dead or saturated FPM pools don't get new requests.
• Microcache or Varnish in front. A reverse proxy that serves cached pages without touching PHP-FPM is the single biggest TTFB lever for anonymous traffic. The Full Page Cache deep dive explains why most product pages should be served entirely from cache, bypassing PHP and database on hit.

3. PHP frame and bootstrap

On a cache-miss (or for logged-in customers, who usually bypass FPC per-section), TTFB is dominated by the PHP bootstrap and layout rendering. Biggest contributors, in order:

• Collection and EAV queries. Add the query list in the profiler; a handful of heavy collections on category/product pages often account for most of the DB time. The database index strategy guide shows how to find the offenders with EXPLAIN.
• OPcache efficiency. Ensure opcache.enable=1, opcache.validate_timestamps=0 in production and a generous opcache.memory_consumption. The PHP OPcache tuning guide covers sizing.
• Layout and blocks. Rendering dozens of blocks is cheap only if their data is cached (blocks, layout cache, translations). The UI component guide and customer data sections guide reduce per-request work for logged-in traffic.

4. Database and Redis/OpenSearch round trips

Cold product/category pages typically issue many backend calls. TTFB contributions here are really query latency times query count. Attack both:

• Reduce query count — avoid N+1 collections, load relations in bulk (addAttributeToSelect in one pass rather than per-entity loops), and prefetch product options/stock in a single query.
• Reduce per-query latency — correct indexes, warm buffer pool, and LOCAL cache for session/config. The MySQL read/write replication split moves the read load off the primary and can shave tens of milliseconds per request.

OpenSearch/Elasticsearch appears on search and layered-navigation requests. Watch slowlog in the cluster; facet-heavy queries can add hundreds of milliseconds to the category request that runs them.

Warm vs cold TTFB — track both

Cold TTFB (a page no one has requested lately) is dominated by cache-miss work and fills around best with a generous FPC. Warm TTFB (a page already in Varnish/Redis) tests your proxy, connection and FPC-hit path. A healthy store should show warm TTFB in the tens of milliseconds and cold TTFB under roughly 400–600ms on the product path; anything above that on warm hits usually points at a proxy misconfig or a broken cache-tag invalidation that is recreating pages constantly. The cache tag invalidation guide is the reference when pages never stay warm.

A practical reduction playbook

1. Measure first: scripted curls, warm and cold, plus an APM profile of the slowest URL.
2. Fix the queue: max_children, slow-log, and health checks before touching PHP code.
3. Serve from cache: ensure Varnish/FPC covers product and category pages for anonymous traffic.
4. Cut query count on the uncached paths (login, cart, customer account).
5. Verify TLS/HTTP2/keepalive so connection setup is not adding hundreds of milliseconds on repeat visits.
6. Re-measure after each change; a single metric (median warm TTFB) kept in CI with a budget prevents regressions, as described in automated performance regression testing.

TTFB is the one number that makes all your other front-end work pay off. Get it under control first — every subsequent optimization (bundling, image sizing, lazy loading) shows a bigger effect on a fast first byte.