One major gripe I have with WordPress is the default wp-cron.php implementation. If you are familiar with how WordPress uses wp-cron.php by default, you may want to skip ahead to the next section of this article.

What is wp-cron.php & How does it work?

The file wp-cron.php is the portion of WordPress that handles scheduled events within a WordPress site. Anything that has to do with scheduling posts or publications and really anything date/time oriented is governed by the wp-cron.php file.

In order for wp-cron.php to work properly, it needs to be executed frequently, but no more than once per minute. However, the default behavior does not require you to set up a real system level cron job on your server. Instead, it uses a piggyback method on every incoming request. When a request comes into the site, WordPress will generate an additional request from itself to the wp-cron.php file over HTTP(S). That sounds pretty innocuous, right?

Why is the default wp-cron.php behavior a nightmare?

The default method works perfectly fine on a small site with very few visitors per hour.  However, when implemented on a medium or larger site or even a site that is being scanned by bots (which is very common these days), this means you get twice fold whatever traffic you are currently handling. It becomes a rudimentary DDoS attack against yourself. This is because the cron is being executed multiple times a minute using an HTTP request. The HTTP request generates additional overhead by having to generate, negotiate and establish the connection over a network socket. It even impacts the effective capacity of your underlying web server. This solution does not fare well in most situations, and honestly, it should be removed as the default behavior due to its propensity to be abused or turned into an attack vector on a server just from regular traffic.

Check out the Full Article on Medium.