E-commerce website performance - a case study

There is currently quite a lot of information on the internet about website performance in terms of page load speed. Unfortunately what most of it comes down to is what it known as 'Monkey patching' or otherwise hacking on top of out dated technology to achieve a performance gain.

Some developers however choose to do things differently, this post will focus on some technology and patterns used to gain a good balance between website performance, usability and scalability.

Creating a fast platform has to start in the right place and fortunately for us we had a purpose built modular CMS or Content Management System built from the ground up to facilitate a fast website in a widely used production environment. One of the core principals of the CMS was to never compromise on performance, a principal which was later relaxed for module development due to the core system using so few resources. This allowed us to create truly expressive, dynamic modules to enhance the capabilities of the system, one of which is the E-commerce module which we will be discussing in brief in this article.

Built over the course of 12 months between 2015 and 2016 the module encapsulates and otherwise tries to invalidate common annoyances in the e-commerce software sector. The two main gripes at most of the available e-commerce software were website load time and website scalability that is the number of concurrent users or transactions the website could tolerate before melting down without costing obscene sums of money for hardware.

We set out to tackle these gripes without adding lots of extra caching layers, caching proxies or otherwise advanced and often complicated configuration to the core system or its modules. We wanted an amazing out of the box experience with minimal configuration that would allow us to concentrate on creating outstanding user experiences and not have to worry to much about the effects on the system. We also wanted an amazing search experience, as, in our opinion, what was currently on offer was sub standard and could easily be improved upon.

Search

Having been and avid Lucene advocating company for many years through various job boards, recruitment websites, CRM systems, Directories and Property portals we knew that we wanted to utilise the technology again. At the time and on several other projects nodex was invested heavily in Elasticsearch, it was powering a few of our API's for searching and geo location lookups and was processing approximately 8 million requests per day on average with very little in the way of resource utilisation, this meant for us that we knew the system could handle almost infinite horizontal scalability.

For obvious reasons search is read heavy and thus it should be optimised for the read path, meaning that one write (a product update for example) may be read hundreds of thousands of times in search results before it is updated or removed, this allows Elasticsearch to make efficient use of its internal caching and keeps search times very low indeed, mostly under 10ms from application to server and back.

Facets / Filters.

Another great piece of technology that Elasticsearch (Lucene in general) afforded us was facets or filters. Facets are the little filter menus you often see say for example on Amazon or Ebay on the left of the screen and they give you product counts for varying different criteria, perhaps pricing blocks or categories or colours. Although other e-commerce software offered these filters, they were seldom any good and often either very expensive to create (in terms of resources) or they were inaccurate or quite often didn't include the actual product count so they weren't in fact all that useful. Elasticserach however is very fast at creating these filters for display to the end user, furthermore filtering with these buckets is extremely fast due to the way we handled the searching internally, this gave us a win in the performance box and a win in the user experience box a win win if you will!!

Putting it all together

So you're probably asking yourself why does all this matter, it matters in a number of ways, here are a few to mull over:

1. End user experience first and foremost a website should deliver the very best experience it can if it wishes to retain a user base this is a no brainer!
2. Faster IO means better scalability it stands to reason that if you can process a request faster then you can process more requests per second.
3. Google / other search engines give a ranking boost to faster websites once again this is a no brainer and a widely accepted fact that faster website rank higher in the SERPS and we know that higher rankings mean more traffic which in turn gives greater opportunity for sale.
4. Beating your competitors this touches on the first point a little but simply ask yourself, if you have two websites and one gives you a faster and less bandwidth intense experience then which one would you return to?