Change Details

MobileFrontend currently provides 64 modules (58 in extension.json, 6 in MobileFrontendHooks.php), of which 51 are registered on desktop and 64 on mobile. This amount to a significant overhead to the startup module, which Performance Team is working on this quarter to reduce in size as part of T192623. This task is to track the effort of removing and/or consolidating modules that are not separately needed. To do this, I find it helps to think of modules as delivery bundles. The primary purpose of a module registration is to be able to queue it with OutputPage::addModules (or to lazy-load it client-side). And modules are only split to avoid unused code being loaded, e.g. when there are N>1 other modules dependent on it, where those N modules are not always loaded together.

MobileFrontend currently provides 64 modules (58 in extension.json, 6 in MobileFrontendHooks.php), of which 51 are registered on desktop and 64 on mobile. This amount to a significant overhead to the startup module, which Performance Team is working on this quarter to reduce in size as part of T192623. This task is to track the effort of removing and/or consolidating modules that are not separately needed. To do this, I find it helps to think of modules as delivery bundles. The primary purpose of a module registration is to be able to queue it with OutputPage::addModules (or to lazy-load it client-side). And modules are only split to avoid unused code being loaded, e.g. when there are N>1 other modules dependent on it, where those N modules are not always loaded together. See also: * {T153473}

MobileFrontend currently provides 64 modules (58 in extension.json, 6 in MobileFrontendHooks.php), of which 51 are registered on desktop and 64 on mobile. This amount to a significant overhead to the startup module, which Performance Team is working on this quarter to reduce in size as part of T192623. This task is to track the effort of removing and/or consolidating modules that are not separately needed. To do this, I find it helps to think of modules as delivery bundles. The primary purpose of a module registration is to be able to queue it with OutputPage::addModules (or to lazy-load it client-side). And modules are only split to avoid unused code being loaded, e.g. when there are N>1 other modules dependent on it, where those N modules are not always loaded together. See also: * {T153473}