Introduce code splitting and lazy load components to reduce bundle sizes

[thelovekesh]

Currently, AMP plugin JS assets constitute various modules which are as follows with their bundle size:

Module	Stat	Parsed	Gzipped
AMP Validation	54.74 KB	21.97 KB	7.77 KB
Block Editor	171.13 KB	83.56 KB	21.42 KB
Classic Editor
Admin	81.32 KB	34.54 KB	12.02 KB
Customizer	31.22 KB	12.99 KB	4.87 KB
WordPress Polyfills
Onboarding wizard
Settings page	3.13 MB	1.64 MB	284.67 KB
Support Page	989.85 KB	388.23 KB	127.26 KB
Styles
Mobile Redirection

Source: Webpack Bundle Analyzer

Upon bundling these assets Webpack warns of a bundle limit exceeding 244 kb size that is not optimal for web performance. Even though these things will not affect an end user but can affect the admin side.

To overcome these bundle-heavy situations we can implement react lazy loading and code splitting for such components/modules which are not needed at the time of first loading impression.

More refs on lazy loading and code splitting:

• https://reactjs.org/docs/code-splitting.html#reactlazy
• https://webpack.js.org/guides/code-splitting/

[westonruter]

Oof. 3.13 MB for the Settings page? That's big.

Why are some of the module rows blank?

I'm hesitant to spend a significant amount of time on the code splitting since performance of the pages hasn't been a user complaint so far. Nevertheless, if it is a quick win then I don't see why we shouldn't do it.

[thelovekesh]

Why are some of the module rows blank?

Ahh. Sorry, I forgot to mention. While analyzing modules, no analyzing stats were there for empty blank ones. I think it's due to their fewer bundle chunks(and less in size) or there is just a plain css/js file that does not contain any other dependency in it.

I'm hesitant to spend a significant amount of time on the code splitting since the performance of the pages hasn't been a user complaint so far. Nevertheless, if it is a quick win then I don't see why we shouldn't do it.

I think it's because it loads on the admin side and performance doesn't matter much(I mean PX). After the first-time load, static assets got cached on the browser as well so it's not something the user will face every time.

But we can keep it a low priority and analyze the field of improvement. Instead of doing heavy benchmarking, we can find out simple cases where it can be done easily.