how to reduce dynamic processing

Regardless of all the WordPress caching and speed optimizations you’ve applied, it’s all for nothing when it comes to the cases where your site still needs to launch dynamic PHP processes to serve some types of page requests. These dynamic processes use up more CPU and memory than do the cached requests and sometimes that can cause slow processing, whether on the front-end or in the WordPress admin.

Here’s the most common cases where dynamic processing is used:

  1. Accessing pages in the WordPress admin panel (Backend)
  2. Backups and malware scans when completed by a plugin (Backend)
  3. Frequently when parts of your website update *after* the page has loaded, like if you’ve got a currency switcher for your WooCommerce products or a cart that exists on every page which updates automatically when you add products. (Frontend)
  4. The first time a page of your site is loaded after the cache has been cleared (this is when it generates the static cache file, which loads much faster). Details on this in our how to speed up WordPress guide. (Frontend)

If in any of these cases you find page loading to be slower than roughly 3-5 seconds, then dynamic processing is the culprit and the steps here will help!

How long it takes to load a page dynamically varies depending on what your site is used for. As an example, WooCommerce sites with certain types of Extensions will require more CPU power to operate, particularly in the WordPress admin.

Why does dynamic processing create slow performance?

There’s two facets to dynamic processing that can cause slow performance:

  1. Weight: The ‘weight’ of each PHP process and how long it takes for the server to serve any given page. For example, if you have a database table with millions of entries and WordPress or one of its plugins needs to scour through those entries on every page load, it might take 10 seconds to do that. Therefore you end up with 10 second wait times to load those pages; and meanwhile the process on the server is chewing away at available CPU resources.
  2. Concurrency: The number of simultaneous PHP processes you can run. Most shared hosts limit your dynamic processing capabilities to between 1 and 5 PHP processes that can run simultaneously (we allow between 2 and 5, depending on the CPU weight of your site). Consider the example above where it takes 10 seconds for a process to complete. If you get more than 5 visitors to your website in under 10 seconds, then those additional visitors will need to wait for one of those 5 processes to complete before they can serve the next visitor.

We need to either stop those dynamic processing requests entirely, by caching or blocking them, or make them lighter weight.

One thing to keep in mind is that if your processing is very slow because of a heavy process, enabling caching may only be delaying the inevitable. Using better optimized code, which we describe how to do in this article, is still going to be your best option for top performance. Or, if you opt not to remove or replace the poorly performing site functionality (plugin, theme, custom code, etc) then upgrading to a VPS to get more CPU power may be your only viable option.

Even with just 1-5 dynamic processes, if your site is cached, uses well optimized and carefully selected code/plugins/themes, and is on good quality WordPress hosting, you can still reach over 1,000 simultaneous visitors with minimal impact on your server resources.

If you’re experiencing a problem where a page suddenly takes longer than 30 seconds before it even begins loading content, there’s often an underlying problem with WordPress or the hosting configuration that you should resolve before proceeding with any of the steps in this guide. Click here for help troubleshooting issues with suddenly very slow loading pages.

We’re first going to proceed through the most common offenders that take up dynamic processing slots as identifying these and implementing a specific solution for them will frequently resolve any performance issues without having to dive too heavily into the code and exhaustive troubleshooting process.

Here are 7 ways the most common types of dynamic processing can be quickly curbed:

1. Discouraged Plugins and Themes

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 your site performance is to do as it recommends. This usually means either changing the configuration or disabling/replacing the offending plugin or theme.

2. Cache Preloading

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.

3. Backups and Malware Scans

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.

4. Disable Custom 404 Pages

Because of the way WordPress rewrites work, every 404 request must be handled by a PHP process dynamically. You can use Google Search Console to identify 404s, or you can identify them using your server logs.

Here’s a few potential solutions:

  1. Eliminate the 404s 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.
  2. Make your 404.php file lighter weight. Details on how to do this can be found in the link to our discouraged functionality article in the note above.
  3. Disable dynamic processing of static file 404s. Add the following code to the very top of your .htaccess file to accomplish this. 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!
# 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]
# END 404 Load fix

5. Global WooCommerce Cart

The best thing you can do in this case is to disable your dynamic cart display, if your theme has such an option. We describe a couple of themes and plugins that do this in the discouraged functionality link above, however there’s bound to be others that we have yet to discover.

