Performance Audit 2017: Breakup plugin creation / initialization to avoid long tasks

[nicjansma]

When the boomerang.js package is loaded (with included plugins), Boomerang and the plugins will be sequentially created and init()ialized.

While this initialization work is generally pretty quick, it's all done as one sequential block of execution:

Here's a breakdown of init() time on a variety of devices:

We will investigate ways of reducing the initialization cost in specific plugins, but in general, it might be nice to break up the cost of plugin creation and initialization via something like a setImmediate(). Then it's not just one solid block of code execution.

This could help avoiding Long Tasks on older browsers and less-powerful devices.

[andreas-marschke]

This might be something I've been pondering in the past, specifically when it came to onboarding new developers/users to the project/tool. As it's not always obvious from the outside how each plugin is intertwined with another it may be beneficial to draw or create dependency trees of some sort based on the plugins/instances each of the plugins will need. This way even if a plugin is required for another to work we can defer loading that plugin until it's dependencies are met.

So for example

 BOOMR.plugins.SPA.deps = ["AutoXHR"]

And in BOOMR.init() we'd check which other plugins required AutoXHR and called

setImmediate(function() {BOOMR.plugins.SPA.init()})

As a callback of some sort.