- Why is my WordPress so slow?
- Why aren’t my caching plugins helping speed up my website?
- WordPress isn’t so slow when hosted on other servers, fix your servers
If you are experiencing a slow WordPress, or these statements seem familiar to you or your customers, then you are not the first, and guaranteed not to be the last person to feel that your WordPress just isn’t up to the task of being fast. There is a reason for this, and I will henceforth call it the WordPress exponent:
Website slowness = WPWP
What this means is basically: The bigger your WP, the faster your website will become slower.
“Big WP”?
The definition of a “Big WP” has nothing to do with the amount of posts or traffic. A website with 1 million posts, 1 million images and millions of visitors is not necessarily considered a “Big WP”. All that is counteracted with a proper server setup, proper caching and a decent theme.
The size of your WP increases with the amount of work the server has to do whenever WordPress loads up, and this is one of the biggest weaknesses of WordPress: The server load racks up pretty fast.
Typical sources that increase the size of your WP include, but are not limited to:
- Adding an extra plugin
- Using a badly written theme
- Using a badly written plugin
The way these result in a large workload for the server requires an explanation of how wordpress works.
Saving a new title
Imagine sitting in your control panel, your are editing your latest blogpost (newsarticle, page, whatever..). You decide to fix a simple typo in your title, and proceed to fix it and click the nice big blue “Update”-button. You have now done your part, and WordPress takes over to perform your desired action: changing the title of your post. Should be fairly simple to swap a few letters in this modern age of computers, right?
What would normally happen next:
- The request, containing your new title and other bits of data, is sent to the server.
- A database connection is created
- Safety first, your login and more is verified (are you a user that is allowed to save this title to this website in this situation?)
- The text of the title is updated in the database
- Redirect back to editing and show “Success” or “Failure” message.
Success!
What WordPress -actually- does next:
This list is a bit extensive, but pay attention to #8, #9 and #10. This is necessary information to explain a slow WordPress.
- The request, containing your new title and other bits of data, is sent to the server.
- WordPress starts preparing it’s basic configuration and creates a connection to the database.
- WordPress now starts loading itself; namely the core files, the bits and bobs that it needs to function.
- Then it loads up many large(!) functionfiles and classes (like the user handling, wpdb, rest api..), starts a timer, checks if it has been installed,
- …Tries to normalize variables across any platform (WP can run on a vast array of systems)…
- …Hooks up a load of actions and filters that will sanitize, normalize, prepare and load more stuff at a later time….. (not looking at your submitted data – yet!).
- .. Starts loading the built-in plugins and widgets, User is verified at some point.
- Plugins are loaded (which means that each of them load fully and RUN)
- Theme functions.php is loaded (fully, and RUN)
- WordPress triggers its more important actions, like after_setup_theme, init, and wp_loaded
- ???
- Post is saved – profit (?)
- Redirected back
And that is just scratching the surface
Ok:
“Inefficient”
Claim: “WordPress has existed for a long time and learnt a lot about how to verify everything properly, of course there will be a lot going on for even a simple operation!”
True, and WordPress does probably perform many good sanitations, normalizations and security-related stuff. The size of this code is not the main problem. This is not the focus of the size of your WP.
The #8 problem, layer 1
WordPress loads all your plugins when you save your title. It also loads all plugins every time someone visits your frontpage (except if cached properly), and every time you click “edit” on your post. In fact, every request to WordPress will result in all plugins being loaded fully, and their code will be run.
The more plugins you have, the more code will be loaded fully and run on every single request made to WordPress, that includes showing a page, doing an ajax-request (wp-ajax.php), saving your post, anything and everything!
The #9 problem, layer 2
Your theme is loaded when you want to save your title. Just as with plugins, your themes functions.php is loaded fully on every single request made to the WordPress.
Why on earth would you need your theme files to put your new title in the database? It’s not going to be shown during the “save the title” request, and theme files are ment to show your content!
WordPress seems to not care about this. This “concept” of a problem is present throughout the entire WordPress architecture.
The #10 problem, the final layer
Remember this?
#10: WordPress triggers its more important actions, like after_setup_theme, init, and wp_loaded
During #8, and possibly #9, all those plugins are loading their files and running… They are hooking up their actions to “init”, “wp_loaded”… They are preparing all sorts of filters and registering post types, adding custom fields, clearing transients, sending emails, running wp-cron.php etc.
Every plugin adds more work for the server when it needs to be loaded, and in the process adds a WHOLE LOT of later work for the server when WordPress starts triggering the huge queue of actions at the end of the load.
Plugins are also able to run their own actions, or even rerun wordpresses own actions. They are quite creative and will spare no cpu-cycle to make sure their work is done.
Plugins may also add filters to parts of actions, which means that each plugin added may actually increase the amount of work all other plugins have to do before reaching the end.
An actual example
Say you have 20 plugins in your WordPress. If 1 of those plugins add 1 ms extra loading to all the other 20 plugins you have through some filter or action, that just means 20ms extra load time. No problem.
But:
If all 20 plugins add 1ms extra load to the other 20 plugins, that’s suddenly 400ms extra load! That’s nearly half a second extra, and is not uncommon. This is one common problem in your slow WordPress.
Then you add one more plugin that accidentally 1ms to all the other plugins, and now you have 441ms extra load.
What if one of those plugins accidentally more than 1 ms to the other plugins? The number starts racking up very fast.
This potential problem is present in every single request made to wordpress, in all situations and all locations, on all WordPress installations, no matter the hosts claims about “our wordpress are faster”.
I need my plugins and my themeforest theme with the fancy stuff and..
No you don’t. Stop hoarding plugins and get a proper theme. Install WP fastest cache and keep it active. By simply using common sense, your slow WordPress might speed up significantly!