Page Comparison

...

This improvement is because we’re bundling less stuff in the guest/module architecture. If the MFE retains its index page which loads core-js, regenerator-runtime, and the header/footer, the build time is actually slightly higher on average.

Production Builds

Similar to the development build times, we’re bundling less actual code, so can expect there’s less work to do.

Production Bundle Sizes

Traditional Build

Total: 1,725,984 bytes

Guest/Module Build

Worst case bundle size: 1,167,317 bytes

The worst case scenario is how many bytes we’d have to load if our host application didn’t have a compatible shared dependency version for any of our dependencies (like Paragon).

The above bundle size number won’t make sense with the sizes in the above table. While running this test, I realized that because my MFE didn’t use our other shared dependencies, they weren’t included in the bundle. Rather than start over, I went back to the Shared Dependencies page, counted up the total size of all the dependencies that we would have to load if our host didn’t have a compatible copy of them, and added that to the base size of our best case scenario. That number was 1,081,960, and includes @openedx/paragon, classnames, prop-types, react-redux, react-router, react-router-dom, and redux. React, react-dom, and @edx/frontend-platform don't count because they are singletons and can’t be loaded more than once.

✨ Best case bundle size: 78,210 bytes

In the best case scenario, we load our GuestPage JS and CSS and the remoteEntry.js file. Remote entry is the size it is because of how many shared dependencies we have - it needs to act as a manifest for all the other files we might need to load.