English version of my old post WordPress es un CMS lento - 2014
More than once, I've found myself in the middle of the debate: Is WordPress slow? Well, it’s not much of a debate when the only answer from those attached to WordPress is that there are sites with many visits using it, and their performance is optimal. These people seem to forget that even the bubble sort algorithm Bubble sort performs well for excessively large samples if "run" on a powerful machine. However, this doesn't mean it is necessarily an efficient algorithm (it is not, in fact) if we consider its computational complexity. The same thing happens with WordPress. Given the same amount of information, it will require a much more powerful hosting than other CMS. Not only that, but as we will see, WordPress is inherently slow whether it has a lot of information or not.
This does not mean that WordPress is bad. Nothing could be further from the truth. Just like in a car, speed is not everything. The same goes for the world of CMS. In fact, many of my web projects are built with it. However, each project is different, and therefore, you need to choose the best tools wisely, not out of attachment.
Since I am a technical person, my arguments will be based on technical aspects. Particularly when I understand that WordPress is slow due to its design. I invite anyone who disagrees to leave a comment with their reasoning.
All in One Table
When designing a database schema for a web project, the question arises whether to go for practicality or efficiency. In the case of WordPress, they chose practicality and grouped posts, custom posts, resources, and versions all in one table: wp_posts. This action has the advantage of simplifying the code and searches (although this is another issue WordPress struggles with, as we will see in another post), but on the downside, it drastically reduces WordPress's efficiency. Some examples to make this clearer:
If we have 500 posts, and each has four different revisions (the current one and three more), it’s as if we were dealing with 2,000 posts.
If we have 500 products with WooCommerce, and each has a featured image and four in a product gallery, it’s as if our CMS had to handle 3,000 products.
If we have a small website with 35 pages and 35 menu items, whether external or internal links, our content manager would work as if there were 70 pages since each menu item counts as an entry or page in our CMS. This might not seem much in this example, but it shows another factor influencing performance.
If you have 500 products in four languages, your WordPress will act as if it were handling 2,000 products.
Now, let’s go to a real-world example in summary: If you have a website with 500 products, each with a featured image, four product gallery images, and a PDF with technical information, and the site also has a blog with 200 entries, each with their respective featured images. If your site also supports three languages and is set to allow only two revisions per post, WordPress must search through over 5,500 items every time it queries your database. I am ignoring other factors like menu items, pages, and custom posts. Advice:
Limit the number of revisions to two or disable them completely:
// Limit revisions to two:
define('WP_POST_REVISIONS', 2);
// Completely disable revisions:
// define('WP_POST_REVISIONS', false);
- Delete all revisions from time to time. You can do this by running the following SQL query:
DELETE a, b, c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';
Be frugal with the images on your website. Do not add images to your CMS that you will not use.
Avoid having multiple menus unless they are essential. Remove menu entries you do not intend to use.
If you have no other option, because your client insists on using WordPress for medium or large projects, try creating auxiliary tables to lighten the load on wp_posts as much as possible.
Your WordPress Has Alzheimer's
WordPress seeks flexibility at any cost, even at the expense of speed. Maybe because in its beginnings, it was only going to be a blogging system, and in that case, so much flexibility wouldn’t cause much damage. However, when we started using it as a CMS, performance problems caused by this flexibility began to arise.
Let me give you some bad news: your content manager has Alzheimer’s. It forgets everything from one request to another. You will have to repeat each time which custom posts, sidebars, or menus you are going to use. There is no other choice because it forgets. That's why, for example, if you want to add an entry to the admin menu, you will have to tell it every time it is to be displayed. Yes, it offers enormous flexibility, but it forces PHP and the CMS to process the same thing repeatedly, resulting in a loss of efficiency. The same thing happens with plugins, which is why many plugins can significantly slow down your website. It’s not because of the plugin system itself (which is magnificently designed and programmed) but because plugins have to declare the same information repeatedly, forcing WordPress to go through them entirely with every request.
A performance-focused CMS would have done it differently. For example, by having the theme declare during activation what sidebars, custom posts, or other elements it needs. This CMS would register this information and adjust internally. The same could be applied to plugins. But, as mentioned earlier, such an approach would significantly reduce the CMS's flexibility, which for WordPress is not desirable.
Tips:
Limit the number of plugins.
Choose minimalist themes that only have what you need.
You might be advised to use a cache plugin; I don't. Only use one if your website is extremely slow and do so with caution. I will discuss this in another post (edit: now available: Don’t Use Cache Plugins with WordPress, but basically, it’s because you will disable all of WordPress’s internal workings based on hooks. That is, you will force WordPress to work in a way that is not intended.
Everything Always Available
As almost everyone knows, WordPress started as a blogging system based on a previous system. It wasn't designed for large projects, which is why its design leaned toward simplicity. No classes, just functions. As with any design aspect, this doesn’t have to be a bad thing (just ask those using desktops built with GTK) unless you are looking for flexibility. Then, the headaches begin.
If you come from the PHP world, you might be surprised that with WordPress, you don’t have to use "require," "include," or "namespace." This is easy to understand: WordPress always loads its entire arsenal of libraries. Yes, always, whether you use them or not. When you combine this with its memory issues, well... that's a lot of code to read with every request. But, of course, this is all for flexibility. You can use a core function without having to include a file that might change names or paths tomorrow.
Since PHP 5.6, there is full support for function namespaces. Maybe this is a solution for WordPress. But in that case, they will have to make the difficult decision of breaking backward compatibility. I don't know what they will do.
There’s nothing you can do to improve this, as it’s part of WordPress’s design. All you can do is your part: make sure your code doesn't follow this path. If you decide to do so, here are my tips:
- Create anonymous functions for "actions" that are nothing more than includes to external files where you keep your code. This way, if the action never triggers, PHP won’t have to parse all the code. Example:
add_action('admin_init', function() {
include(__DIR__ . "/zones/panel/init.php");
});
add_action('admin_menu', function() {
include(__DIR__ . "/zones/panel/menu.php");
});
- For widgets, shortcodes, and filters, use classes with namespaces. Also, make sure these classes are instantiated using autoloading.
// It's better to use: spl_autoload_register()
function __autoload($classname) {
$file = str_replace('\\', DIRECTORY_SEPARATOR, $classname);
include_once(BASE_PATH . $file . '.php');
}
add_shortcode('block', array('myShortcodesBlock', 'load'));
//... my other shortcodes, filters, and widgets...
In summary, we have seen that WordPress's design principles are simplicity and flexibility, but in a way that sacrifices efficiency. It is essential to understand that no development tool is good for everything. If someone presents it that way, they are either misleading you or selling you a Swiss army knife that is good for nothing.
WordPress struggles with speed, but for showcase websites, this is not something to worry about. However, for websites where the business relies on the web, or for sites with a lot of traffic, alternative options should be considered. Still, if we choose WordPress for its ease of use and flexibility, we must compensate by investing in good hosting, being very careful with the selection of plugins, and using a high-quality theme tailored to our needs.
Top comments (0)