Looks like WordPress unnecessarily fire WP CRON on every page load. I'm thinking, instead of having it run on every visit, why not just schedule it to run every 5 minutes via server? I could simply trigger wp-cron.php every five minutes and achieve desired result?
Is there any downside to this?
There is no downside for running WP CRON using the server's cron jobs. In fact this is the recommended practice.
According to Official WordPress Plugin Development Document:
WP-Cron does not run continuously, which can be an issue if there are critical tasks that must run on time. There is an easy solution for this. Simply set up your system’s task scheduler to run on the intervals you desire (or at the specific time needed).
To do this, you need to first disable the default cron behaviour in wp-config.php:
define('DISABLE_WP_CRON', true);
Then, schedule wp-cron.php from your server. For Linux, that means:
crontab -e
However, instead of running it in Command Line (CLI), run it as an HTTP request. For that you may use wget:
*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron
WordPress loads all the required core files, Plugins etc. in wp-cron.php with the following CODE:
if ( !defined('ABSPATH') ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . '/wp-load.php' );
}
So don't worry about WordPress not loading important features.
wget http://YOUR_SITE_URL/wp-cron.php without the addition of ?doing_wp_cron So is one better than the other? What does the addition of ?doing_wp_cron do that the non-version doesn't?
define('DISABLE_WP_CRON', true); disables only that part of the cron process and then calling the cron script with code like: */5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron on the server makes sure cron jobs are executed. Any scheduling Plugin will not even know the difference.
There are a couple of downsides: Firstly, when using wp-cron.php as a cli things such as $_SERVER variables aren't set. People overcome this limitation by using a curl request to wp-cron.php instead.
Secondly, Because WP itself isn't loaded with wp-cron.php; if you use a SMTP mailer plugin then this won't be loaded when calling wp-cron. Again, using a curl call overrides this problem. Curl seems to be the most frequently used method.
However; I prefer to use wp-cli after setting mail settings in postfix and (for nginx) php-fpm config correctly and setting a crontab such as
*/5 * * * * wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1
(List all crons with specific fields in csv format - hook being the name of the cron, next run relative is the time. Strip out ones showing 'now' as next run (ones due now) using AWK, pass that list to xargs to call wp cron event run $HOOK on each cron. )
Using wp-cli loads WordPress correctly (I choose to skip plugins when listing the crons, as code erros and php warnings will screw up the scripted output; but not to skip them when running the cron with xargs, as the cron may need the plugins being loaded)
Hope this gives you some pointers in what to look out for.
I am yet to find a real downside to offloading wp-cron to external service. Being doing this for many years now.
Especially in todays world where you can run applications as microservices.
I use separate Docker containers for each WordPress component - php, web, db, crontab, redis and so on). Having crontab as separate container, calling wp-cron via http using local network, running only when I need it to.
This reduces stress on backend nodes and improves security by having smaller attack surface.
If the developer can't figure out how to do stuff without having to call wp-cron on every page load, heck, this just speaks for inexperience on his behalf. "Leaving it alone", because you don't understand how things work is not a good reason to keep it.
There are many reasons not to disable the wp-cron. In fact, it's nearly impossible to find a use case to do this. It doesn't slow your site down, and it is used for things you may not be aware of.
Many plugins use the WP-Cron to schedule things. They may become confused if you turn off the scheduler.
There is a proliferation of tutorials on this subject because it is confusing, and because it doesn't do much to your site when you disable it. What it will do, is cause a headache to the dev who has to fix the mysterious problem it creates in six months.
Also, the WP Heartbeat fires every 15 seconds in the admin area, solving this issue for 99% of the people who think they have it.
