Add code splitting to the client bundles in triggers_actions_ui plugin

[mshustov]

triggers_actions_ui.plugin.js bundle size is 2.7Mb at the moment

node scripts/build_kibana_platform_plugins.js --dist --no-examples --profile
ls -lh x-pack/plugins/triggers_actions_ui/target/public/

This bundle is loaded eagerly whenever a user opens the Kibana app.
We could decrease the plugin size drastically if add code-splitting and lazy loading for the plugin. The most obvious candidates for optimization are UI components used in actionTypeRegistry that could be loaded on-demand.
Related discussion #64179

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[gmmorris]

Picking this up as a time-boxed (a half day or so) investigation to figure out what's causing such an unexpected size and to report back to the team.
We will decide how proceed once we understand where the size is coming from.

[gmmorris]

Looking at the bundle created when building the Triggers UI is primarily made up of 3 "packages":

1. Our actual UI components
2. Lodash
3. Brace (the JSON editor we use)

In the PR I've put together I changed the Email action so that the Params and Connector field components are loaded lazily. Looks like everything still works same as before except the files have been chunked up such that the email components only get loaded when the Flyout is actually rendered.
Repeating this work for all Action and Alert types should make the initial load mildly smaller- about 95k less.

In addition we should be able to lazy load the routes to the alerting UI - this should defer loading about 200k until the user actually navigates into the UI.

All in all once complete - this work should reduce the size loaded when Kibana boots up by just shy of 300k.

I'm going to talk to Platform - as it doesn't make sense to include Lodash, Brace, FP-TS and IO-TS when talking about how big Triggers UI is - as I assume it's loaded by other parts of Kibana too and hopefully we're not loading that for each plugin 😱

[gmmorris]

To see the details for yourself you can use: https://chrisbateman.github.io/webpack-visualizer/

Drop in the attached stats.json
stats.json.zip

[mshustov]

Lodash, Brace, FP-TS and IO-TS when talking about how big Triggers UI is - as I assume it's loaded by other parts of Kibana too and hopefully we're not loading that for each plugin 😱

We are. Only brace is in shared deps atm. lodash is another big guy, but different plugins use different versions, so we cannot alias it.

[gmmorris]

Lodash, Brace, FP-TS and IO-TS when talking about how big Triggers UI is - as I assume it's loaded by other parts of Kibana too and hopefully we're not loading that for each plugin 😱

We are. Only brace is in shared deps atm. lodash is another big guy, but we different plugins use different versions, so we cannot alias it.

Cool, thanks Mikhail.
Any advice on how we could still reduce the size then? Lodash is about 20% of our bundle :/

[mshustov]

I'm surprised that brace included in your bundle. It's used in es_ui_shared plugin, which is shared across plugins. However, I noticed it isn't in your case. Since you import code from src/plugins/es_ui_shared/static which breaks sharing logic.
@elastic/es-ui Could you move es_ui_shared/static to es_ui_shared/public as it's recommended in the migration guide?
@spalger FYI. It's not compatible with the current optimizer logic and can break #64843

@gmmorris we will fix the problem with lodash as soon as update the version. that will allow us to use the same version in the whole Kibana #7537
Meantime, you can use lazy loading for react components in sections and components folders.

[cjcenizal]

@restrry I've created #65301 to track removing the static directory but it's blocked by ongoing work. The soonest we could act on this is probably 1-2 weeks.

[gmmorris]

Cool cool 👍
I've sorted out the sections and components and am just trying to finish off some of the interaction of this with siem as it broke their usage of us (they register React components with us so we can inject theirs into ours where needed).

looking at the es_ui_shared/static issue - am I right that we can't avoid that until @cjcenizal completes the work mentioned above? 🤔

[mshustov]

am I right that we can't avoid that until @cjcenizal completes the work mentioned above? 🤔

yeah, this optimization can wait.

[spalger]

Any advice on how we could still reduce the size then? Lodash is about 20% of our bundle :/

I recommend not using lodash :)