Open wilrevehl opened 3 years ago
I'd be happy to add something like this to the Plugin handbook if you'd like to take a stab at writing up a starting point.
Sure thing. How about something like this:
As you begin your plugin development, beware of leaning heavily on the use of the 'init'
and 'admin_init'
action hooks. These hooks are called on almost every page load. When you use 'init'
and 'admin_init'
hooks to initiate important sequences in your plugin, those sequences may be called repeatedly and redundantly with each page load and AJAX call. This can lead to unnecessary consumption of server resources and slow down your site. To avoid this potential bottleneck, be sure to seriously evaluate whether you need to use either action hook. Most instantiation requirements can be met using traditional PHP Class constructors, getters or similar functional programming approaches. If your plugin has dependencies, review the underlying code of those dependencies to see if it offers more specific hooks related to your requirements. If you determine you absolutely need to use the 'init' or 'admin_init' hooks, adding conditionals such as if( !wp_doing_ajax() )
can greatly reduce your callback being run repeatedly.
Heads up @docs-reviewers - the "[Status] Review" label was applied to this issue.
WordPress speed complaints have long been a thorn in our side. We have been analyzing some complex WordPress sites we host and one aspect which weighs heavily on the php consumption is the use of init and admin_init hooks in plugins. The reason this appears to compound php loads is due to plugins which commonly use AJAX. This often leads to a large volume of init/admin_init calls running repeatedly and rapidly. The WordPress "heartbeat" is a common culprit but many Page Builders are just as likely to lead to the same issue.
The reason repeated calls to admin_init and init hooks lead to PHP spikes is often due to them being incredibly popular hooks to initiate countless plugins in varying degrees. This can especially become a serious bottleneck when a plugin is kicking off a call to an outside API where some sort of remote call such as a curl is being waited on.
We combed through your documentation but could not seem to locate any recommendations to use the function wp_doing_ajax to help alleviate this issue. Obviously every plugin developer would need to stop and consider the implications for using wp_doing_ajax, but I would imagine 90%+ of the plugin use cases could wrap their init/admin_init scripts with
if( !wp_doing_ajax )
and see speed improvements.I hope this perspective is helpful to you and you'll recognize the importance of spreading the word to the WordPress scene about taking advantage of it for the greater good.
Thanks for all you do!