How to detect and reduce dynamic processing with WordPress

Take a look at our discouraged plugins, functionality, and themes list. If you find your site is using one of those themes, plugins, or configurations, then the quickest way to avoid having to dive into the nitty-gritty of site performance analysis is to do as it recommends. This usually means either changing the configuration or disabling/replacing the offending plugin or theme.

Many hosts use server-wide object caching systems like Redis or Memcached. These utilities store the object cache contents in system memory for optimal performance, however they’re also known to be problematic for shared hosting in terms of the security of data access between sites in a Redis or Memcached data store system.

A great alternative solution is a disk-based Object Cache (assuming you’re hosted on SSDs without IO limits, like our hosting). We use and recommend Docket Cache for this purpose. Simply install and activate and you’ve got Object Caching! Even better, it’s got numerous tweaks within its settings to better optimize performance of various areas of WordPress that can slow down dynamic processing.

You’re probably wondering: how does this differ from the other caching solutions we recommend like WP Rocket or WP Super Cache? Those static page caching solutions are essential for dramatically improving speed of front-end non-dynamic pages. However when you absolutely must use dynamic processing, like for a WooCommerce cart, a Membership system, or a Learning Management System, the best way to optimize performance for those types of requests is to optimize the queries that WordPress makes to the database and the processing of the response.

Object caching solutions like Docket Cache accomplish this by intercepting WordPress database queries after the first request’s response has been provided and processed. They then store the fully processed response on disk so that subsequent requests for the same data don’t need to hit the database and PHP unserialize functions at all. SSDs and their built-in hardware caches are often as fast as system memory, making Docket Cache a fast and simple object caching system.

Docket Cache is essentially a totally transparent caching solution for dynamic processing: simply enable the plugin and it does its thing!

If your static caching plugin for WordPress has a preload function, then when it runs, it’s querying your non-cached pages all at one time. It will run when you first enable it, and every time your clear your site cache. Directly after the cache is cleared, the preloading spider kicks in and crawls every single page of your website, generating a request each time.

Each page request creates a dynamic process on the server to generate that page’s cache file such that subsequent visits to the page are much faster. You’re probably wondering, “isn’t this a good thing? Because then all the caches are ready to go for visitors to see the site super fast…” Well, you’re right! But you’re also using CPU resources unnecessarily (as the page requests aren’t even for a real visitor) and you might also be sacrificing page load speed during the time that the caching engine is preloading your cache files.

The solution: disable preloading. Yes this means that the *first* visitor to view those pages will take a bit longer to load — to work around this you can load your high-traffic pages manually yourself with a separate browser to generate the cache file — but it also means that the preloader isn’t wasting CPU resources (because the request it makes isn’t even for a real visitor) and slowing down the site during preload.

On at least some of our shared servers cache preloading is detected and blocked due to the waste of CPU resources that could go towards real website visitors. If you upgrade to your own VPS, then this block can be removed upon request as the CPU resources are yours to choose to waste.

When using WordPress plugins to manage backups and malware scans, you’re also choosing to use one or more of your precious available PHP processes to handle those backups, scans, or both.

Disabling any backup plugins and malware scanners or setting them to run far less frequently (and particularly in off-peak hours) will help resolve this problem.

We’ve long considered both of these tasks as items that should be handled by the host’s control panel and not by a plugin for this exact reason. Why should you potentially sacrifice website performance simply because you want to have backups and a malware-free site? If you host with us, we include the following server-side services with all hosting plans:

1. Free weekly malware scans with reports available within Plesk under the Imunify360 button.
2. Free incremental backups to the cloud storage provider of your choice.

Since they’re run at the server level, neither of these processes affect your PHP process limit! Simply configure your backup to connect to the cloud service of your choice and you won’t need either security or backup plugins for WordPress.

Because of the way default WordPress rewrites work, every 404 request must be handled by a PHP process dynamically. You can use Google Search Console to identify 404s, your browser console’s network tab (details below), or you can identify them using the server logs.

The best possible solution to 404s being sent to dynamic processing is to eliminate all 404s you find by either adding a redirect to the correct file URL or removing the link to the file from the site’s code so there is no more 404 error.

