Frontend Performance Recommendations


Below are some techniques that may be applied to Open edX micro-frontends to improve frontend performance.

Webpack configuration with splitChunks

With HTTP/1.1, browsers can only handle a maximum number of simultaneous requests for assets (n = 6). In this case, you would want to limit the number of critical files needed to be downloaded by the user’s browser upon initial page load, usually resulting in fewer but larger files.

However, if HTTP/2 is supported (e.g., out-of-the-box with Cloudflare CDN), how content is prioritized during the loader process is significantly faster. As a result, browsers no longer have that restricting limit to the number of files or assets that may be downloaded at once thanks to multiplexing.

Given this, if relying on HTTP/2, it may be benefit to configure Webpack to have a maxSize on its generated JavaScript file chunks to ensure smaller files that may be downloaded in parallel.

For more about HTTP/1.1 and HTTP/2, see


Code splitting

The intent with code splitting is to defer the loading of assets (JavaScript, CSS, etc.) that aren’t relevant to the user’s current interaction or user flow. For example, if an MFE contains “Dashboard” and “Search” page routes and the user is currently on the “Dashboard” page, performance can be improved by deferring the loading of any code specific to the “Search” page route until the user requests to navigate to the “Search” page (or demonstrates intent through prefetching).

Code splitting helps with long-term caching as unchanged chunks keep the same file names across builds, remaining cached by users at the CDN layer. As a result, users typically only download chunks that have changed since their last visit, or all chunks if its their first visit.

When running npm run build, the default Open edX Webpack configuration generates a Webpack Bundle Analyzer report, which is useful to investigate and prioritize opportunities for code splitting.


Preconnect resource hints

<link rel="preconnect" href="" />