Magento TTFB Performance: How CDN, Varnish, and Redis Reduce Origin Work

TTFB measures the wait before the page can begin

A customer cannot begin receiving the HTML document until the server starts responding. Time to First Byte, or TTFB, measures the time between the start of navigation and the arrival of the first byte of the response.

That includes more than Magento application execution. TTFB can include redirects, DNS lookup, connection and TLS negotiation, network latency, request handling, and backend processing before the response begins.

That distinction matters.

A slow TTFB does not automatically prove Magento code is the only problem. But on a server-rendered Magento storefront, it is an important signal that too much time may be spent before meaningful page delivery can even begin.

Google's web performance guidance describes TTFB as a foundational metric for connection setup and web server responsiveness. As a rough guide, most sites should strive for a TTFB of 0.8 seconds or less, while remembering that TTFB is not itself a Core Web Vital and must be understood alongside real user-facing loading behavior.

Why Magento storefronts expose origin-performance problems quickly

Magento is a powerful commerce platform because it assembles a storefront from catalog data, pricing, customer context, configuration, layout instructions, extensions, inventory behavior, search dependencies, session state, and checkout-related rules.

That capability also means an uncached request can require meaningful work before the HTML response begins.

A slow request path may involve:

• PHP application bootstrap and dependency execution
• layout and block generation
• database reads
• cache lookups or misses
• extension/plugin execution
• catalog, pricing, or customer-specific behavior
• session and private-content handling
• downstream infrastructure latency

That is why performance work cannot stop at “the page loads.”

The better question is:

How much Magento work did this request require before the customer received the first byte — and how much of that work should have been avoided through correct delivery and caching architecture?

A fast Magento stack reduces unnecessary origin work in layers

Magento performance is not achieved through one toggle or one cache backend. A production storefront usually needs multiple delivery and caching layers, because each layer removes a different class of unnecessary work.

The architecture can be understood in three practical layers:

1. CDN or edge delivery for content that should be served close to the customer.
2. Varnish full-page caching for cacheable HTML responses that should not require Magento to rebuild the page on every request.
3. Redis or Valkey-backed application caching and session design for the requests that still reach the Commerce application.

A request served from an earlier cache layer avoids work farther downstream. A cache miss still reaches the application and exposes the quality of the origin architecture.

The goal is not to claim every page can be cached at the edge or in Varnish. Authenticated state, private content, checkout, business rules, cache invalidation, and custom extensions all affect what may be safely cached.

The goal is to ensure that requests do not perform expensive Magento work when they do not need to.

Layer one: CDN and edge delivery reduce avoidable distance and origin traffic

A CDN places delivery capability closer to customers than a single origin server. For static storefront assets such as images, CSS, and JavaScript, an effective CDN strategy can reduce the number of requests served from the Magento origin and reduce the distance those assets travel to the shopper.

Depending on the implementation and cache policy, edge delivery may also support additional cacheable content. That decision must be made carefully around Commerce behavior, invalidation, private data, and the actual CDN configuration.

A CDN review should confirm:

• static assets are delivered through the intended CDN path
• cache headers and asset versioning behave correctly after deployment
• origin traffic is reduced where expected
• invalidation and publishing workflows do not leave stale customer-facing assets
• geographic delivery performance is measured rather than assumed
• HTML or API edge-caching behavior, if used, is explicitly designed and tested
• authenticated and private customer content is not cached incorrectly

Layer two: Varnish is the production full-page cache Magento expects

For cacheable storefront HTML, Varnish is one of the most important Magento performance layers.

Adobe Commerce documentation strongly recommends Varnish in production because it is significantly faster than the built-in full-page cache. Varnish operates as a reverse proxy in front of the web server and can serve cached pages from memory, preventing equivalent requests from reaching the Commerce application.

That is the performance advantage:

When a valid full-page cache hit is served by Varnish, Magento does not need to perform the same page-generation work again for that request.

