It’s no secret that the Magento community is rife with complaints about the speed of a typical Magento website. Google has indexed almost 1 million web pages about Magento being slow. Clearly it is a huge problem for the thousands of Magento customers.
Magento’s poor load speed performance is one of several reasons we decided to create Miribase in the first place. We knew the future of ecommerce was speed, multi-screen compatibility and great SEO.
There are many great articles on the internet detailing the reasons why Magento is so slow and the steps that can be taken to try to improve matters. Unfortunately the main reason Magento is so slow is an architectural issue with the system’s core that is impossible to resolve. Magento’s greatest strength is also its greatest weakness. When creating Magento, its developers prioritised flexibility above all else and they created a system that is incredibly flexible, enabling the most obscure businesses to change Magento to their unique requirements. For the vast majority of businesses that operate relatively common business models, this flexibility comes at a big price.
Magento employs a common architectural model known as EAV (Entity-Attribute-Value) which is also used to some extent within Miribase. However Magento took EAV to a whole new level. When Google, Twitter and other forward-thinking companies moved in the direction of de-normalised database design such as “NoSQL” to address performance issues, Magento’s designers went in the opposite direction and implemented a database design that has been making many internet performance experts cringe as far back as 2009 and these design decisions will be maintained even in the upcoming new version, Magento 2.
With Miribase we also decided against a fully de-normalised database schema such as Mongo and instead settled for MySQL which powers many of the biggest and most popular websites we use each day such as Twitter and Wikipedia. Despite fast loading speeds being one of the most important goals for Miribase, we were convinced that this could be achieved within a traditional MySQL database design, and we were right.
The database design we ended up with looks sublime in its simplicity when weighed against the complexity of Magento’s schema, and the typical load speed of a Miribase website demonstrates the benefits of a simplified approach.
Magento load speed experts would say that many of Magento’s shortfalls can be overcome through the use of ‘caching’, a performance technique we also employ heavily as part of the Miribase Load Speed solution. However, caching can only go so far. In fact, caching only plays a role in loading ‘static’ web pages – pages that are not tailored for the user but are instead the same for everyone. Many pages on an ecommerce website do fall into this category, such as the Homepage and Category or Product pages. However, as soon as user interacts with a website, such as adding a product to their basket, the website then needs to be tailored specifically to the individual user, and caching goes out of the window. At this point the system’s core platform comes into play and only super-efficient coding and database design can save the day.
One reason is that it is made up of over 1 million lines of code (Miribase contains around 200,000 and most ecommerce platforms have less than 500,000) and the database is geared up for flexible data storage, not speed. It can take hundreds, if not thousands of individual code and database operations just to get the details of a single product for a Magento website!
With enough time and effort, it is possible to make a Magento website load more quickly. Achieving a ‘fast’ website is, however, virtually impossible due to the core system design.
If you are currently using Magento and would like to make changes to improve load speed, Guido Jansen has a list of 101 tasks that can be carried out to help in this area.
Luckily for Miribase customers, load speed performance is part of our core system, not an optional extra, so no changes are required to optimise our sites.