WordPress.org

Ready to get started?Download WordPress

Ideas

Selective Plugin loading

  1. zafrir_ron
    Member

    12345

    Plugins loading is one of the performance big factors,
    some installations has lots of plugins.
    all active plugins are loaded for every page request!
    some of these plugins needed only in admin area, some needed only for specific page/s only. but all of them loads for every request, some with overhead in loading, some even add unwanted content to pages that not related to the plugin. some of these plugins are HUGE.

    I've put a hack to selective load of plugins depend on the page request:
    1. by default all plugins loaded
    2. array of selective plugins with include/exclude sub arrays, each contains a list of reg exp of the URI request.
    3. in wp-settings.php in the plugin loading loop just added a one condition test for each plugin calling a validation function if to load it.

    I suggest to add to the plugins main page to each plugin an include/exclude input boxes to put comma separated, uri (or page numbers...) regular expression.

    My code is working like charm on my site. Its very small, very efficient and the performance improvement is great (depends on how many extra plugins and their size loaded to unwanted pages).

    And in the future plugin development codex should include directions and logic/option for each plugin to "tell" where should it be loaded (admin only plugin, page plugin...) as default values for the new added fields. to avoid the need of the users to find out the proper settings.

    Posted: 4 years ago #
  2. Justin Tadlock
    Member

    12345

    I'm not sure how I feel about this from a WP perspective because all the tools are already available. Plugin authors just need to use them.

    For example, if my plugin is only needed on the post editor page of the admin, then that'll be the only place it should be loaded. WordPress has plenty of hooks for things like this.

    A better idea would be educating plugin authors on how to properly load things only when they're needed.

    Posted: 4 years ago #
  3. iwanttobelieve
    Member

    12345

    This is also a concern of mine. zafrir_ron, would you mind sharing your script? Thanks!

    Posted: 4 years ago #
  4. Mark / t31os
    Moderator

    12345

    I agree with Justin, the hooks already exist, if a plugin loads needlessly in areas it shouldn't then the plugin author is at fault by not correctly coding their plugin.

    Plugins authors should be better educated on how to properly write their plugins so they do not load needlessly.

    Posted: 4 years ago #
  5. zafrir_ron
    Member

    12345

    Guys
    I agree with you and wish that all plugin writers will follow your coding advice.
    I checked some of the heavy plugins (e-commerce) for example and other plugins that has some kind of assumptions that when its installed. All the WP application pages must use it.
    All initializations, options, script loading, css are loaded for every page call.

    I bet that 99% of all plugins do some activity on every wp page call,
    I never saw a plugin that checks at first line if it has to load itself for the current page call and quits.

    please run wp-tune and add hooks for timing of your plugins to see the loading times.
    I also saw bad coding on many plugnis...I'm not sure I want to start this education proccess...
    I reduced my loading time to 1/2 just by this script.

    My suggestion is adding a very simple admin - plugin page field for every plugin, to control it's loading.
    since it will become a part of the plugin header data, it will make the education, since every plugin writer will have to think what to put in these fields in order to make his plugin work.

    Posted: 4 years ago #
  6. Justin Tadlock
    Member

    12345

    Loading PHP on every page isn't going to hurt things. Where sites get bogged down is usually because of slow (or too many) database queries or too many CSS/JS files loading. It really isn't WordPress' job to control these things. It's the plugin's job.

    since it will become a part of the plugin header data, it will make the education, since every plugin writer will have to think what to put in these fields in order to make his plugin work.

    I, as a plugin developer, would just tell WP to load my plugin on every page, bypassing the need for this. Then, decide on my own when/how things are loaded.

    It'd pretty much be impossible to make something like this as well given that plugins are loaded prior to knowing which page is currently being viewed. Plus, the plugin might need to check something very late in the process before deciding to load or not load something. A generic feature like this would only serve as a roadblock that fixes no issues.

    Posted: 3 years ago #
  7. iwanttobelieve
    Member

    12345

    If you include more than 30 plugins and load them on every single page, you could have a memory usage of more than 48MB for every page. You can cut that down to 20MB by not loading unused plugins. 48MB isn't going to hurt? I don't think so (to think of 20 visitors clicking on a blog post at the same time).

    If a plugin does not make use of the init action, I think we can safely include it later on template loading, where most functions, like is_page, etc. used to determine which pages we are on are ready for us to use.

    It's the plugin's job.

    Sure, but as zafrir_ron said, there's next to none plugin doing so. Until they do something, we need to load them in a better way I suppose.

    Posted: 3 years ago #
  8. Justin Tadlock
    Member

    12345

    I'll go ahead and save some of you the trouble of arguing — I'm about 99% sure this will *never* happen. It is not the responsibility of WordPress to control third-party plugins. If you want to see changes in any particular plugins, I recommend that you talk to the individual plugin authors.

    If you include more than 30 plugins and load them on every single page, you could have a memory usage of more than 48MB for every page. You can cut that down to 20MB by not loading unused plugins. 48MB isn't going to hurt? I don't think so (to think of 20 visitors clicking on a blog post at the same time).

    First of all, 30 plugins? Are you seriously using 30 plugins on a single site?

    Thirty average-sized (in terms of file size) plugins still wouldn't hurt. Heck, they wouldn't come close to the size of the files WordPress itself loads. If you're going to run 30 heavy plugins, sure. But, a little common sense has to happen when it comes to the end user as well.

    Nevertheless, don't pick a single sentence out of a paragraph to try and argue. If that's all you're seeing, then you completely missed the point.

    If a plugin does not make use of the init action, I think we can safely include it later on template loading, where most functions, like is_page, etc. used to determine which pages we are on are ready for us to use.

    init is only one action before template_redirect. Nevermind the tons of other hooks that plugins use. It's obvious you need a better understanding of the sequence of action and filter hooks WordPress executes in its loading process. This simply, without a doubt, will not work.

    Sure, but as zafrir_ron said, there's next to none plugin doing so. Until they do something, we need to load them in a better way I suppose.

    Thus, breaking 100s or 1,000s of plugins in the process. You could simply find a better plugin or ask the plugin author if it's possible to make some changes.

    Posted: 3 years ago #
  9. iwanttobelieve
    Member

    12345

    Thirty average-sized (in terms of file size) plugins still wouldn't hurt. Heck, they wouldn't come close to the size of the files WordPress itself loads. If you're going to run 30 heavy plugins, sure. But, a little common sense has to happen when it comes to the end user as well.

    Nevertheless, don't pick a single sentence out of a paragraph to try and argue. If that's all you're seeing, then you completely missed the point.

    Yeah and you are doing exactly the same thing. You can search on Google for some users having problem with maximum PHP memory usage issue using WordPress (with some plugins of course). I never said that WordPress should include selective loading in the core, did I?

    It's ok. Discussion ended.

    Posted: 3 years ago #
  10. enailor
    Member

    12345

    Re-Opening Discussions! And getting back to the original topic!

    Personally, I would love to see something added to WordPress that allows the user to control this better. Maybe it is a hook or filter that the theme programmer can use, or another plugin that gives you overall control. But this is a problem.

    Justin, I respect the hell out of your opinions! However, the problem is that your idealistic approach simply isn't being done. For example, 2 of the most popular plugins I use often are the Next-Gen Gallery (by Alex Rabe) and Calendar (by Kieran O'Shea) plugins.

    NextGen Gallery by default adds 2 additional stylesheets, 2 additional JS files (+1 inline script), the RSS feed link and another meta tag. Calendar adds a very long < style > tag section. Both of these are loaded on every page, adding to code bloat and slower load times. I don't need these on all pages, but I have no way of controlling this.

    Should the plugin author give us an option? Yes. Should I make changes to their code to handle this? No.

    I think the general user should be able to have finer control over where things are added, even when the plugin author does not provide it. In my example, I am using 2 of the most popular plugins found on WordPress. If I add a contact form plugin and a lightbox plugin, I can add even more bloat on pages not using these features! Now I am only talking about 4 plugins!

    Yes, plugin authors should give us more options in this area. But having a fail safe way to circumvent this is a good idea for WP users. Again, I totally respect the opinions of awesome WP contributors like Justin, but sometimes practicality should override ideology.

    zafrir_ron : You claimed to have a workaround on this.... Would you mind sharing with us?

    Posted: 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.

  • Rating

    12345
    26 Votes
  • Status

    This is not a core suggestion