6. Run WP-CRON Less Frequently

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. The guide is preferred.

7. Slow Database Queries

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

Large Tables: 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 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.

For example, recently we saw a WooCommerce Scheduled Actions table 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';

How to detect dynamic processing

If you’ve completed the tips above and you believe dynamic processing is still affecting your site performance, then I’m afraid the rest isn’t going to be quite as simple to troubleshoot, but you can use the following steps to help determine what’s happening.

Note: this can be a tricky troubleshooting process. It requires you to carefully analyze your website’s logs and use your browser inspector tool in order to find the cause for your dynamic processing problems. We’ll show you how to analyze your logs in our guide to viewing logs with Plesk, but there’s no guide to using the web inspector tool in your browser (at least not yet), so please check your browser’s online documentation if you need help with that.

Monitor your website’s access logs while loading a slow page or while the site load is heavy to see if there’s a commonly accessed page that’s being requested by visitors that is the one triggering the PHP processes. You might have to make note of a number of pages and try them all out yourself to see which might be not-cached. There’s a couple of handy tricks in that article to help you narrow the results down to the specific requests that require dynamic processing and are likely to be generating higher load.

Open each page URL that you made note of with your browser and examine it using your browser’s web inspector. Go to the Network tab to see all requests and how long they took. You may need to refresh the page to fill this tab with the page’s requests. You’ll also see an option near the top of the network tab that allows you to filter by resource type. Here’s the two most important ones for analyzing dynamic processing:

Filter for Document/Doc and select the page itself (called / or /page-name/ if not the homepage in the list of resources). Some hosts – like us – will indicate in the headers (one of the tabs here) whether or not the page was served from cache. Here you should also see the time it took to load the core page itself (excluding all other resources the page loads). This number is your Time to First Byte or TTFB. More on this below.

Filter for XHR requests (these are AJAX or async requests) and see if any of them are loading data from your domain. XHR requests to external domains will not affect your server’s dynamic processing, so these can be ignored. Select each one and use the data/request/response tabs on the right to determine what data is being sent/received. This should pinpoint what plugin or theme function is being used here to generate dynamic data.

Here’s how to analyze these results:

  • If you find that it’s not loading the page from the cache, then you’ve found your problem: try to identify why the page isn’t loading from cache.
  • If you find it’s loading XHR dynamic content from your domain, then that’s your problem: figure out how to stop that dynamic request from occurring.
  • If the page is cached, then the TTFB you found on the initial page load is an indication of how fast the web server engine can provide that cached file (and also how far away you are from the server physically). If you’re on the same continent (or close) to the server, this value should be around 200ms or less. If you’re on the other side of the planet, then this value should be around 300-500ms. Just about anything higher than 500ms for cached pages usually means your server just can’t keep up.
  • If the page is not cached, then the TTFB you found is an indication of how fast the server can prepare your page’s PHP (plus the distance between you and the server, as described above). For non-cached pages the quicker this processing can occur, the less CPU intensive it is and the better your site will scale, so reducing this to something like 500ms to 1s by following the steps below to lighten a heavy PHP process is strongly recommended.

If you think you *need* that dynamic request for functionality you require on the site, then I’m afraid your site is likely going to need more power, like migrating to a VPS, or if you already have a VPS, purchasing an additional CPU core and/or more memory.

How to lighten a heavy PHP process

Unfortunately the only way to resolve problems with a heavy process is to determine what code is causing the heavy weight and remove it. This is a cumbersome process of disabling plugins, changing themes, and testing the results after each change. Once you determine the source of the issue, you then need to find a lighter-weight replacement option for that theme, plugin or custom code. You will likely just have to try others until you find one that doesn’t weigh down the page load time.

Tip: if you have been able to lighten PHP processing by finding the responsible code and removing or replacing it, and this code was affecting performance site-wide, then it’s likely that it was also affecting the performance of some functionality that we recommended you disable above. For example, global WooCommerce carts might now work more efficiently and could be re-enabled without detrimental effect.

Want us to do the heavy lifting for you?

No problem! Most performance optimization and repairs are covered by our $149 flat-rate, though some can be a bit more involved. Please reach out today and we’ll get started on speeding up your site!

About Jordan Schelew

Jordan has been working with computers, security, and network systems since the 90s and is a managing partner at Websavers Inc. As a founder of the company, he's been in the web tech space for over 15 years.

Leave a Comment