Server · Foundations

Why Magento Stores Are Slow

Magento is structurally slower than most modern eCommerce platforms because it does more work per request. Understanding what work it does is the first step to making it faster.

Server & TTFB7 min read

Magento — both Open Source and the Adobe Commerce edition — is structurally slower than most modern eCommerce platforms when run with default configuration. The platform does substantially more work per request than Shopify, BigCommerce, or a headless storefront, and that work has to happen somewhere. Understanding where it happens is the difference between a Magento store that loads in 1.2 seconds and one that loads in 8.

The five places Magento spends its time

Almost every slow Magento store loses its time across the same five places. A useful diagnosis takes them in order:

Server-side rendering. Magento renders product, category, and CMS pages on the server using the Layout XML system, building each page from a tree of blocks and templates. Even with full-page caching active, cache-miss rendering is expensive — typically 800 ms to several seconds depending on the catalog size and the depth of the layout tree.
Database queries. The EAV (Entity-Attribute-Value) data model that backs catalog and customer data fans out simple lookups into joins across many tables. A category-listing page can issue dozens of queries; an unconfigured search page can issue hundreds. Slow MySQL or unindexed product attributes show up here.
Caching layer mismatches. Magento expects multiple cache backends — full-page cache, configuration cache, layout cache, block cache, and session storage — and serves them all out of the same Redis instance by default. Stores running on file-based caching (the default before Redis is configured) pay 10–100× the latency for every cache hit.
Frontend asset weight. Magento's default Luma theme ships ~2 MB of JavaScript and ~600 KB of uncompressed CSS. Modern alternatives like Hyvä cut that to ~80 KB JS / ~50 KB CSS but require theme-level migration. The default state is heavy.
Indexer state. Magento maintains 9+ indexers (URL rewrites, product price, stock, search, etc.). When indexers fall behind their source data, page rendering falls back to non-indexed queries that are an order of magnitude slower. A store with stale indexers feels slow for reasons that don't show up in any obvious metric.

What a healthy Magento response looks like

A reasonably-tuned Magento 2 store on appropriate hosting should produce, for a fully-cached category page, a server response time (TTFB) in the 100–300 ms range and a Largest Contentful Paint under 2.5 seconds. Cache-miss responses on the same hardware will land in the 800–1500 ms range. Stores significantly outside those bands almost always have a specific named cause — most often Redis misconfiguration, a missing OPcache, or a database under-resourced for the catalog size — rather than a vague 'Magento is slow' problem.

Run the speed test on your store before reading further. Specific numbers from your actual storefront will tell you which of the five domains above is your bottleneck, and the rest of the guide library is organised around them.

Where to start

If you don't know where your bottleneck is, the most efficient diagnostic order is: server response time first (cheap to fix when it's a configuration problem; expensive when it's hosting), then full-page-cache configuration (almost always the highest-impact server-side fix), then frontend asset weight (expensive but durable), then indexer state (cheap to verify, occasionally the whole problem), then database query patterns (subtle and developer-time-intensive).

Each domain has its own dedicated guide on this site — start with the most likely cause first.