Optimizing JS bundle for HTTP2

What does this MR do?

In the course of setting the very basis for the performance optimization work, this MR updates our webpack's optimization.splitChunks option to make JS bundle more optimized for working in the HTTP2 scenario.

Screenshots

All the measurements are taken locally in the GDK environment. Hence, it's worth noting the testing conditions:

1. HTTPS is enabled
2. HTTP2 is enabled
3. Webpack's dev server is disabled in config/gitlab.yaml

To get the production bundle of Webpack:

1. Stop the Webpack service in GDK with gdk stop webpack
2. Generate Webpack's production bundle with yarn webpack-prod
3. Restart the GDK server with gdk restart rails-web. The server gets restarted between Before and After analysis

	Before	After	Benefit
Webpack bundle (parsed)			36.3% smaller total JS bundle
Webpack bundle (gzipped)			33.65% smaller total JS bundle
Exemplary waterfall (/h5bp/html5-boilerplate/-/tree/master in local GDK setup)			Even though the number of requests nearly doubled on this particular page, due to HTTP2 they are fetched in parallel with slight (very rough measurement in DevTools) loading performance improvements

Why bother?

Even though the overall bundle size is smaller, it might look like the actual time performance boost here is not that significant (if any) after all. However, this split into smaller chunks allows for easier and more granular optimizations along the road. So this MR is just the basis for the further optimizations towards more granular assets serving different routes.

Performance profiles:

• Current master 31.6% of time in scripting
• Baseline in this MR 25.2% of time in scripting

In the case of the config, introduced in this MR, we have 20.2% less time spent in scripting.

⚠ keep in mind that these numbers are very rough and depend on a lot of factors related to my local machine. However, the measurements were done with the best intent and to the best of my knowledge calculating an average out of 5 runs for each case.

But… but… HTTP1.1!

To make sure we do not degrade performance for those on HTTP1.1 dramatically, I made measurements on HTTP1.1 as well:

	Master	Master Average	Branch	Branch Average	+/- Absolute numbers	+/- Percentage
DOMContentLoaded Event (DCL)	1361 1234.9 1276.2 1257.2 1238.4	1273,54	1396.1 1126.5 1289.9 1400 1261	1294,7	21,16	+1,66% 👎
First Contentful Paint (FCP)	1365.6 1240 1099.7 1261.9 1243.2	1242,08	1294.5 1432.5 1106.7 955.2 1414	1240,58	-1,50	-0,12% 👍
Largest Contentful Paint (LCP)	3053.3 2289.1 2661.5 2457.7 2346.1	2561,54	2723.7 2352.1 2502.7 2913.0 2541.0	2606,5	44,96	+1,76% 👎
Cumulative Layout Shift (CLS)	0.02148 0.2234 0.02158 0.02155 0.2233	0,102262	0.2235 0.02148 0.02167 0.2235 0.02148	0,102326	0,00	+0,06% 👎

As the numbers in the table suggest, the suggested change has very little effect (if any) on HTTP1.1 for this particular view (repository view).

Relevant performance profiles

• Current master
• baseline.zip

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team