You upgraded the server. You added more memory. You moved your Magento store to cloud infrastructure. On paper, everything should be faster. Yet product pages still hesitate. Search feels sluggish. Checkout takes longer than expected. During busy periods, performance becomes unpredictable.
This is where many merchants make the same assumption: if Magento is slow, the server must need more resources.
That is not always the case.
A well-configured cloud environment is an important foundation, but Magento 2 performance depends on much more than CPU and RAM. Caching, PHP workers, database queries, OpenSearch, extensions, cron jobs, external integrations and frontend code can all become bottlenecks. Recent Magento performance guidance similarly emphasises diagnosing backend response time, caching, database activity and application behaviour rather than treating server size as the only performance variable.
An experienced Magento agency should therefore start by finding out where the delay occurs before recommending more infrastructure.
Why can Magento 2 be slow even with powerful cloud hosting?
A Magento 2 store can remain slow on powerful cloud hosting when the underlying bottleneck is not infrastructure capacity. For example, adding more CPU will not necessarily fix an inefficient database query. More RAM will not repair an extension making unnecessary API requests. Moving to a larger virtual machine will not solve poor cache configuration.
Magento performance is better viewed as a chain:
Shopper → CDN → Cache → Web Server → PHP → Magento → Database/Search → External Services
A delay at any point in that chain can affect the experience delivered to the customer. That is why Magento 2 performance optimisation should begin with measurement rather than assumptions.
First, find out what is actually slow
Before changing your hosting plan, establish where the problem occurs. Does the entire website slow down during periods of heavy traffic? Does search take longer than other functions? Are product pages slow while cached pages remain fast? Does the problem appear mainly at checkout?
Each behaviour points towards a different area.
| Performance problem |
Possible cause |
What to investigate |
| Site slows during traffic spikes |
Infrastructure capacity |
CPU, RAM, PHP workers |
| Product/category pages are slow |
Application or caching |
Varnish, FPC, extensions |
| Search and filtering are slow |
Search infrastructure |
OpenSearch |
| Checkout is slow |
Dynamic processing |
PHP, database, payment APIs |
| First request is slow |
Cache miss |
Varnish/FPC |
| Magento Admin is slow |
Backend processing |
Database, extensions, cron |
| Intermittent slowdowns |
Background workload |
Cron, imports, indexers |
This distinction matters. A Magento agency investigating performance should be able to demonstrate where time is being spent rather than simply recommending a larger hosting package.
-
Your Magento cache may not be doing enough work
Caching is one of the most important parts of a high-performance Magento environment. Consider what happens when a customer requests a page that cannot be served from cache. Magento may need to execute PHP, process application logic, retrieve information from the database and assemble the page before returning it to the browser.
Now compare that with a correctly cached page. Much of that work can be avoided. This is why technologies such as Magento Full Page Cache, Varnish and Redis/Valkey play different but complementary roles in a properly configured Magento stack. Current performance guidance continues to identify Varnish and effective caching as central to reducing backend workload.
Cache HIT vs cache MISS
A cache HIT means the requested content is already available from the relevant cache and can be delivered without Magento rebuilding it. A cache MISS means Magento must perform more work to generate the requested content.
If a large percentage of supposedly cacheable traffic keeps reaching Magento itself, buying more computing resources may simply give an inefficient architecture more capacity to do unnecessary work.
Your Magento agency should therefore investigate cache behaviour before concluding that the store needs a bigger server.
-
The database could be your real bottleneck
Magento is heavily dependent on its database. Products, categories, customers, orders, configuration and many other parts of the store involve database activity. As your catalogue and transaction volumes grow, inefficient queries become increasingly visible.
Common warning signs include:
- slow checkout processing;
- a sluggish Magento Admin;
- slow category or product operations;
- high database utilisation;
- long-running queries; and
- performance degradation as order or catalogue data grows.
Third-party modules can make this worse. A single extension that repeatedly performs inefficient queries can create a noticeable delay across thousands of requests. This is another reason why simply adding resources to the application server may achieve very little.
A Magento agency performing a proper Magento performance audit should examine database activity, slow queries and application traces to determine whether MySQL is actually responsible for the delay.
-
Your PHP workers could be creating a queue
Think of PHP workers as checkout counters in a supermarket. You can build a much larger supermarket, but if only two counters are available and twenty customers are waiting, the queue remains.
Something similar can happen with Magento. Dynamic requests—including account pages, carts, checkout processes and certain API requests—require PHP processing. When available PHP workers are occupied, additional requests may have to wait.
This becomes particularly noticeable during:
- high concurrent traffic; and
- periods with significant API activity.
Correct PHP-FPM configuration therefore matters alongside the underlying cloud resources. Increasing resources may be appropriate when the application genuinely needs greater concurrency, but this decision should follow monitoring and load testing.
-
Redis or Valkey may be incorrectly configured
Redis or Valkey can be used within the Magento architecture to reduce the amount of repetitive work performed by the application. However, simply having an in-memory cache service installed does not mean it is configured optimally. Memory pressure, cache eviction, session workloads and architecture choices can all affect results. It is also important not to confuse Redis/Valkey, Varnish and a CDN. They solve different problems.
| Technology |
Main purpose |
| Redis/Valkey |
Application and session caching |
| Varnish |
Full-page caching |
| CDN |
Edge delivery of content |
| OpenSearch |
Catalogue search and related search workloads |
A good Magento hosting architecture uses these components according to their respective roles rather than expecting one technology to solve every performance problem.
-
OpenSearch could be slowing product discovery
If the homepage performs well but product search, filtering or catalogue navigation feels slow, the problem may be associated with the search layer. This becomes particularly important for Magento stores with large catalogues, complex filtering or high search activity.
Look for symptoms such as:
- performance degradation during intensive catalogue updates.
Recent Magento performance guidance highlights OpenSearch configuration, memory, network proximity and indexing as areas that can materially affect catalogue/search workloads.
Your Magento agency should therefore evaluate OpenSearch separately rather than treating every slow response as a web-server issue.
-
One Magento extension could be causing more trouble than fifty others
Extension count is not a particularly useful performance metric on its own. A Magento store with numerous well-built modules can perform effectively, while another store can suffer because of one poorly implemented extension.
An extension might add:
This is why randomly disabling modules is not a sound optimisation strategy. Application Performance Monitoring (APM), profiling and controlled testing in a staging environment can help identify which code is consuming time or resources. Current Magento performance guides similarly recommend profiling extensions and application transactions rather than guessing which module is responsible.
An experienced Magento agency should be able to distinguish between an infrastructure problem and an application-code problem.
-
Cron jobs and indexers may be competing with your customers
Your storefront is not the only workload running on a Magento server. Behind the scenes, the platform may be handling:
Problems arise when too many resource-intensive operations run simultaneously. Imagine a large product import, Magento indexing, a backup and an ERP synchronisation all starting while customers are actively shopping.
Even powerful infrastructure can experience unnecessary contention. This becomes especially important for B2B Magento environments connected with ERP, PIM, CRM or other business systems.
A Magento agency should therefore review when workloads run, not merely how much infrastructure is available.
-
Magento may simply be waiting for another system
Sometimes Magento itself is responding perfectly well. The delay comes from somewhere else.
Modern eCommerce environments commonly connect Magento with:
- recommendation engines; and
If Magento has to wait for one of these services before completing a request, the customer experiences the delay as a slow Magento website. Upgrading your server will not make an external payment or shipping API respond faster.
A Magento agency should therefore include external dependency monitoring in its performance analysis, particularly when the problem occurs during specific processes such as checkout.
-
Your CDN cannot solve every Magento performance problem
A Content Delivery Network (CDN) can significantly improve the delivery of static resources and reduce the distance between content and customers.
It can also reduce requests reaching the origin infrastructure. But a CDN is not a universal Magento speed fix.
If checkout is slow because of an inefficient database query, the CDN cannot rewrite that query. If PHP execution is taking too long, moving images closer to the shopper will not solve the backend problem.
This distinction is important when assessing Magento 2 cloud hosting.
The CDN should form part of the overall architecture, not replace application and infrastructure optimisation.
-
The problem may be in the browser rather than the cloud
Not every slow Magento website has a slow backend. The server may generate a page quickly while the customer's browser spends considerably longer processing it.
Common frontend problems include:
- third-party marketing scripts;
- complex page structures; and
This is where Core Web Vitals and frontend performance metrics become important.
It also explains why a good server response time does not automatically guarantee a fast perceived experience.
Magento performance optimisation should therefore consider both sides:
Backend: server, PHP, caching, database, search and APIs.
Frontend: JavaScript, CSS, images, fonts, layout and third-party scripts.
Current 2026 performance guidance similarly distinguishes backend response metrics such as Time to First Byte (TTFB) from browser-side performance measurements.
-
Your Magento infrastructure may be powerful but unbalanced
This is one of the easiest problems to overlook. Imagine having substantial CPU and RAM on the application server while the database or OpenSearch environment remains resource-constrained.
The overall store will still be limited by its slowest important component. Magento cloud architecture therefore needs to be considered as a system:
Application → Database → Cache → Search → Storage → CDN
Each layer has a different workload. This is one of the areas where specialist Magento cloud hosting differs from simply renting a large virtual machine. Magento-specific infrastructure needs to be designed around how the application actually behaves.
When does scaling Magento cloud infrastructure actually help?
There are situations where additional infrastructure is exactly what a store needs. Scaling becomes relevant when monitoring demonstrates sustained resource pressure, such as:
- consistently high CPU utilisation;
- database resource saturation;
- growing concurrent traffic;
- predictable campaign peaks; or
- substantial growth in orders and catalogue activity.
There are several ways to respond.
Vertical scaling
Vertical scaling means increasing resources such as CPU or memory for an existing server or service. It can be effective when a particular component genuinely requires greater capacity.
Horizontal scaling
Horizontal scaling distributes workloads across additional application instances. This can be valuable for Magento stores that need to support higher concurrency and significant traffic.
Autoscaling
Autoscaling allows infrastructure capacity to respond to changing demand according to predefined conditions or workload patterns. But autoscaling should not become a substitute for optimisation.
If an inefficient Magento process consumes twice as many resources as necessary, autoscaling may simply create more infrastructure to run that inefficient process.
Measure before you scale
This is perhaps the most important principle in Magento performance management.
Do not start with: “How much more CPU do we need?”
Start with:
“Where is the request spending its time?”
A useful Magento monitoring strategy should examine metrics such as:
| Metric |
What it can reveal |
| CPU utilisation |
Compute pressure |
| Memory utilisation |
Memory/resource constraints |
| TTFB |
Backend response behaviour |
| Cache hit rate |
Caching efficiency |
| Database query time |
Database bottlenecks |
| PHP execution time |
Application bottlenecks |
| OpenSearch latency |
Search problems |
| API response time |
External-service delays |
| Error rate |
Application/infrastructure instability |
Monitoring provides the evidence required to decide whether you need optimisation, reconfiguration or additional infrastructure.
Follow the Magento request instead of guessing
A practical approach is to follow a customer request through every layer of the architecture:
Customer → CDN → Varnish → Web Server → PHP → Magento → Redis/Valkey → Database/OpenSearch → External API
At each stage, ask four questions:
- How much time did the request spend here?
- Is this component under resource pressure?
- Is it behaving as expected?
- What happens to it when traffic increases?
This turns Magento troubleshooting from trial and error into a measurable process. And it is where the role of a specialist Magento agency becomes particularly valuable.
The objective should not be to sell the merchant more infrastructure. It should be to identify what the store genuinely needs.
Fully managed Magento hosting is more than a powerful server
There is an important distinction between buying cloud infrastructure and having a Magento environment actively managed. A fully managed Magento hosting service can encompass infrastructure configuration, Magento performance monitoring, database and cache optimisation, backups, security, scaling, deployment support and incident response.
The infrastructure also needs to evolve with the store. A Magento environment serving 1,000 orders a month may have very different requirements once the business reaches 10,000 orders, introduces new integrations or expands internationally.
For businesses looking to run Magento on Microsoft cloud infrastructure, a Magento agency with Azure and Magento expertise can bring these layers together rather than treating hosting, application performance and development as isolated responsibilities.
Ingold Solutions provides Microsoft Azure Fully Managed Magento 2 Cloud Hosting, combining cloud infrastructure with Magento-focused management and support.
Magento 2 performance checklist: what should you check before upgrading your server?
Before increasing your Magento hosting resources, review:
- Magento Full Page Cache and Varnish configuration
- Redis/Valkey configuration
- database performance and slow queries
- PHP-FPM configuration and worker utilisation
- Magento extensions and custom code
- ERP and third-party API response times
- frontend JavaScript and CSS
- CPU and memory utilisation
- traffic and concurrency patterns
Only after these areas have been measured should infrastructure scaling become the default answer.
A bigger server is not always the answer
When a Magento store is slow, increasing server resources can seem like the obvious solution. Sometimes it is the correct one. Often, it is not.
The more reliable sequence is:
Measure → Find the bottleneck → Optimise → Load test → Scale where necessary → Monitor continuously.
A capable Magento agency should help you understand whether the constraint is cloud capacity, Magento configuration, custom code, database activity, caching, search, integrations or the frontend before recommending the next investment.
That approach does more than improve Magento speed. It helps ensure that your cloud infrastructure grows for the right reasons rather than becoming an expensive workaround for problems elsewhere in the stack.
