Reduce `core` bundle size

[mshustov]

Parent issue #95853

Core bundle size is critical for performance because it's loaded on every page and delays all other plugin initialization affecting perceived UI performance.

There are still lots of options to improve Core bundle size, just a few ideas:

• move @kbn/std to kbn-ui-shared-library Move more Kibana packages to UI shared deps #95894
• move @elastic/safer-lodash-set to kbn-ui-shared-library Move more Kibana packages to UI shared deps #95894
• remove node-libs-browser from the build,
  • caused by nodejs util usage

    kibana/src/core/public/fatal_errors/get_error_info.ts

    Line 9 in e91d0d4

    import { inspect } from 'util';

  • also by our implementation of Sha256 that uses Buffer and requires the polyfill (~40kB):

    kibana/src/core/public/utils/crypto/sha256.ts

    Line 77 in 4681a80

    private _block: Buffer;

• more aggressive lazy loading for UI components:
  • fatal_errors
  • overlays
  • notifications
• investigate whether we can reduce the size of css built-in by css-loader

We don't aim to abide by the 100KB limit set for plugins. The limit bundle size value for Core should be investigated as a part of this issue.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

Not sure we can gain much with async loading UI components in core, as we are just delegating to EUI which is already a shared dep.

E.g

• overlays/banners

The banners service is already lazy loading react-markdown

kibana/src/core/public/overlays/banners/user_banner_service.tsx

Line 27 in 4584a8b

const ReactMarkdownLazy = React.lazy(() => import('react-markdown'));

The rest of the UI component in UserBannerService is mostly using EUI. Async loading that would be a gain of less than 1kb.

• overlays/flyouts

Only UI component here is

kibana/src/core/public/overlays/flyout/flyout_service.tsx

Lines 121 to 128 in 4584a8b

	render(
	<i18n.Context>
	<EuiFlyout {...options} onClose={() => flyout.close()}>
	<MountWrapper mount={mount} className="kbnOverlayMountWrapper" />
	</EuiFlyout>
	</i18n.Context>,
	this.targetDomElement
	);

As @elastic/eui is already a shared dep, we wouldn't gain anything here

• overlays/modal

Same, UI comp is only a passthough to EUI

kibana/src/core/public/overlays/modal/modal_service.tsx

Lines 199 to 204 in 8126488

	render(
	<i18n.Context>
	<EuiConfirmModal {...props} />
	</i18n.Context>,
	targetDomElement
	);

• notifications/toasts

The toast list is currently rendered during startup

kibana/src/core/public/notifications/toasts/toasts_service.tsx

Lines 49 to 61 in 4584a8b

	public start({ i18n, overlays, targetDomElement }: StartDeps) {
	this.api!.start({ overlays, i18n });
	this.targetDomElement = targetDomElement;
	render(
	<i18n.Context>
	<GlobalToastList
	dismissToast={(toastId: string) => this.api!.remove(toastId)}
	toasts$={this.api!.get$()}
	/>
	</i18n.Context>,
	targetDomElement
	);

Changing to lazy load would force us to adapt the code to only render the component when a first toast is actually received.

Also GlobalToastList is a very thin wrapper around EUI's EuiGlobalToastList, and as @elastic/eui is already in the shared deps, the gain would only be of a few bytes.

So I don't think we should do anything for overlays/banners

• fatal_errors

Opened a PR #96020 to try that one. I guess the gain will be negligible too, but waiting for CI.