Maintenance and support
Creatim was assigned with building a new online store for Merkur (www.merkur.si), an established DIY retailer in SE Europe. The company struggled with its existing, over-customized Magento store. Based on Magento 2 Enterprise edition the new solution should aim for better user experience and more room for innovative merchandising initiatives.
We approached the project with due respect since it was the first M2 solution on our agenda. We had quite some
It looked like the problem was bigger than us. We contacted all Magento experts we could think of, hired Magento consulting service and of course, Magento enterprise support. I guess we unrealistically expected some Magento magician out there will just pull all the answers out of the hat. Yet no one could sort out the problem. Considering the feedback, the solution seemed to be in accordance with the Magento guidelines and recommendations and should be working fine.
Well, it wasn’t.
We were on our own. We went to the client and put the cards on the table. We needed more time. There was simply no easy way out but we were determined to get solution in check. They agreed to give us a second chance.
Luckily we have sorted out the main culprit quite soon. It was the facet navigation module that appeared to be the main cause of many performance issues we were struggling with.
I am not going to do bad advertising here, I am sure the guys are already working hard on improving their module to bring its performance in check.
However, I certainly want to wow the alternative.
So we redesigned much of the solution around Elasticsearch. Everyone who is familiar with the ES knows it does much more than just providing a “search” function. In fact it can play a pivotal role in the catalogue, relieving the database and speeding up the page view response times. While the front-end part of its multi-filter component may not look as fancy as some of the competitors’ its speed is persuasive.
Despite a barrage of complaints on the web regarding its performance, Magento 2 is actually not that slow. What really thwarts its speed are the modules that are being added to the core platform in order to improve the customer experience. The quality of this modules can vary significantly. What works well in M1 does not necessary perform in M2. Since the modules come from various vendors they may not get along with each other smoothly just out of the box. Leveraging one module can impede the performance of another one.
During the solution development it is vital to continuously monitor how much the added modules affect the time to first byte (TTFB). Test every feature added and if you find out it is compromising the overall performance, replace it. Fight for every millisecond! Redesign the dataflow, choose an alternative module or drop the feature altogether - just get to the bottom of the problem while still on track. Having to reach back later in the process can cause a domino effect forcing you to revamp much of the application logic already in place. We have learned this rule the hard way.
Needles to say, implementing Elasticsearch after much of the solution had already been in place was a daunting task. Yet it was worth it. We were hoping to alleviate at least some of the most notorious performance issues. But we refused to stop there. Learning the M2 ropes along the way we have turned a flat-tire pick-up into a racing car. How?
In addition to choosing the right components there are many decisive factors. Here is what worked for us.
The development team
People matter. Considering the scale of adjustments we lost just two months to get the solution back on track. Having experienced developers on board means they will not get stuck in escalated situation. Eventually they will find a way out.
Encourage rigorous testing in every step of the process. Plan enough testing time. Test everything, even processes and components that you think they should work fine (because they always have). Test them, optimize them, then test again.
Magento enterprise is a hungry beast so don’t scrimp on server capacity. But it is not just about capacity. Go deeper.
After the initial failure we decided rethink everything, including the technical infrastructure. Our administrators compared various types of bare metal hosting offering. The final infrastructure was based on processors that proved to be twice as fast as the initial ones. Furthermore, they implemented a spider that crawls the servers and moves all the product data into cache every morning thus reducing the TTFB as the first users knock on the door.
Schedule Your Free 30-Minute Consultation!
We would like to know more about your project, your current situation, and your goals. You have nothing to lose - it is always good to have a second opinion and outside experts bringing fresh views to the table.
What can we discuss:
- A quick audit of your website
- Your e-commerce agenda
- Your lead generation needs
- Staff outsourcing