[Fleet] Reduce bundle sizes

[jfsiii]

Goal

Aim for individual bundles under 250k uncompressed.

Why

Spending a long time parsing/compiling code can heavily delay how soon a user can interact with your site. The more JavaScript you send, the longer it will take to parse and compile it before your site is interactive.

-- Web Fundamentals docs

Reducing the uncompressed size of JS (in total & per-file) greatly reduces the work for the browser and provides a better experience for the user. There are variables like network & CPU speed but, generally, sending 1 500k bundle is worse than 2 250k or 5 100k bundles.

We're currently loading JS that's not strictly required. e.g. we load all plugin JS used anywhere when the overview page is hit. Ideally, we'd load less JS but we can at least make smaller chunks of work for the browser. Less JS might come from these changes or might happen later.

Current status

/app/ingestManager loads ~275kb compressed or 1.8MB parsed JS in production (e.g. cloud staging)

The plugin entrypoint ingestManger.plugin.js is about 400k

With ingestManger.chunk.2.js roughly half of that and an uncompressed size over 1MB

What's in the bundles

1. Generate a stats.json file via node scripts/build_kibana_platform_plugins.js --profile --focus=ingestManager more info
   * --dist gives is what we'll send to users, but it loses a bit of detail about the source, so I omit it while iterating on approaches
2. Put that in a tool like
   * https://chrisbateman.github.io/webpack-visualizer/
   * https://github.com/webpack-contrib/webpack-bundle-analyzer

How move dependencies into another bundle/chunk

TL; DR: Lazy load with await import() Use React.lazy or similar approach on client side. We should eventually have a standard way of doing this, but we don't need to come up with one before we start. More at Keep Kibana fast

Analysis & options

ingestManager.plugin.js 385k

stats screenshots

• 70% of the bundle is two dependencies: esprima (50%) and js-yaml (20%)
• Assume it's from

  kibana/x-pack/plugins/ingest_manager/common/services/full_agent_policy_to_yaml.ts

  Line 6 in ad5c0f5

  import { safeDump } from 'js-yaml';

• One option is below, but I don't know if await fullAgentPolicyToYaml(string) is reasonable/feasible for all consumers

- export const fullAgentPolicyToYaml = (policy: FullAgentPolicy): string => {
+ export const fullAgentPolicyToYaml = async (policy: FullAgentPolicy): Promise<string> => {
+ const { safeDump } = await import('js-yaml');

ingestManager.chunk.2.js (chunk.1 in dev) 1.1M

stats screenshots

• 45% is from three dependencies d3, react-use, react-markdown
  • d3 is only used in one component. Can make this individual component lazy and/or any of the parent components which call it
  • I believe the same is true for react-markdown
  • react-use usage docs say our this should work

    kibana/x-pack/plugins/ingest_manager/public/applications/ingest_manager/index.tsx

    Line 8 in f5b1fae

    import { useObservable } from 'react-use';

    but changing to import useObservable from 'react-use/lib/useObservable' worked locally for me
• 20% (400k) is because the dependencies for each public/applications/sections/ingest_manager component are in the same bundle.
  • Switch the overview page to lazy-load the individual Integrations, Agents, etc section

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[jfsiii]

#95855 (comment) says goal is under 100k for ingestManager.plugin.js fleet.plugin.js

[joshdover]

Superseded by #95863