The Code Company has been working with WordPress at scale for almost a decade. During that time, we’ve been asked to work on or build high-scale ecommerce sites. It is our view, that while WooCommerce is a suitable platform for certain types of ecommerce stores, we have found that it is not suitable for high scale ecommerce sites.
For the sake of clarity, this post is talking about websites that are purely ecommerce and receive a significant number of orders (50+ orders a week or more).
At its core, WooCommerce uses WordPress’ flexible database structure, which is a great way to rapidly build out data models, but fundamentally fails when it comes to any kind of complicated querying or manipulation of that data.
The WooCommerce project are addressing this and are moving towards a custom data structure that will scale significantly better; however, it’s hard to asses just how well this will work until it’s completed.
One risk that still remains, is how third-party developers or WooCommerce addons work with this new data structure. Meaning, that using one poorly written plugin has the potential to significantly degrade the overall performance.
As an example, WooCommerce currently fails to be able to do any kind of reporting. We’ve seen first-hand large database clusters being brought down by a store administrator forgetting to set an end date on their report.
No single ecommerce product is going to be able to do everything for everyone. But given WordPress’ flexibility, WooCommerce suffers the same fault; that anyone can write a plugin that alleges it can do anything.
One of the perceived benefits of using open source software to a business, is that you can leverage these third party addons to prevent having to write your own. This sounds great, but rarely works as well as expected. For a number of reasons we consider this a problem;
This is a common problem with WordPress as well as WooCommerce. That open source software is free, so therefore running an ecommerce site on WordPress and WooCommerce is going to be cheap. The reality is, there is a lot of work required to make WooCommerce scale and handle large spikes of orders and traffic, along with being as flexible as other DIY tools.
Running an ecommerce site is very different to running a content based site, no longer can you rely on CDNs and services like CloudFlare to handle spikes of traffic to your site.
Ecommerce is higly dynamic, and even building a high end AWS cluster can often be a never-ending game of cat and mouse. The cat and mouse game can greatly be exaggerated with some of WooCommerce’s known race conditions (we’ve seen product launches result in 100’s of products oversold).
Ecommerce traffic can be highly unpredictable so all the planning in the world is pointless unless your infrastructure can scale, and the application has been fine tuned to work.
Out of the Box, WordPress & WooCommerce present a fairly complicated administration UI. Especially when you bring in all the third party plugins and services that are almost essential to have a fully functional ecommerce presence.
The above screenshot is all too typical of a WordPress/WooCommerce backend. That’s not to say it can’t be fixed, but there is an entire UX design project required just to make the administration interface workable.
Some of that would work would involve overriding how plugins by default set their navigations up etc, which can mean it’s a permanent job to maintain.
Over the last couple of years, The Code Company has had the opportunity to really deep dive into a bunch of WooCommerce projects of all kinds of shapes and sizes.
At the end of the day, just because you can make WooCommerce work at significant scale doesn’t mean you should.
The main exception to this argument is where you need to deploy a large ecommerce store and need 100% control over presentation layer, database and custom business logic alike.
However, that is then a WordPress and WooCommerce vs Magento vs Shopify vs et al argument – that we do not pretend to be experts in and defer to others.