[data] Reduce data bundle size

[lukeelmers]

Currently the initial page load bundle size for the data plugin sits around 1MB. We made an initial effort to lazy-load the UI components which saved about 200k, but that was really the only low-hanging fruit in the plugin.

Since data contains so much code and is relied on by nearly every plugin, there's only so much we can practically do to reduce the bundle size further, but should consider if there's anything we can do to improve the situation.

One particularly significant chunk of the bundle size comes from data.search.aggs, which registers a bunch of default agg types during setup, representing dozens of modules (about 97 modules that comprise ~20-25% of the bundle size). es_query is another chunk that feels larger than it needs to be.

There are a few options for improving the situation, but one thing in particular I thought might work for aggs is making registries async where possible.

In the case of aggs, we could cut out the majority of the bundle size if retrieving aggs from the registry was an asynchronous operation. Currently a function is added to the registry in setup, which when called during start will return the underlying agg type. If retrieving the aggs were async, then each of the registered functions could lazy import the modules only the first time they are needed.

A similar approach could be applied to other registries which have a number of default items added during setup (eg field formats?): If you register an async provider function for a registry item, and make the registry itself async, then you can lazy load items inside the provider only when they are needed.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[streamich]

Similar issue: #95859

[streamich]

Some ideas of how to shrink the data plugin's initial .js bundle from looking at the composition screenshot.

1. Make field formats and aggregations load async. But make the formatting still synchronous or possibly reactive. That would remove those parts:

2. Expression functions are async, we can load esaags expression function using dynamic import, it would remove:

3. Not sure why we have those huge CSS files, but we can structure CSS such that it only loads with React components that all can be loaded lazily, unless those are some global CSS theme (in which case they probably should not be part of the data plugin):

4. Maybe Index Patterns should be its own plugin?

5. For KQL we can probably do the same as for field formats/aggregations—load them lazily but still expose synchronous or reactive API:

[lizozom]

#103530 should split out the whole es_query folder into a package.

[vadimkibana]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

[lukeelmers]

By closing this issue, does this mean we no longer intend to take steps to reduce the data plugin's initial bundle size? Or are we saying that we have already exhausted the low-hanging fruit, and any further improvements would require a much larger investment?

"closing due to inactivity" doesn't help me understand if the <100k bundle size goal is still something we intend to achieve. If there are places the bundle can be reduced without too much effort, I'd vote to keep this open since bundle size continues to be a big challenge across Kibana (regardless of how much activity this issue has gotten). But if further improvements are unrealistic at this point, then I understand closing the issue.

cc @tylersmalley