What does site speed and performance mean in the first place? These are attributes that can be measured objectively with the help of different indicators but there is also a subjective aspect to them as well, that are based on customer experience. Both the performance and the site speed depend on the environment, that’s created by the basic operations of a website (such as load time, response speed perceived by the user, endurance). These aspects defy the user experience and are responsible for ensuring smooth business operations. 

What influences site speed?

First thing’s first, let’s see what circumstances affect the performance of a Magento webshop. We can divide these into two main groups:

1) Components that build up the system

• The site speed is obviously affected by the performance of the default base engine’s (Magento’s) prevailing operations, which can vary slightly between different versions.
  
• It can also be affected by the software environments of the servers that the webshop is running on (such as PHP, MySQL). This includes up-to-datedness, versions, configurational status, server-level cache operations as well as hardware properties (processor power, memory, scalability, cluster status, network bandwidth, and so forth). 
  
• Other important factors include the quantity and quality of live site modules. Besides the integrated and external modules that are linked to the site, the frontend framework’s quality and complexity also defy performance. 
  
• If a website is integrated with external software (an ERP for example) then the interfaces of these might hinder the site’s load. The interfaces that are building up these systems and the integrational solutions will have an influence on the performance. 

2) System operation and usage environments

The site speed that the users’ experience is heavily influenced by demand and the current number of visitors on the site.

Especially during the campaign or promotional periods. To put this into context, the speed of our website won’t be the same during a Black Friday campaign period – as thousands of users might be at a check out stage all at once -, as it would be on a chill summer’s morning.    

Performance is also subject to the number of users being logged in to the admin panel at once and the intensity of the tasks they are carrying out in the system.

The more tasks are running simultaneously, the heavier the load is on available capacities. (With this in mind, the workflows between Magento, ERPs and external software can be considered to be ‘heavy users’, as these webservice-based processes constantly import and export data, they run indexing tasks, empty caches, etc.) 

• A few other usage-related aspects that affect Magento’s performance:
  
• The number of available products, categories, and product attributes
  
• The volume and frequency of data import on the site
  
• The size and optimization of multimedia content and imagery on the site 
  
• The number of active processes for pricing, coupon, and other catalog indexing and data extraction 
  
• Number of languages and shop views available 

The above clearly shows that the performance of a Magento webshop depends on so many different things. To sum up, server infrastructure, applied development methods, functional complexity are key but the webshop’s environment and usage are also aspects to bear in mind. 

There’s a question that seems to come up quite often: who’s responsibility is it to make sure that a webshop runs as smoothly as possible? Does it have to do with development, with server operation or with admin? Truth is if you want to enhance the performance of your site you need to focus on these three things in equal measures.  

Server infrastructure requirements

Let’s start with the most important thing: Both versions of Magento are very robust software that requires a strong server background. If you don’t back them up with appropriate infrastructure, then you might run into severe speed or performance issues. In this sense, Magento sites require more resources than WordPress or Drupal-based sites. With Magento, shared hosting databases should be also ruled out. You will need at least one VPS or ideally a dedicated server, and for sites with heavier traffic or with more complex functionalities, clustered servers or strong cloud-based solutions are recommended. 

Okay, but how much does this cost? Well, it’s hard to tell. For sites with smaller traffic or with more simple functionalities, a VPS could do the trick – these usually cost around 80- 90 EUR a month. For webshops that either has thousands of products in their offering or make a high number of sales, a dedicated server or a cloud database would be the suggested alternatives, making for an investment of 160 – 180 EUR on a monthly basis. A clustered solution with several items (separate frontend servers, database servers, and load balancers) could involve an investment that’s within the hundreds of thousands month after month. 

There is another question that comes up quite often: is it worth investing in having our own server, being webshop owners? The answer to this one is quite simple actually: no. By owning a server, we limit the possibilities of our own expansion, we can’t change configurations to cater to higher demands in a flexible way plus we also need to get access to the know-how. By opting for cloud-based solutions, on the contrary, we can alter our capacity needs rapidly and for short time periods (even for a few hours only, during campaign periods for example).  

(Here’s a disclaimer though: OANDER doesn’t do server operation. We don’t have any business interest in where and how our clients run their webshops. Our recommendations are not fuelled by gaining extra profit, we simply just have the experience)

load time We develop it, so it’s fast. Read more

Speed-up processes from a development perspective

Let’s check a few methods from a development perspective, that could help with to accelerate site speed if needed. Optimization for example is the umbrella term for development solutions affecting the operational environment, with the aim of improving both site speed and performance. Here are a few of these solutions. We often suggest these if a Magento webshop needs a bit of extra attention. 

This list is not complete, these are just the most common first steps you can take that will bring the best possible results. It’s worth mentioning that these are additional development tasks that are excluded from Magento’s base operations. 

• Block cache: by this, we usually mean the rearrangement of the caching processes of category pages. Magento saves all data from the category pages by default. Due to frequent product enrichments however, these cache saves can get outdated quickly. When this happens, Magento has to keep caching over and over again. In such cases, users might end up coming across cache content that’s not coming from a saved, up-to-date source and this might result in site overload. The block cache method offers a possible way to prevent this from happening. Instead of caching the entire category page, it is the individual products and their frontend appearances that are cached only. Instead of having to cache the whole category page it’s enough to fill the cache with the new data that includes the attributes of selected products that need updating. To put this into context: changing the price or the stock status of a single product doesn’t result in the whole category page cache getting outdated. Opting for cache blocking is only recommended for very intense product enrichment as it dramatically increases the number of cache data packages. For this reason the emptying methods used during the caching method also need to be blocked to decrease the number of processes. 
  
• Lazy load: this is a method we usually suggest for speeding up start pages, longer subpages, and category pages. With this solution the products and UI components only load just before the users see them – as they are scrolling through the page – instead of loading all the content in the beginning. Lazy load helps us to make the first full rendering and loading of the site a lot faster in the user’s perception. In other words, the method doesn’t change the actual load time of the site itself, but the user will have a noticeably quicker response with their own experience. 
  
• Cache Warmup: the purpose of this process is to load the ajax cache components – that were predefined by algorithms – in advance, most commonly for product pages. It works like this: after emptying the cache, we automatically fill them up again so that new visitors experience a cache hit rather than a cache miss. This helps to reduce the number of users who experience a cold cache; however this method makes cache clearing more complicated. 
  
• File groupings for returning visitors: another way to improve site speed is to start grouping files that are linked to page load and user-operated processes. By doing so, the browser has fewer files to process when loading the site. The name of these grouped files will include the date when they were generated, so the user’s browser will know whether it should load the new version or just use the previous one if it’s still appropriate. This ultimately speeds the site up for returning visitors.  
  
• Module clearing: webshops that have been running on and have been constantly updated on a Magento engine for a long time will typically have a lot of different modules being integrated. Many of these might not even be needed anymore.  Despite not being used they might still take up resources in the background. We suggested checking for such modules annually and getting rid of those not needed anymore. It’s not enough to simply deactivate them, they need to be deinstalled on a database level. 
  
• Emptying big log dashboards: Magento creates module logs for itself for debugging and traceability purposes and these are stored in databases. The databases tend to grow in size: sometimes it’s worth archiving and emptying their content so that we can free up storage and we can take an unnecessary load off the database at the same time.