If you need a faster solution, or the requests generating 404s are trying to access URLs that aren’t real, you can either make your 404.php file lighter (details on how to do this can be found in the link to our discouraged functionality article in option 1) or disable dynamic processing of static file 404s. Add the following code to the very top of your .htaccess file to disable dynamic processing of 404s. You may need to extend the list of file extensions to your particular scenario. Note: we do this for you when you Host your WordPress website with Websavers! If you’re hosted with us this isn’t necessary.

# BEGIN 404 Load fix
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} \.(jpe?g|png|gif|js|css|ttf|xml|map)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* - [R=404,L]
</IfModule>
# END 404 Load fix

You have a cart icon somewhere on the site that displays the number of items in the cart or other cart details on every page. If the theme or plugin that provides your global cart provides the option to disable it, the best thing you can do for performance is disable the dynamic cart. We describe a couple of themes and plugins that do this in the discouraged functionality link in option 1.

If you require the global cart display then one of two things needs to happen. Either you need more CPU to power the site, which might mean upgrading to a VPS, or you need to determine if there are plugins contributing significantly to the cart display load times and remove them specifically or report the performance issues they create to the developer.

To resolve this, you can either add define('WP_CRON_LOCK_TIMEOUT', 900); to wp-config.php or follow our guide to help you to force your WP Cron to run less frequently and more reliably. Using that guide is preferred.

Slow database queries can be caused by two major categories of issues:

Inefficient Queries: if a plugin or your theme is poorly coded, then it will run queries on your database that are inefficient.

Large Database Size / Table Size: If a database table gets filled with hundreds of thousands or millions of entries, then requests that use that table can become slower.

The simplest way to detect database performance issues is to install and activate the Query Monitor plugin, then load the slow page. The Query Monitor plugin will add itself to the bottom of your page and show an exhaustive list of all database queries, identifying which ones take the longest.

If you’re seeing page loads take 5 seconds, but Query Monitor shows all database queries complete in less than 1 second, then I’m afraid this isn’t your problem and you should use the steps below in the “How to detect dynamic processing” section to try to identify the real source. However, if Query Monitor does show database queries roughly matching up with your page load times, then you’ll be able to use it to identify either the plugin causing the problem or the table that’s too large.

If the table it’s querying is too large (typically > 500k entries or larger than 50-100MB, but this will vary depending on memory caching configuration and IO performance), you can use the phpMyAdmin button in Plesk to view the table and sift through the entries. You might find many of them are old data you no longer need (and which you can delete using phpMyAdmin), or that a plugin is creating duplicate data due to a bug which needs to be reported to the developer.

Note: before you proceed with any changes to the database, be absolutely sure to take a backup. Here’s how to create a database dump with Plesk.

The queries listed below can be run easiest from within the phpMyAdmin button in Plesk — once in phpMyAdmin go to the “SQL” tab, paste your query in there and press run.

If you opt to delete from the database, make sure to optimize the table after you have done so by going to the Operations tab > table maintenance > Optimize. It will appear to do nothing for a while and the optimization process may take a few minutes.

Common Examples of massive database tables

Example 1: Massive WooCommerce Scheduled Actions table. We recently saw one with over 2M rows, seemingly due to Square sync logging. It appears WooCommerce doesn’t trim this table over time and so we ran the following query in phpMyAdmin’s SQL tab in order to clear out all completed actions:

DELETE FROM wp_actionscheduler_actions WHERE status = 'complete';

Example 2: Orphaned PostMeta. If your wp_postmeta table is massive, you may have orphaned data. The first query below will show you how many orphaned rows there are, and the second one will erase them (permanently, so be sure to take a backup).

-- List all orphan rows from wp_postmeta
SELECT * FROM wp_postmeta
LEFT JOIN wp_posts ON wp_posts.ID = wp_postmeta.post_id
WHERE wp_posts.ID IS NULL;

-- Delete all orphan rows from wp_postmeta
DELETE wp_postmeta FROM wp_postmeta
LEFT JOIN wp_posts ON wp_posts.ID = wp_postmeta.post_id
WHERE wp_posts.ID IS NULL;

Example 3: a bug in WP Rocket’s Reduce Unused CSS (RUCSS) feature causes duplicate data for the RUCSS feature to be logged to the database every time one of the CSS or Javascript files generated by a theme or plugin would change. This resulted in the table wp_wpr_rucss_resources becoming huge: as large as 5GB in the case of one of our client’s sites. The best way to resolve this is to truncate the table in phpMyAdmin (under the Operations tab) daily until WP Rocket is able to resolve the bug.