Speeding up Magento: it all starts with instrumentation

As tempting as it is to add to the high number of articles in existence entitled “10 ways to speed up your Magento store”, instead in this series of articles I am going to focus on a more scientific and engineering-led approach to the problem of optimising an underperforming eCommerce store.

Through the use of proper instrumentation and a solid refinement process you can ensure that you are focusing only on the key issues

In a world where most people use a some sort of mobile device to view the web, a performant eCommerce site is no longer only a requirement but an expectation. For example 53% of mobile visitors will leave when a page takes longer than 3 seconds to load so it should be no surprise that every millisecond counts.

So how should you go about thoroughly optimising your site? Through the use of proper instrumentation and a solid refinement process you can ensure that you are focusing only on the key issues slowing down your site rather than blindly adding fixes and hoping for the best.

In order to get the best results this will always be superior to the “one size fits all" approach as it focuses only on measurable and testable fixes.


It should also be noted that while this series of articles focus on retrospectively addressing performance issues the true best practice here is to take performance into consideration at every step of the way throughout the development process.

The best scenario is to test performance via an automated process as you will save hours and even days further down the line.  

Magento basic optimisation features

We are going to focus on Magento but the same principles can be applied to any eCommerce platform or website for that matter.

Lets start by crossing off some basics and ensure that you are running your store in a production ready mode. Be sure that you have the following performance features enabled:

  • Caching 
  • Flat category data
  • Indexing modes have been reviewed
  • JS and CSS merging
  • Use of a CDN (if applicable)
  • Redis or Memcache for sessions and cache storage

Now that we have Magento configured for production lets dive into our methodology for optimising your site and ensuring that you are focussing your energy on the items that matter most. 

The optimisation methodology

The key underlying methodology should always be the same :


Performance is all about bottlenecks.

The idea is that you initially identify what the single biggest performance issue is, measure it and focus on improving only that.

Once you are done, measure again to verify, deploy and go in search of the next biggest issue. This ensures that you are always fixing the biggest problem on your site. There is always room for improvement.

Now lets take a more detailed look at how to run this process effectively as well as looking at some tips that apply specifically to Magento. 



Everything starts with instrumentation.

The first thing we need to do before optimising anything is to measure it. This transcends many things outside of eCommerce and the digital world. How can you improve something if you can’t measure the improvement? 

At first glance when someone says a site is "slow" it may seem like a straight forward statement however you will soon find it is not. We need to define "slow" in more detail. Is it slow for certain users? Is it only certain pages? You get the idea. 

So we want to start by picking a select few metrics that matter to you and your customers, measure them and look at how they can be improved.

Key performance metrics

The metrics that you need to select will differ depending on your site and its purpose. For example maybe mobile performance doesn’t actually matter to your customers as much as desktop performance or connection speeds are generally not a problem. For the sake of this example though, I am going to pick some common metrics and then look at how to go about measuring them.

Lets start by making an important distinction between the two main optimisation categories of any website that are often confused:

Frontend performance vs Application performance.

In order to clearly understand the difference we need to understand what a typical HTTP request looks like:

Dev team split.jpeg

Looking at the above diagram we can see there are three distinct areas that can be measured: The network, the web server (application performance) and its response to the user’s browser and how long that take to render (frontend performance).

As we can't do anything to optimise the users network latency as a developer we are going to disregard that and focus on what we can control: Application performance and Frontend performance.

Now that we have made a distinction between the two lets look at some suitable metrics for each.

Application performance metrics

  • Average application response time
  • Slowest application transaction
  • Average MySQL response time

Frontend performance metrics

  • Time To First Byte / Document Interactive Time / Total render time
  • Overall page size
  • PageSpeed and YSlow score
  • Number of HTTP requests

Now we have a solid set of metrics. Next time we will discuss how to measure these effectively using New Relic for application performance and GTMetrix for frontend performance. We will go into detail about how to drill down into the items slowing down your site and how to go about fixing them.

If you are interested in a Magento code audit inclusive of a full performance report, you can learn more here.