Speed up slow WordPress backend
A fast WordPress frontend can be easily accelerated – frontend caching, on demand script loading,our world’s fastest WordPress theme – here good results are often possible quickly.
In the WP admin, on the other hand, the unembellished result of a lack of optimization of numerous plugins is often shown. The administration – especially in online shops – then costs more time, which is at the expense of productivity.
In this article, we use a concrete example to show how a single function massively degrades the speed of the dashboard – and how the problem is solved.
Here we describe a way of error detection, analysis and correction
See how you can also apply our method to your website – so that you can find the cause and solution yourself even if you have a new problem.
Step 1
Overview & Narrowing
For performance, we test the loading time of the WP admin dashboard, i.e. the overview page that is displayed when /wp-admin/index.php is called.
With the developer tools of the browser (e.B. in Chrome) a waterfall view of the loaded content can be displayed.
These can be found in the tab “Network” – the loading time of the HTML document is particularly important here, as it shows how long the server needs to calculate the page. You can also filter the result by entering “index.php” in the filter (see screenshot).
The ideal loading time is less than one second – this is not always realistic depending on the setup, after all, a lot has to be calculated live in the WordPress dashboard – a complete caching, as is often possible in the frontend, is not mapable in the WP admin.
Nevertheless, the optimization also affects their own customers, especially with shops – because they are logged in at some point as part of the checkout – and many caching plugins usually deliver a non-cached page for logged-in users – so the goal should be that the website is both logged in and loaded quickly as a guest.
Low load time = Lower bounce rate. Their WP admin performance also often affects logged-in users, but also API queries, such as shopping cart Ajax widgets.
Important: From now on, please work on a staging environment and always think about backups – because in the analysis the website is taken apart on a test basis.
If the initial load time was recorded before any optimization, you should not deactivate individual plugins and check if something improves – deactivate all plugins immediately.
After that, activate plugin by plugin and record the loading time for each change – so you can see the effect of each plugin.
The rule of thumb: The more plugins, the slower WordPress becomes.
Often only a fraction of the functions of individual plugins are used – here it may be worthwhile to research more tailor-made plugins or commission us to combine functions in an individual plugin – often half a dozen plugins or more can be saved.
An optimized WordPress website usually gets by with an average of 30 plugins – installations with 60 or more plugins are becoming less and less manageable from a maintenance point of view.
Step 2
Cause & Optimization
Poorly optimized plugins or design flaws often lead to ticking time bombs.
In the example of the screenshot, it becomes clear that WooCommerce increases the loading time enormously – from 2.7 seconds to over 50 seconds.
We’re not talking about a niche plugin here – WooCommerce has over 5 million active installations.
An extremely long loading time usually indicates the database as a bottleneck.
With the free plugin Query Monitor, complex database queries are suddenly visible – since the plugin itself generates load, it should only be active during the optimization work – then it can be deactivated and deleted again.
On the screenshot it becomes clear that above all a WooCommerce database query is responsible for the high loading time, more precisely: the method get_top_seller() from the WC_Admin_Dashboard class.
This can be quickly narrowed down to the WooCommerce Status widget, which is only used in the WP admin dashboard.
Obviously, the underlying data query is enormously time-consuming and thus leads to long loading times up to timeouts on the dashboard page in some shops.
Thanks to the disable WooCommerce Bloat plugin, the widget can be easily deactivated – problem solved.
In contrast to simply hiding the widget via the Screen Options, the widget is then actually no longer loaded and the loading time of the dashboard normalizes again.
result
Optimize by omitting
Performance problems are in most cases a sign of a lack of optimization – especially database queries are rarely optimized, although caching results or reducing queries/complexity promise the best performance improvements.
Of course, you can also simply book a stronger hosting package – after all, a lot helps a lot.
But optimizing at the software level not only means more sustainability,but also a more cost-effective solution.
The example with the WooCommerce widget shows only one particularly extreme case – as a rule, the page load time is gradually increased with each activated plugin.
Therefore, proceed step by step in the optimization and try to reduce the number of plugins required. Historically, plugins are often still installed that you no longer need.
There are also numerous plugins that promise to optimize the performance of the website by cleaning up the database – for example, WP Optimize. This certainly makes sense and improves the charging time partly noticeably, sometimes only very slightly.
Our recommendation
Check your website’s technology stack and work on the exclusion principle to effectively detect and optimize bottlenecks – disable any feature you don’t need.