Critical Performance Alert: Unpacking the Duplicate RequireJS Script Loading Bug in Magento 2.4.x
Critical Performance Alert: Unpacking the Duplicate RequireJS Script Loading Bug in Magento 2.4.x
As e-commerce experts focused on Magento migrations and platform optimization, we at Shopping Mover constantly monitor the pulse of the Magento community. A recent GitHub issue (Issue #40527) has brought to light a significant performance and stability concern affecting Magento Open Source and Adobe Commerce versions 2.4.7, 2.4.8, and the 2.4-develop branch. This critical bug involves the duplicate loading of JavaScript modules via RequireJS, leading to slower page loads and potential front-end errors.
The Core Problem: Unintended Double Script Loading
The issue stems from an unexpected behavior within Magento's RequireJS implementation, specifically in the lib/web/mage/requirejs/mixins.js file. The defContext.configure wrapper, designed to synchronize RequireJS contexts, inadvertently forwards the complete configuration object—including deps (dependencies) and callback—to the unbundled $ RequireJS context. This is problematic because the $ context is primarily intended for path resolution, not for loading modules.
Consequently, every module listed in a deps array within requirejs-config.js is loaded twice: once by the default _ context and again by the $ context. This results in duplicate tags appearing in the browser's network tab for essential modules such as:
mage/common.jsmage/dataPost.jsmage/bootstrap.jsMagento_Ui/js/core/app.jsMagento_PageCache/js/form-key-provider.jsMagento_Translation/js/mage-translation-dictionary.jsMagento_Theme/js/theme.js
Impact on Merchants and Developers
The implications of this bug are far-reaching. For merchants, duplicate script loading directly translates to:
- Slower Page Load Times: Increased network requests and redundant script parsing delay the user experience, potentially impacting SEO and conversion rates.
- Increased Bandwidth Consumption: Unnecessary data transfer for repeated scripts.
- Intermittent Front-end Errors: More critically, the double execution of scripts like
mage/bootstrap.jsandmage/common.jscan corrupt jQuery plugin states. This manifests as frustrating, intermittent errors such as$fotoramaElement.fotorama is not a functionon product pages, directly affecting image galleries and product display functionality. The intermittent nature makes these issues particularly challenging to diagnose and debug.
The issue has been categorized with a Severity S0, indicating it affects critical functionality and leaves users without an immediate workaround.
Tracing the Root Cause
The problem was introduced in commit bf705b031d1c4ea63f19ff14036d9d1ffd4f8304. This commit altered the script loading order, causing mixins.js to load before requirejs-config.js. To maintain synchronization, a wrapper was added to defContext.configure:
// lib/web/mage/requirejs/mixins.js — L229-232
defContext.c (cfg) {
originalContextConfigure(cfg);
unbundledContext.configure(cfg); // ← forwards deps, triggering loads in '$' context
};
The key insight from the community is that the unbundledContext.configure(cfg) call processes cfg.deps internally, leading to unwanted module loading in the $ context, which should only handle path resolution.
Community-Proposed Solution
Fortunately, the original reporter, hryvinskyi, also provided a clear and concise proposed fix. The solution involves stripping the deps and callback properties from the configuration object before it's forwarded to the unbundled context. This ensures that only relevant configuration, not module loading instructions, reaches the $ context:
defContext.c (cfg) {
var unbundledCfg = {},
key;
originalContextConfigure(cfg);
for (key in cfg) {
if (cfg.hasOwnProperty(key) && key !== 'deps' && key !== 'callback') {
unbundledCfg[key] = cfg[key];
}
}
unbundledContext.configure(unbundledCfg);
};
This proposed fix effectively prevents the redundant module loading without disrupting the intended synchronization of other configuration aspects.
Confirmation and Next Steps
The issue has been successfully reproduced and confirmed by the Magento engineering team on the latest 2.4-develop branch. A Jira ticket (AC-16506) has been created, indicating that an official patch is in the pipeline. For merchants and developers running affected Magento 2.4.x versions, monitoring for the official release containing this fix is crucial for maintaining optimal store performance and stability.
This incident highlights the ongoing importance of the Magento community's vigilance in identifying and resolving core platform issues, ensuring a robust and efficient e-commerce experience for all.