Categories and listings
We check the number of operations performed when generating product lists, prices, attributes and filters.
Magento performance optimisation
The store takes a long time to load. Search and the administration panel are getting slower. Each fix brings a temporary improvement, but after a while the problem returns.
In this situation, we do not start with random attempts to “speed up Magento”. First, we measure the platform and determine where the actual bottleneck lies.
Only then do we decide what is worth optimising.
A free 30–60 minute call. We will discuss the symptoms, available measurements and platform architecture. We will indicate which data and tests should form the starting point for diagnosis.
Diagnosis
A slow store is a symptom
In Magento, the visible problem does not always reveal its cause.
A slow category may result from a database query, the way attributes are fetched, a third-party module or indexing. Slow search may originate in the OpenSearch configuration, but just as easily in the data model or the way queries are built.
Adding cache or increasing server resources may temporarily reduce the symptoms, but it does not necessarily solve the source of the problem.
That is why we start with diagnosis, not a ready-made list of changes.
Scope of analysis
What we diagnose
We usually analyse several areas at the same time.
Product pages
We analyse the cost of fetching attributes and related products, as well as additional modules executed with every request.
Search and OpenSearch
We verify index structure, query construction and the scope of data processed by the search engine.
Database and SQL
We look for expensive and repetitive queries, as well as operations performed more often than necessary.
Cache
We check the configuration and whether the cache actually reduces the application’s workload.
Infrastructure
We analyse whether the environment is properly matched to the way the specific platform operates.
The frontend is also part of the analysis. If it proves to be the main constraint, we will not force the search for a problem in the backend.
How we work
How we work
-
01
Diagnosis
We start with diagnosis and profiling.
-
02
Priorities
On this basis, we set priorities-not everything needs to change at once. We address first the areas that deliver the greatest effect relative to cost and risk.
-
03
Changes
We introduce changes in stages and measure the result after significant modifications.
-
04
Decision
If the analysis shows that further optimisation of an area makes no economic sense, we say so and propose a different approach.
Profiling
Measurements should answer a specific question
We profile the platform to determine where time is actually being lost and then verify whether a change has improved anything.
We compare measurements under conditions that are as similar as possible.
Not every result needs to become a formal client report. Some profiling is simply a working tool for the team.
On large platforms, optimisation often does not end with one project. The catalogue, code and integrations keep changing, so over time a bottleneck may emerge elsewhere.
Optimisation examples
Categories and listings
SQL queries
- Before
- 652
- After
- 99
backend time
- Before
- 2.69 s
- After
- 0.787 s
CPU usage
−65%
In one profiled project, generating a single category executed 652 SQL queries. After the changes, this fell to 99-approximately 85% fewer.
In the same comparison, backend category generation time fell from 2.69 s to 0.787 s-approximately 71% less-while CPU usage dropped by approximately 65%.
The changes included optimising queries, indexing methods and the operation of additional modules.
Product pages
A product page may perform many expensive operations, particularly with extensive attributes, recommendations and related products.
In subsequent profiles of the same project, we achieved:
shorter backend product-page generation time
up to 62%
fewer I/O operations
up to 71%
less CPU time
up to 54%
SQL queries
- Before
- 373
- After
- 151
The optimisations included how attributes and related products are fetched, third-party modules and the use of OpenSearch.
What these figures mean-and what they do not
Faster backend execution means less work is required to handle a single request and may leave the platform with more resource headroom as load increases.
It does not automatically mean better Core Web Vitals, a higher Google ranking or more sales.
The user experience is also affected by the frontend, images, third-party scripts, CDN, network and the device itself.
We do not use backend profiling results as evidence of increased conversion.
These are results from comparable technical backend profiling without FPC or OPcache. They do not represent average production response times or Core Web Vitals results, nor do they constitute a promise of improved SEO rankings, conversion or a specific PageSpeed score.
Data and search
Search and OpenSearch
OpenSearch is responsible for more than the search box. With large catalogues, it is also an important part of filtering and working with catalogue data.
We analyse the indexing method and the queries sent to the search engine.
Sometimes it is more efficient to move specific reads from the relational database to a properly prepared index. This is not a universal recipe-the decision follows from measurements and how the data is used.
Database and SQL
Database problems can remain hidden for a long time, especially when cache masks some expensive operations.
We check which queries take the longest, which are executed repeatedly and whether modules fetch more data than they actually need.
Sometimes a small change to the way data is fetched has a greater effect than increasing infrastructure resources.
Environment
Cache and infrastructure
Redis, Varnish, PHP, the database and environment configuration directly affect Magento’s behaviour.
Cache is necessary, but it should not be used solely to hide expensive code.
If the diagnosis shows that the problem really lies in the infrastructure, we can also help change or optimise it.
Frontend
What about the frontend?
This service focuses primarily on the backend, data and infrastructure, but we do not ignore the frontend.
For new implementations, we work with Hyvä by default. In an older store, however, the existing frontend may itself be a significant source of problems.
If the backend generates a response quickly but the store remains heavy for the user, rebuilding the presentation layer may be the right direction.
In that case, we recommend Hyvä for Magento → , rather than trying to solve a frontend problem through database or cache changes.
Fit
When another service is needed
Large catalogues in Magento
If the problem grows primarily with catalogue size and stems from the data model, indexing or handling a large number of values, a better starting point may be an analysis focused on large Magento catalogues.
large catalogues in Magento →Hyvä for Magento
If the backend is fast and the problem lies in the frontend layer, the presentation layer may need to be rebuilt with Hyvä.
Hyvä for Magento →Magento takeover and stabilisation
If the platform is generally unstable, errors keep returning and the project’s technical condition is difficult to determine, it is worth starting with a project takeover and stabilisation.
Magento takeover and stabilisation →Questions
FAQ
VLCT
It is not responsible to give a single figure without a diagnosis. In one of our projects, backend category generation time fell from 2.69 s to 0.787 s, but this was the result for a specific platform and a specific scope of changes.
VLCT
It can help if backend response time is the problem, but Core Web Vitals also depend on the frontend, assets, rendering approach and third-party scripts. We must first determine which layer is the actual constraint.
VLCT
Only when a significant part of the problem lies in the frontend. Hyvä does not fix a slow database or issues with OpenSearch, integrations or indexing.
VLCT
Not always. More powerful infrastructure may help when current resources are the constraint, but it will not fix inefficient code or a poor data model. First, we determine where resources are actually being lost.
VLCT
The scope of documentation depends on the project. We take measurements to make decisions and verify changes. Not every measurement needs to become a separate formal deliverable.
VLCT
It can be permanent for the problem that was removed, but the platform continues to change. New modules, integrations and data are added. For larger systems, performance should also be monitored as part of ongoing maintenance.