[Cases] Reducing the page load bundle size

[adcoelho]

Summary

Things got a bit out of control ever since we merged #154436.

In this PR I managed to reduce the cases bundle size from 166.0k to 140.0k.

This was done in several different steps:

Removing the usage of query-string

This package took over 0.6% of the size of all chunks.

All functionality it provides could be replaced by the native URLSearchParans.

I removed the package in 1ef0211.

@kbn/cases-components

The cases plugin used imports from @kbn-cases-components in several places, these took up 4.4% of the bundle size.

This would normally be fine but it seemed like webpack's tree shaking wasn't working correctly when doing imports from the top like import {...} from '@kbn/cases-components'.

The plugin bundle seemed to be getting too much unnecessary code so I changed the imports in 547755c to be more specific.

Now @kbn/cases-components only takes up 0.1% of the bundle size.

Removing unnecessary public exports

Code that is shared statically with other plugins will contribute to the page load bundle size of that plugin. This includes exports from the public/index.ts file and any file referenced by the extraPublicDirs manifest property.

I read the above in the documentation and checked what we exported. I found a bunch of things that we were exporting but that actually weren't being used by other plugins.

I removed those unnecessary exports in 6a0ff8c.

Unnecessary exports part 2

After merging the multiple file-related branches we were exporting the imageMimeTypes variable(a quite large array) twice. 53135ec

It belonged to common/ that is referenced in extraPublicDirs so that saved us a few more Ks.

Cases plugin

Code that is shared statically with other plugins will contribute to the page load bundle size of that plugin.

In the cases plugin start we were returning a deprecated function that was not being used anywhere any more.

I removed it -0.9K 🤷

42b30b3

Making the clientAPI lazy

Once again,

Code that is shared statically with other plugins will contribute to the page load bundle size of that plugin.

I was going over everything that our plugin exports to see if something was not used and noticed that the functions we return in cases.api are not used by everyone.

They were already promises so I changed the implementation to lazy load the code.

A good rule of thumb here is that if the chunk is not always needed at setup/start time it might benefit from being lazy loaded. Some plugins need some of this code so we can async import() and reduce the page load bundle size significantly. See e201ab1.

Lazy loading components in the file attachment

During the cases plugin setup step we register the file's internal attachment.

This defines how the file user action will look on the Case Detail page so naturally it requires a bunch of components to be loaded. The mistake here was that we don't need those components to be loaded right away.

I followed React's guidelines for lazy loading all components in the registered object greatly decreasing the bundle size in 1c9ede7.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)

[js-jankisalvi]

Great work!! 🎉

[js-jankisalvi]

Nice approach 👍

[adcoelho]

This was effective because this attachment type is registered in x-pack/plugins/cases/public/plugin.ts.

Before realizing I was trying to lazy load everything everywhere but it didn't work :D until I realized that the cases app is already mostly lazy loaded, these were the exceptions.

[js-jankisalvi]

Wasn't aware that not importing from exact folder increases bundle size 😄

[adcoelho]

Ideally, it wouldn't because web pack should be able to recognize what is and is not necessary. But it seems we can't fully trust it 😬

[js-jankisalvi]

Haha.. better to be safe!! 👍

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 7bdff47

Failed CI Steps

• FTR Configs #23

Test Failures

• [job] [logs] FTR Configs #23 / Cloud Security Posture Findings Page SearchBar add filter

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
cases	650	640	-10

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
cases	84	64	-20

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
cases	386.9KB	416.4KB	+29.5KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
cases	30	26	-4

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
cases	175.8KB	152.9KB	-23.0KB

Unknown metric groups

API count

id	before	after	diff
cases	101	79	-22

async chunk count

id	before	after	diff
cases	23	26	+3

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
securitySolution	413	417	+4
total			+6

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
securitySolution	497	501	+4
total			+6

History

• 💛 Build #133945 was flaky 4faf9aa
• 💔 Build #127432 failed 42b30b3

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @adcoelho