build: optimize webpack code split

[ktmud]

SUMMARY

Give more hints to webpack code split so that vendor scripts can be better extracted and cached. Reduced the overall bundle size from 7.05MB to 4.11MB.

Future plan would be to utilize more async module imports import(...) so that large chunks of code like brace and mathjs can be loaded on demand instead of on page load.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before

Bundle sizes via npm run build -- --analyzeBundle=true:

Visiting an example dashboard ("Tabbed Dashboard" from example testing data) with throttled network:

After

There are more JavaScript requests, but DOMContentLoaded time improved. Note this is also only the initial visit. We expect average load time to improve for future new releases as vendor scripts now have better cache.

TEST PLAN

Make sure CI passes.

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

[etr2460]

Thanks for the work in this space! Was the main focus here only on dashboards, or do we expect to see more optimal webpack bundling across all pages in the app?

[ktmud]

Thanks for the work in this space! Was the main focus here only on dashboards, or do we expect to see more optimal webpack bundling across all pages in the app?

I think another low-hanging fruit is to make brace and mathjs async. Make all plugin registry async can also have potential to be impactful.

[kristw]

Yeah mathjs is quite heavy. I wonder if we could switch to something else lighter.

[kristw]

this may also pull the one-time-use packages (that are not part of core d3) such as d3-sankey d3-cloud

[ktmud]

I'll make further tuning in this space in future PRs.