Performance

Hi, Camilo. Thanks for your interest in Paid Memberships Pro and performance.

We are always open to ways to improve performance. That said, it’s not always easy. WordPress and PMPro are complicated pieces of software being used in a lot of different ways.

For your specific request, that file is about 34kb, only used by admins, and cached immediately by modern browsers. We’re not concerned about reducing the load there vs the downside of not having that JS available when we need it. For e.g. PMPro loads things on the edit post page, other plugins settings pages, some of our add ons need it, third party builders may need it.

There is some more info on this issue here: https://github.com/strangerstudios/paid-memberships-pro/pull/2024#issuecomment-1130057471

It should be noted that compared to your typical WP plugin, PMPro does A LOT of things, and so it is going to need more resources, more DB queries, more memory, etc. In practice, we try to keep our load comparable to other ecommerce and transaction plugins like WooCommerce or Easy Digital Downloads.

We sometimes, e.g. when loading JS files, sacrifice small amounts of performance in order to make things more robust or easier for users and devs to work with.

In some cases, e.g. when exporting CSV files or running searches and complex queries will sacrifice usability and robustness to eek out an impactful performance gain.

If you are scaling a WP site to many thousands of users and posts, the same kinds of things that scale a website in general will scale PMPro. So e.g. if time to first load is super important to you for your admins or probably more likely your end users, there are many ways to hook into how JS and other assets are loaded to cache them optimally for your site. People have lots of different opinions and the optimal solution will always depend on the specific site and setup. Whenever possible, we’d like to make sure that they way we load things (e.g. using the WP core enqueue functions which can be hooked into) is done in a way that people can customize.

Let me know if this answers your questions or if you have other specific concerns. Feel free to search around the issues and PRs on our GitHub repo to see if someone else is already thinking about those things or working on them. There are for sure ways we can safely improve performance that just need a bit more attention and work from us. We have quite a few improvements in these areas coming out in our 3.0 release, dropping soon.

?load files in parts that are not used. wp-content/plugins/paid-memberships-pro/js/pmpro-admin.js is loaded in /wp-admin/plugins.php and in the header, slowing down the entire list of plugins

Just want to add, that is not at all how it works.

If your plugins page is loading slow, its likely due to WP scanning X number of plugin folders header files to get plugin details.

In fact the page is already completely loaded for you in the browser before the browser even knows to make a request for a JavaScript file.

Thus even though your initial point has some validity, your example is not indicative of their plugin causing a problem.

Further there are ample use cases for including a JS file on the plugins page, detecting deactivations of your plugin for example and asking if you would rather enable a “Safe Mode” instead of deactivating is one that comes to and many plugins of this nature offer.

All of that said performance of a plugin is important, but in general no ecommerce/membership plugin is “performant” by any measure, this is simply due to the enormously dynamic environment that can’t benefit from page or full query caching.

Your better off throwing more resources as hosting than squeezing out 1% more performance from a single plugin’s JS files or 1 extra query etc.

The reason is mainly because of diminishing returns, that 1% of 1% means nothing when you later install Plugin X & code snippet Y, or even update Z to existing plugins/themes/core, but permanently faster hosting doesn’t care about that.

Just my 2 cents.

Thank you for your feedback @danieliser.

As there hasn’t been any updates to this topic from the original poster, we will be changing the status to resolved.