Site-kit-wp: Optimize entrypoint bundle sizes

[aaemnnosttv]

Feature Description

As we add dependencies, JS entrypoints are growing in size where limits need to be increased.

 PASS  ./dist/assets/js/googlesitekit-activation.js: 160.8KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-admin.js: 4.49KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-adminbar-loader.js: 6.08KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-api.js: 155.4KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-dashboard-details.js: 257.04KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-dashboard-splash.js: 166.23KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-dashboard.js: 259.64KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-data.js: 63.13KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-module.js: 257.32KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-settings.js: 274.87KB < maxSize 280KB (gzip) 
 PASS  ./dist/assets/js/googlesitekit-wp-dashboard.js: 253.1KB < maxSize 280KB (gzip) 

maxSize recently increased from 270KB

We should be able to reduce the main bundle size by leveraging more asynchronous loading of chunks where possible.

---

_Do not alter or remove anything below. The following sections will be managed by moderators only._

Acceptance criteria

• Reduce module entrypoint filesize for pages that load many modules conditionally, based on user settings.
• Reduce filesize of the main dashboard and settings entrypoints, getting each of their conditional sections to load via a chunk-loader/Suspense instead.

Implementation Brief

• The dashboard and the settings entrypoints are refactored to use <Suspense> and load only the relevant modules that the user has enabled.

QA Brief

• Dashboard should continue to function with various modules activated/deactivated.
• Settings page should continue to function with various modules activated/deactivated.

Changelog entry

[felixarntz]

@aaemnnosttv What would be your suggested approach to accomplish this more asynchronous loading?

[aaemnnosttv]

@felixarntz the same way we already do for other components using dynamic imports with <Suspense>. I was talking to @tofumatt about this a bit as well and I think that the common dependencies between entrypoints are not being split out into chunks, like vendor chunks are. There may be some fine-tuning of the webpack config needed here but the general idea is splitting the entrypoints into more chunks which are loaded on demand.

[tofumatt]

For folks looking at this issue, thinking it's been solved by #1222/#1344: not quite 🙂.

That issue was about ensuring vendor chunks (eg. packages from node_modules/) were shared between entrypoints. But this one is about establishing places we can leverage to only load certain bits of code on-demand.

A good place to start might be the Settings page—each "module" (AdSense, Analytics, etc.) has its own component and related code to load, but the modules that the user doesn't have enabled shouldn't be loaded. That could save on filesize/speed.

---

In practice this should mean the dashboard and the settings entrypoints are refactored to use <Suspense> and load only the relevant modules that the user has enabled.

[tofumatt]

Pushing this one through because I think it's a good first issue to tackle, assuming there aren't any gotchas in the code that loads these pages…

[aaemnnosttv]

@tofumatt

The dashboard and the settings entrypoints are refactored to use and load only the relevant modules that the user has enabled.

I'm not sure this is possible given the current architecture. Modules hook into the settings app in their index modules. Maybe we could cut down on the bundle sizes by hooking in the module wrapped in Suspense as you're referring to, but the module's index module still needs to be loaded early for hooks to be registered. For this reason, I'm not sure that using suspense for these components would offer much benefit. What do you think?

[tofumatt]

Sounds like exactly the sort of gotcha I figured we might run into.

The file sizes on the entry points are already way down thanks to vendoring. I wonder if it’s best to leave this issue alone until the removal of the old WP hook API usage. I think it is.

[tofumatt]

(Should we close this issue or mark it blocked by the JSR epic or something like that?)

[aaemnnosttv]

Related: https://github.com/google/site-kit-wp/pull/1311#issuecomment-615929968

[felixarntz]

@aaemnnosttv @tofumatt Can you provide an update here based on the last comments? The IB is a bit vague right now, and it sounds to me that this issue could easily introduced unexpected problems because of how our code is currently structured? I feel like this could benefit from a more precise proposal.

[aaemnnosttv]

I talked through this with @tofumatt a bit and considered a few different options and approaches although none of them were going to be as easy as what was originally invisioned for this issue.

After taking another look at the bundle sizes, it seems that we've already improved them quite a bit with the introduction of the vendor bundle and the other work we've done related to import hygiene.

As it is, our biggest bundle is (unsurprisingly) vendor now, with the next largest settings coming in at 64KB. Many of the others are ~50KB or less.

 PASS  ./dist/assets/js/googlesitekit-activation.js: 20.88KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-admin.js: 1.68KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-adminbar-loader.js: 3.19KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-api.js: 7.81KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-dashboard-details.js: 59.31KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-dashboard-splash.js: 24.52KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-dashboard.js: 61.86KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-data.js: 2.62KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-datastore-site.js: 4.73KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-module.js: 59.54KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-modules-analytics.js: 19.38KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-modules.js: 3.28KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-settings.js: 64.91KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-vendor.js: 266.84KB < maxSize 280KB (gzip) 

 PASS  ./dist/assets/js/googlesitekit-wp-dashboard.js: 55.72KB < maxSize 280KB (gzip) 

Closing this one out as there isn't a lot of room for improvement right now.