[Observability] Optimize initial load bundles

[tonyghiani]

📓 Summary

When loading Kibana on the browser, the plugin architecture loads an initial js bundle file typically named <plugin-name>.plugin.js , which performs all the necessary registrations so that any other plugin can use shared logic with different ownership.

When loading any Kibana page, even an unaccessible page, we transfer a minimum of ~5.5 Mb of compressed resources, including any optimization performed at build time such as tree-shaking, code minification etc, resulting in a minimum of +20 Mb uncompressed resources for the browser to process on the user machine.

The JS bundle files represent a ~90% (5 Mb) of the total transferred resources.

• The JS *.plugin.js files represent ~30% (1.5 Mb) of JS transferred resources.
• The JS *.chunk.<integer>.js files represent ~28% (1.4 Mb) of the total transferred resources.
• The JS kbn-ui-shared-deps-*.js files represent ~38% (1.9 Mb) of the total transferred resources.
• Other core JS files represent ~4% (200 Kb) of the total transferred resources.

Of all the JS code transferred to the browser on the first load, only ~41% is executed, meaning almost 60% of it needs to be parsed by the browser without even using it.

Ideally, JS *.chunk.<integer>.js files represent chunks of code that should be loaded asynchronously only when necessary to load specific features (visiting an app page, loading a registered alert, etc.).

Their presence on the initial page load means we are sometimes splitting code into multiple chunks and immediately loading them even if not necessary.

Important

Re-organizing the lazy-loading around this file might change slightly the *.plugin.js files, but should give us a huge opportunity to cut ~25% of all the loaded code on the first visit for many Kibana features.

If we also detect an opportunity to lazy load more features, it implies a potential size reduction of the *.plugin.js files too.

Another important data: kbn-ui-shared-deps-*.js files are the biggest code chunks sent to the browser, and only ~50% is used on initial load, reaching ~60-65% after browsing into multiple apps. There might be an opportunity to detect multiple libraries that don’t need to be immediately bundled.

Observability bundling issues

A deeper investigation into the Observability plugins implementation spotted some critical insights:

• ~24% (1.2 Mb) of the total transferred JS code is from Observability plugins
• APM loads the biggest async *.chunk.<integer>.js file in Kibana, which represents ~16% of all the transferred resources.

Following here is a list of potential optimizations we can perform in Observability to reduce the impact of our JS bundle.

Tasks

Preview Give feedback

1. [APM] Optimize initial load bundles #191600
   Team:obs-ux-infra_services apm:performance bug performance +4
   
2. [ObservabilityAIAssistant] Optimize initial load bundles #191601
   Team:obs-ux-logs +1
   
3. [Infra] Optimize initial load bundles #191628
   Team:obs-ux-infra_services +1
   
4. [Dataset Quality] Optimize initial load bundles #191602
   +0
   
5. [Exploratory View] Optimize initial load bundles #191608
   Team:obs-ux-logs +1

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[thomasneirynck]

For visibility, the same problem exists elsewhere also:

• [Dashboard] Async chunks of control-plugin are loaded on listing page #189679
• [ML] Async bundles are loaded on each page #189755

[tonyghiani]

Closing as sub-tasks are completed.