Wordpress as a CMS has its die-hard fans and fierce enemies. Personally, I worked with it for several years and I have formed an opinion about it. I agree that with its help, in a fairly short time, we can build practically any kind of project - from a simple business-card website, through ecommerce, all the way to an API. From the user's perspective, it has a very friendly interface, it is trivially easy to install, configure, and manage, and the community is huge and active.

But these are not the reasons why Wordpress is so popular today. Wordpress's success hides behind its flexibility. We can say that extending it is trivially simple. What do I mean? Plugins? Yes and no - we need to look deeper.

Hooks

To understand well what stands behind Wordpress's success, we need to look at the mechanisms that govern it. The most important of them is the hook mechanism. Hooks are places in the code that allow programmers to "hook into" any part of the system without having to edit Wordpress's own files.

It is worth remembering that any work in core files of any application should be performed only in special and well-justified cases. Making changes in the main part of the system blocks our access to later updates, because every new update may remove our previous changes. The most important thing, however, is that introduced changes may create security holes in the system and in its consistency.

This mechanism gives a lot of freedom to programmers who create systems based on Wordpress. They do not have to worry about the integrity of the whole system and its security. Subsequent version releases and patches can be installed without problems. Important: a backup is always necessary during work such as system updates, especially a database backup.

In Wordpress we have two types of hooks: filters and actions.

Filters and Actions

Filters are used to modify existing functions in the system. We can use them when we want to change how a function works by adding some functionality to it. For example, we want to add an ellipsis to the part called excerpt.

<?php

function my_custom_excerpt( $output ) {
  	if ( has_excerpt() && ! is_attachment() ) {
		$output .= "...";
	}

	return $output;
}

add_filter( 'get_the_excerpt', 'my_custom_excerpt' );

In the code above, we create a function that modifies our excerpt and "hook" it into the built-in function that then returns it.

Actions, unlike filters, are used to execute our functions at a specific moment during Wordpress source code loading. Actions do not have to accept parameters and do not have to return anything. They can be useful when we want to extend given features.

<?php

function my_custom_script() {
	wp_enqueue_style( 'my_styles', get_stylesheet_uri() );
}

add_action( 'wp_enqueue_scripts', 'my_custom_script' );

In the example above, the my_custom_script function will be called when Wordpress prepares styles and scripts for the template.

Plugins

These two simple features made extending Wordpress functionality trivial. In May 2004, together with the release of version 1.2, a plugin architecture was added to Wordpress, which allowed both users and programmers to write, add, and share their own Wordpress extensions. We could say: checkmate on the open-source blogging systems market. Over time, it turned out that the plugin system, as well as the hook architecture, changed the perception of a simple blogging system into something bigger.

The Problem with Plugins

Plugins in Wordpress have their disadvantages. A plugin is nothing more than a piece of code that is supposed to perform some task within our system. A definition phrased this way does not have many limitations - and that is basically how it looks in reality. Nobody controls the code quality of plugins. Wordpress gives full freedom in this area, in line with its ideals. Responsibility for installing and using plugins is on the site owner. And what if the owner cannot read code? Well...

Actually, I named this paragraph badly. The problem of plugins is the problem of users. A person who installs a new plugin takes responsibility for system stability, security, and speed. This brings us to a simple conclusion - it is better to find a trusted programmer than to do it yourself.

The story of Stephanie Wells and her Display Widgets plugin describes this perfectly. The author of a very popular free plugin sold it to another developer. Her version was fine. After some time, it turned out that the plugin received new updates that downloaded unknown data from a foreign server and sent some data, mostly statistical, from the site where it was installed to external servers. It is easy to guess that such unauthorized data can be malicious and probably does not serve anything good, and we definitely do not want it on our server.

What About Quantity?

Can the number of plugins affect website speed? It can, but it does not have to. It is not always the case that plugins directly translate into how fast a WP site works. Wordpress runs on the server side, so many performance problems related to the CMS itself can be solved calmly by increasing available RAM and CPU clock speed. In addition, plugins that need to perform operations only on the server side will have less impact on site rendering speed.

We have several types of plugins. Plugins can be divided by the area of the application they touch. Depending on this area, they have a greater or smaller impact on website speed.

Backend Plugins

This group includes all plugins that perform operations only on the server side. These may include all kinds of plugins for making backups, moving data, or changing content editors in the panel. They will not affect how quickly our site renders. Possible slowdowns can be solved by maximizing server resources.

Frontend Plugins

Opposite backend plugins are frontend plugins. They have a large impact on website speed because what is supposed to be displayed to the end user depends on them. Examples of plugins from this group include sliders, contact forms, and page builders.

Plugins of this type slow down a site by making additional HTTP requests, creating a large number of database queries, often unoptimized ones, or running additional background processes and additional database writes. Huge amounts of CSS and JS, added to the source code of our page in an uncontrolled way, also have a significant impact. More than once you can encounter libraries loaded from local resources that are practically unused, and yet they still have their weight.

Plugins of Two Areas

These plugins work everywhere. They are plugins that affect the server, the admin panel, and the site itself. In this group we can find firewalls or SEO plugins.

Advertising Agencies

I would not like to put everyone into one bag, but for several years I have seen a trend of websites being created by agencies that do not have much in common with professional programming. The websites and stores they create are often "clicked together" with page builders and generators. And perhaps there would be nothing wrong with that if agencies informed their clients what they intended to do and what consequences it could have in the future. The LowCode / NoCode trend in Wordpress is quite strong, and that is very good. May honesty and courage not be missing in the whole process when telling clients that not a single line of code will be written while creating the site, and that the whole thing may have performance problems. Meanwhile, improving and optimizing the site / application may be more expensive than producing it. And no... a cache plugin is not a solution to the problem, but burying it.

Summary

Another Wordpress plugin? Absolutely, but with awareness of how much impact it can have on stability, security, and speed. Wordpress gives us freedom to use it, but it does not guarantee that irresponsible behavior will always end well.

What do I think about plugins? I think it is often not worth installing something from an uncertain source, even if thousands of people use it. The masses are not always right. I prefer to extend templates myself and create my own simple plugins that do exactly what they were created to do. The number of plugins may not matter for speed, but it can matter enormously. Everything depends on their quality and the area they touch.