Site-kit-wp: Reduce module JS bundle sizes by not unnecessarily importing massive legacy data API

[felixarntz]

Bug Description

In the refactored modules' assets (googlesitekit-modules-*.js) we need to invalidate caches when settings are saved. Since we're currently partially relying on the new API and partially the legacy dataAPI, it's necessary to cover both of these cache types.

However, at the moment dataAPI is only exported as an entire object. In the module assets we only need a single function but are currently still importing that entire object, which blows up the bundle size unnecessarily.

For example, in the new googlesitekit-modules-optimize.js asset removing just the single line and import to clear the legacy cache brought down the file size from ~14kb to ~2kb.

---

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

Acceptance criteria

• The invalidateCacheGroup function used as part of dataAPI should be importable on its own, with only the dependencies that it needs. dataAPI should then import the function and include it on itself (as it is today).
• All code in assets/js/modules that imports dataAPI to get invalidateCacheGroup should only import the invalidateCacheGroup function instead.

Implementation Brief

• Create new file assets/js/components/data/invalidate-cache-group.js.
• Move dataAPI.invalidateCacheGroup to that file as a function.
• Import invalidateCacheGroup in assets/js/components/data/index.js and use it on the object.
• Update module datastore files to import invalidateCacheGroup directly instead of dataAPI:
  
  
  
  • assets/js/modules/adsense/datastore/settings.js
  
  
  • assets/js/modules/analytics/datastore/settings.js
  
  
  • assets/js/modules/optimize/datastore/settings.js
  
  

QA Brief

Changelog entry

• Reduce bundle size of Analytics and Optimize module JS assets.

[aaemnnosttv]

All code in assets/js/modules that imports dataAPI should only import the invalidateCacheGroup function instead.

Do you mean all code that imports dataAPI just for calling invalidateCacheGroup? I'm guessing there may be other usage in there from legacy API calls which shouldn't be changed here.

IB ✅

[felixarntz]

@aaemnnosttv There is no other usage :)

[tofumatt]

Looks like we also need to move the TYPE_MODULES constant out of the main data import here to prevent it being used, I think. Safer to do that anyway, and it's easy, so I'll do that as well.

[eugene-manuilov]

AdSense still loads the whole legacy dataAPI module, because util/index.js loads whole dataAPI module just to get get function. Looks like we can also extract it into a spearate script and load from a separate file:

https://github.com/google/site-kit-wp/blob/c776b09354e40612462c88fa6128e6878c24f172/assets/js/modules/adsense/util/index.js#L29
https://github.com/google/site-kit-wp/blob/c776b09354e40612462c88fa6128e6878c24f172/assets/js/modules/adsense/util/index.js#L75

[eugene-manuilov]

@felixarntz do we need to rework it in the scope of this task or we need to create a new ticket and rework get function later? Analytics and Optimize modules look good, just AdSense still has it.

[felixarntz]

@eugene-manuilov Ah right, good point. Let's ignore that here though as it would involve some more work. We can look into it separately, long-term the dataAPI usage will be phased out anyway.

[eugene-manuilov]

Sounds good, @felixarntz. Moving it to the Approval column.

[Saibamen]

Please link commit ID for closed issues...