Magento performance guide

Why Magento stores become slow

Magento performance problems rarely have one cause. The fastest route to improvement is to separate frontend, application, database, cache, search and infrastructure symptoms and measure each layer.

1. Start with evidence

Define what is slow and when it happens

“The site is slow” is not a useful diagnosis. Is first uncached response slow? Are product pages worse than categories? Does admin degrade during imports? Do cron jobs overlap? Does performance collapse only during traffic peaks? The pattern matters because different bottlenecks produce different symptoms.

  • Measure uncached and cached response times separately
  • Compare page types and customer states
  • Review peak vs quiet periods
  • Check cron, queue and indexer timing
  • Correlate application metrics with server resource pressure
2. Application & extensions

Custom code and extensions can create expensive execution paths

Plugins, observers, repository calls, repeated configuration loading and inefficient collection use can add small delays that multiply across a request. Third-party extensions should be measured like any other code rather than automatically trusted or blamed.

PluginsObserversCollectionsRepositoriesExtensionsCronQueues
3. Database, cache & search

Magento depends on several stateful services working well together

MySQL query patterns, Redis memory pressure, cache misses and OpenSearch health can all affect customer and admin performance. A cache that constantly evicts useful data or a search cluster under resource pressure can make application tuning ineffective.

  • Review slow/expensive database queries
  • Check Redis memory and eviction behaviour
  • Validate cache hit behaviour
  • Inspect OpenSearch cluster health and indexing workload
  • Review session and full-page cache architecture
4. Frontend & delivery

Backend speed does not guarantee a fast customer experience

Large JavaScript bundles, render-blocking assets, poor image delivery, third-party scripts and layout instability can dominate Core Web Vitals even when the application responds quickly. Performance work should cover both sides.

5. Infrastructure

Tune infrastructure after you know what the workload needs

More CPU or RAM can hide inefficient code temporarily, while an undersized environment can make good code look bad. Capacity, PHP-FPM, web server, database, cache, search and CDN settings should be adjusted against measured workloads.

Frequently asked questions

Questions we are often asked

Is Magento inherently slow?

Magento is a substantial application, but a well-engineered and correctly operated store can perform well. Problems usually come from the combination of custom code, extensions, data scale, cache/search configuration, frontend payload and infrastructure.

Should we install another caching extension?

Not before understanding the existing cache path. Additional caching layers can add complexity without fixing the real bottleneck.

Can performance work improve conversion?

Faster and more stable user journeys can support conversion, but the exact commercial effect depends on the store and should not be invented in advance.

Related expertise

Continue exploring

Need help applying this to your platform?

We can review your current environment and turn the guidance into a prioritised technical plan.

Start a Conversation