bbPress.org

Yes its 0.1 seconds comparing a WP wihtout any plugins, and WP+bbpress. Its not negligible, I expect websites to respond within <0.5 seconds for a good user experience.

There are 2 issues (which apply for most other WP plugins):

1. The impact of bbpress gets bigger with more plugins enabled, because activated plugins have hidden dependencies to each other.
Lets say we have another plugin with 0.1 seconds slowdown, and bbpress with the 0.1 s, the total site slowdown is usually greater than 0.2 s. By using the add_filter() API, plugins actually call each others functions.

2.) Each request bbpress includes almost 40 scripts, the PHP parser parses all of them (lets take opcache apart), and then does not generate a single byte of HTML. So its just wasting server disk I/O, and CPU.

1) It is true and I’ll show you some more precise benchmarks on this for a concrete example. Take the filter bbp_map_meta_caps, it’s within a filter recursion, where the filter fires it self again. The recursively fires 4 times with bbpress only. Now if another plugins does the same, it could get up to 16. Plugin run times include each other through the filter api. In worst case you can’t just add them to each other, they bias by some non-linear function that is definitely not O(n).
Your point is true, that you can’t blame a plugin for being slower in conjuntion to others. But, you as a developer, should avoid that other plugins can slowdown your own plugin, by minimal intrusion into the WordPress plugin API. And bbPress does not have this minimal intrusion. Of course it is a big software product, but there is high potential to conditionally hook into WP only on pages it needs to.

2) No its not completely irrelevant. I wasnt clear enouh here, I’m not referring to file count, but yeah -how you said- file size or LLOC. Were not talking about vulcanizing scripts. You’re right, the PHP interpreter got very fast and it should not matter, but consider:

a) Only the inclusion of bbpress main file makes PHP allocate about 600 KB. Thats a lot, considering 0 output bytes. And this happens on every request, every REST.

b) Think about who runs a WordPress site, not people that have a dedicated high performance server. Usually its a webspace in a VM. These systems can power hundreds of sites, so the webserver does not just read 500 files at the same time, but lets say 10000. This lowers the chance to find the same PHP code in some cache between subsequent requests. The code size per request starts to matter here.

b) It is a style thing, I dont want my programs to load 1MB code without using it. And yeah, there are many plugins that just follow WordPress style to include everything, but this does not mean it is a good style to follow. Unfortunately, there is no well known code metric that covers this. WP was created in darker times of PHP, without autoloaders. Why do we have them now? I dont get it why so few plugins properly use them, it takes a day to refactor your plugin and another to test.

bbPress is not doing bad. It could just be more minimal if the forum is just a smaller part of your website. I dont expect 25 plugins to allocate 0 memory, but I expect 25 plugins not to clog my dashboard and frontpage, where I do not want them to load. I want them to do what they are supposed to do on specific pages within the front- and backend.
Its true that woocomerce is the worst.
I could optimize it though. It only loads on the shop frontpage, on the checkout page, on product pages, specific ajax actions and REST endpoints. The cart can be XHR, or one can keep on loading the plugin once a cookie is set. This technique makes the wp-admin dashboard fast too.

(I’ll back with the benchmarks)

@johnjamesjacoby thats not true, WP has a “polyfill” for autoloading, and actively uses it on every request, even on legacy PHP 5.2. So autoloading is officially supported.

These are first numbers about the impact of an unconfigured bbPress on a fresh WP server response time:

PHP 5.6 + opcache : +35 % SRT
PHP 7.0 + opcache : +28 % SRT
PHP 7.1 no opcache: +28 % SRT

As you can see bottleneck is loading and parsing. Note that the speedup of opcache in PHP 7 is about 6x.