But a running Varnish service is not proof that the storefront is benefiting from it.

A Varnish review should validate:

• Commerce is configured to use Varnish for full-page caching
• the active VCL was generated/configured for the Commerce environment
• cacheable page requests are actually receiving cache hits
• invalidation is functioning when storefront content changes
• custom extensions are not making pages unnecessarily uncacheable
• cookie behavior is not bypassing cache unexpectedly
• TTL and grace behavior match operational needs
• cache-hit and cache-miss behavior is monitored during realistic traffic

Do not display invented cache-hit timing promises.

Layer three: Redis or Valkey supports the requests that still reach Magento

Not every request should be served from full-page cache.

Customer sessions, private content, cart behavior, checkout flows, uncached pages, administrative activity, and cache misses still require application work. For those paths, cache and session storage configuration matters.

Adobe Commerce documents Redis configuration for default cache and page cache, and its current documentation also identifies Valkey support in newer Commerce tooling. Adobe recommends assigning different database numbers when Redis is used for multiple cache/storage responsibilities, including default cache, page cache, and session storage.

That guidance is important because different workloads should not be mixed carelessly.

A cache/session review should confirm:

• which backend is used for default cache
• which backend is used for page cache, if Varnish is not owning full-page cache
• how sessions are stored
• whether distinct databases or appropriately isolated resources are configured for separate responsibilities
• whether eviction policies and memory limits are understood
• whether cache invalidation works correctly
• whether configuration matches the Commerce version in use
• whether observed cache performance aligns with real production behavior

Do not state that every store universally requires two separate Redis servers. For some environments, separate logical databases may be appropriate; for others, separate services or more advanced architecture may be justified by workload, availability, scaling, or operational requirements.

The performance claims that should never be published without measurement

Performance discussions often fail when architecture diagrams become promises.

A CDN, Varnish, and Redis architecture can materially reduce unnecessary origin work when correctly configured. But no credible engineer should promise a specific TTFB, concurrency level, or performance improvement merely because the components exist.

Actual results depend on:

• catalog and customer behavior
• cacheability of storefront pages
• extension and theme behavior
• cache-hit ratio
• infrastructure sizing
• database and search-layer performance
• traffic distribution
• session and private-content requirements
• CDN and invalidation configuration
• test methodology
• the difference between cached and uncached paths

The original version of this topic included illustrative values for uncached, Varnish-served, and edge-served responses. Those numbers may be useful in a measured case study, but they should not be treated as guaranteed outcomes for another merchant.

What to measure before calling a Magento store optimized

TTFB should be measured with enough context to distinguish a meaningful improvement from a misleadingly fast single request.

A fast cached homepage is useful. It is not a complete performance audit. A Magento storefront must also remain reliable when customers log in, search, browse dynamic catalog behavior, add to cart, and complete checkout.

Five common ways a Magento caching stack underperforms

The stack can be technically present and still commercially underperform. The difference is not whether the components were installed. It is whether they are configured, measured, and maintained around real Magento behavior.

A practical Magento TTFB review plan

The practical conclusion

TTFB is not the only performance metric that matters. It does not replace Core Web Vitals, checkout testing, field data, or real workload validation.

But for Magento teams trying to understand why a storefront feels slow, TTFB is one of the clearest starting signals available: how long did the customer wait before the response even began?

A properly designed delivery and caching strategy can reduce unnecessary work before Magento has to process the request:

• use CDN delivery intentionally and verify what it serves
• use Varnish for production full-page caching where appropriate, as Adobe recommends
• configure Redis or Valkey responsibilities carefully for the requests that still reach the application
• measure cache hits, cache misses, invalidation, field response behavior, and uncached paths
• prove every performance claim under conditions that match the business

The stack is not the hard part.

Knowing what the storefront is actually doing — and proving that the architecture reduces risk instead of only looking correct on a diagram — is where performance engineering begins.