WordPress can be slow for many reasons, including adding extra plugins, themes, the hosting environment, or even just because PHP is slow. In this post, we’ll examine what causes WordPress to be super slow, and we’ll look at some ways that we can improve WordPress Core to make it run much faster. This article is targeted towards other Software Engineers, and is not meant to help the average user speed up their WordPress installation.
WordPress is Slow – Why is That So?
Sloppy Code – Clean code naturally lends itself to maintainability, code reuse, and ultimately faster code. While the same code could be written in a sloppy fashion, and perform just as well as its clean code equivalent, humans can understand clean code much more readily than sloppy code. If a method is over 100 lines long, it’s much harder to reuse that method. However, a developer can reuse several smaller methods and reduce repeated code in multiple places. If the repeated code ever changes, you need to change that code all over the codebase.
In short, developers may forget, or not know, that a piece of code is already in the codebase. They may choose to rewrite the code in a different way, and perhaps one version of that code will run faster than the other version. That slows down a portion of the website.
Globally-Scoped Code – When you write clean code, you use namespaces and classes within those namespaces. OOP works beautifully for keeping the codebase clean, and therefore faster. The WordPress team did an excellent job in developing some classes, however the classes are not namespaced, and therefore, it’s not possible to properly autoload the classes. That leads to the problem of manually loading the classes.
WordPress uses helper functions to manually load the classes, and those helper functions are globally-scoped. Plus they use globally-scoped variables which are very difficult to track down. Where is $wp_object_cache defined in this helper function? I couldn’t find it by searching the repository on GitHub. However, I did find it’s declaration inside the helper function which apparently references a class below all of those helper functions. Like I mentioned above, autoloading would remove the need to have helper functions loading classes. WPCache::get() could be a perfectly valid call instead of using wp_cache_get() It’s even the same length. Cache::get() is even shorter, and use could just use the “WP” namespace!
So, to sum it up, the codebase is bloated with hacks that really need to be replaced with proper coding techniques. The cleaner the codebase, the easier to read, and the less code duplication, and ultimately the faster the site will run.
HTML in PHP Files – WordPress has HTML inside of its PHP files. HTML files should be in their own directory and use a template engine for processing them. The processed templates are then cached by the engine, and that leads to a website speedup. Plus, templates are meant to be easy for designers to edit without any knowledge of PHP. Template engines have loops, variables, and more. WordPress has a team for designers who would probably love to have a quick way to manage their templates. With all of the templates in their own directory, perhaps as a parent theme, they can easily change every little bit of front-end code strewn throughout the codebase.
Personally, I like using Smarty, but if there’s a better template engine for the project, I’m all for it. The goal is to make it fast, maintainable, and clean. Heck, with an autoloader, we can make it easy for the end user to select a template engine based on what their theme supports! A refactor should use Composer to manage vendor libraries.
For our friends who use shared hosting, and who cannot use the console, we can make a script to run those updates right from the admin area. Composer is just a phar