Why your CMS is slow (probably)

Most CMS platforms make poor use of resources. This is because, rather than your CMS being one “thing”, it is actually a collection of “things”, each thing made by a different person and none (or few) of them talking to each other.

Every time you add a “plugin” to a website you are adding load as well as code.

Configurations need to be loaded. Data needs to be picked up from the database. Data that has already been picked up might need to be altered or tweaked in some way. Other third-party components might need to be used… the list goes on.

A typical open source CMS with plugins and themes activated isn’t a process that goes from “A” to “B” as rapidly as possible. It’s more like a committee who insist on voting on everything between “A” and “B”, including the manner in which the voting will take place, full terms of reference, and who spend half the meeting discussing nominations for treasurer every week. They do get to “B”, but end up going via “F” because that was the consensus opinion at the time.

Of course, you can always add more plugins to help improve the speed of the site again – caching plugins, content delivery network plugins… the list goes on once more. A lot of these are great… just so long as they are compatible with each other, and all the other plugins you have, and the theme you have, and… the list goes on.

Why your website is slow today but wasn’t last year (probably)

If your website seems to be slowing down, there are four areas to check: Scalability, Concurrency, RTSG, and KUWTJ.


Scalability is the measure of how well a system copes when the size of things (except users) increases.

Imagine launching a website with 100 products on it. Now, jump forward in time and imagine your website is now selling over 10,000 products. Assuming the number of people on your website has remained the same, scalability is the measure of how well (or not) the website copes with having to search, sort, and display this increased volume of product.

Some eCommerce platforms are notoriously poor at scaling up to large product sets. If you are implementing a new site, check with your developer what the largest site in terms of the number of pieces of content or number of products they have handled is.

Fixing scalability problems is hard. You can overcome them by simply increasing your server capacity (we nerds call this “throwing iron at the problem”) but this is a short-term fix. Long-term, you need to find the inefficiencies in the code and fix them, or move to a platform that can handle larger amounts of data.


Concurrency is the measure of how well a system copes when the number of parallel operations (or users) increases.

Imagine launching a website with 100 products on it, getting 100 visits a day, taking 2 orders. Now, jump forward in time and imagine that website still has 100 products on it, but now it is getting 1,000,000 visits a day and taking 20,000 orders.

See the difference? The size of the calculations didn’t really change, but we have to do them far more often and do a lot of them at the same time.

Assuming you have a scalable system then concurrency is often just a matter of increasing parallel capacity in the system – “throw some iron” and get more/bigger servers. However, there can be bottlenecks – certain processes that cannot be parallelised or that have other capacity limitations on them. These problems are harder to fix.

The classic issue that impacts concurrency is database locking – multiple processes all wanting to update the same information (or type of information) in the database and creating an unscalable bottleneck as they all “lock” each other out whilst trying to “lock” the data they wanted to alter. Nasty.


RTGS or “Rose Tinted Glasses Syndrome” is the psychological trick that our brains play on us to make us think everything used to be better than it is now. Yes, we can even get nostalgic about the websites and servers of yesteryear!

Joking aside, it’s important to keep track of things like website loading times over the long term. “Thinking” something is running slower than it used to is not as compelling as “knowing” something is running slower because you’ve got proper analytics behind you.


KUWTJ or “Keeping up with the Jones” is another trick we can play on ourselves.

Your website didn’t seem slow a year ago, but it seems slow now. You check your analytics and the page load time is exactly the same… so what’s going on? Whilst those well documented analytics have ensured you’re are immunised against RTGS, what you might be noticing is not that your site got slow… everyone else just got faster.

Like sprinters who constantly chase shaving even 0.1 of a second off a World Record, the biggest players in the game know that every microsecond counts and are constantly looking to make their systems more scalable, more concurrent, and thus serve more things to more customers more often.

Leave a Reply