Adobe Commerce (Magento) is a powerful platform, but it is unforgiving of shortcuts. Stores that run beautifully in development hit a wall under real traffic, and almost always for the same handful of reasons. The good news: the failure modes are predictable, which means they are preventable.
Caching is the whole game
Most Adobe Commerce performance problems are caching problems. Full-page cache, block cache and a properly tuned Varnish layer are the difference between a page served in milliseconds and one rebuilt from scratch on every request. The most common regression is code that quietly makes pages uncacheable — a personalised block in the wrong place, a missing cache tag — so the hit rate collapses and the database takes the load.
Where stores fall off the cliff
- Custom code that disables full-page cache for everyone to serve one personalised element.
- N+1 queries in collections that are fine with 100 products and fatal with 100,000.
- Indexers left in the wrong mode, so catalog updates lock the storefront.
- Third-party extensions that each add a little overhead until checkout is slow.
- No load testing before a campaign, so peak traffic becomes the first real test.
Build for the peak, not the average
Performance on a quiet afternoon tells you nothing about Black Friday. The work that holds up at scale happens before the traffic arrives: profiling the real bottlenecks, load testing against realistic catalogs and traffic, keeping personalisation out of the cacheable layer, and watching the metrics that predict trouble — cache hit rate, database load, time to first byte. That is the difference between a launch that scales and one that becomes an incident.
Adobe Commerce scales well when it is engineered for the peak. The platform is rarely the limit; the shortcuts around it are.