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
Bugs – Some plugins are bug-ridden and of those bugs, some are because of how WordPress Core handles the plugin. The issue tracker is riddled with bug reports, and a refactor will be the perfect opportunity to smash some bugs. While we won’t go surfing the issue tracker to fix them, we will fix them if we notice that something is up when we rewrite the code. Clean code will help us see errors a whole lot easier. Some of those bugs might increase the speed.
Other Odds and Ends
A refactor will allow us to increase security much easier, perhaps even giving people the option of moving WordPress outside of the root directory of their site. A refactor will allow designers to design more beautiful templates in a directory all of their own with code that they can more easily understand. A refactor will allow the WordPress Core team to rapidly develop new functionality using WordPress’ existing functionality while keeping the code running bleeding fast!
Grady Booch says, “Clean code reads like well-written prose.” Heck, WordPress’ tagline is “Code is Poetry” which shows that WordPress cares about clean code. Let’s clean up the codebase and make it poetic.
Here’s What I Propose
I’d like to get started on a refactor of WordPress because that’s something that excites me, and because it’s something that will benefit a massive user base!
W3 Techs - Web Technology Surveys
Source: https://w3techs.com/technologies/details/cm-wordpress/all/all
The Big Idea
There are several main objectives for the project.
- Clean Code – Clean code is our primary objective. Without it, everything else will fail.
- Speed Up WordPress – The mission is to make WordPress incredibly fast. I won’t go over everything again. You know what that means.
- Speed Up Development – Cleaning up the codebase will consequently make development easier in the long run. Designers will find it easier to change the HTML that once was in the PHP files.
- Security – Security is always a priority in every project. We need to keep/make the codebase [more] secure.
Timeline
- Dream Team – Put together a “Dream Team” of volunteers who share the vision, and who understand how to architect a proper system for WordPress. I’ll start off as a Project Manager just until we all understand how we plan to get the job done. As with every good team, we need to work together to realize the vision, and ultimately I want the team to make decisions together. While Project Manager, I just want to make sure that everyone is on the same page, and that everyone has only one person they need to listen to to avoid confusion.
- Plan It Out – Everything starts with a plan. To make the best use of our time, we need to figure out exactly how we need to refactor the code. The refactor is going to take a while, so we’ll probably do this project in sections over the course of months to a year, or perhaps even longer depending on how well things go. Remember that everyone is a volunteer on the project, so we all have our day jobs. In this stage we may also create some kind of block diagram. [UML?] That way we understand how the new system will work. However, if we use a PHP framework, then that’ll be unnecessary.
- Get Crackin’ – At this phase we’ll have ordered the items in our ToDo list in order of priority. The first iteration should get the basics in place for the WordPress Core team to build off of the new infrastructure right away. That will save time when porting future versions of our project into the main codebase. Every item in the ToDo list will get completed in this stage, and we’ll release in sprints.
- WordPress Core – At the end, the whole project will be managed by the WordPress Core team. Perhaps some of the team will become part of the WordPress Core team.
The Dream Team
To pull off this beast of a project, I’d like to put together a team consisting of around 10 people with the following skills. I’ll screen each candidate to see what kind of code they’ve written in the past, and to see if they’ll be a good fit for the project. Ultimately the team will interview new candidates.
- Understand the WordPress codebase
- Can write clean code at the same skill level or better than mine
- Has passion for the project
Proposed Tools
I have a list of tools we could use to make this project a success. As we put together the Dream Team, we’ll all decide on the best tools for the job.
- Slack – WordPress Core uses Slack, and Slack has been an awesome tool for teams to keep in touch. I’ve used it frequently, and probably the Dream Team does too.
- Trello – Trello is an awesome ToDo list that works extremely well with Agile Software Development. I propose that we use it for collaboration on this massive undertaking.
- Laravel – Laravel is a PHP framework in its own right, and it has most of the tools that we need already. It has the MVC design pattern, clean code, its own template engine, caching, and the largest PHP framework user base by a long shot. Site Point conducted a survey in 2015 on the most popular PHP frameworks, and Laravel came out on top… by far. In 2016, Laravel continues its dramatic uptrend according to Google Trends. We can leverage Laravel’s user base to provide more options to WordPress users, including through the use of Laravel plugins.Using a framework will dramatically shorten the time to deploy our changes.
- Symfony Components – The Symfony PHP Framework offers multiple components for reuse. If WordPress is to stay its own “framework,” then we could use still use Symfony components.
- Smarty – Smarty is an excellent template engine for PHP. If we don’t use Laravel’s built-in template engine, we could use Smarty. If we do use Laravel, it’s faster to go native. Smarty is one of the oldest template engines for PHP, and it’s still the most widely used. It’s something the Design team should consider.
- Composer – Composer is a dependency manager for PHP. It’s something that probably every developer has, and it will allow us to easily autoload 3rd-party software and never commit those dependencies to our own repository. They should only appear in the archive with the production WordPress code.
- Git – Yes, WordPress mostly uses SVN. However, personally I prefer Git. It’s as simple as that. 🙂 We’ll probably just vote on what people feel the most comfortable using. I’d like to use GitHub so that way we can all publicly track changes that we make. GitHub is much more popular than any private SVN tracker. Outside developers will love the fact that they can see who did what and when, as they’ll see how active we are. Like I said, it’s mainly a personal preference, though there are small benefits for everyone. Plus, it looks good on your resume.
Social Contact