Lucas_Werkmeister_WMDE added a comment.
I did some small experiments with `performance.mark()`. (Helpfully, there is already an `mwStartup` mark emitted by the MediaWiki startup module.) On my local wiki, it always takes ca. three seconds until even the `mwStartup` event. This time seems to be dominated by the network request to get the startup module (even when it’s cached, the server needs a while to generate the 304 Not Modified response), and I don’t think we can do anything about it. If the network cache is disabled, it takes a bit more than two seconds (up to 2½) to get from `mwStartup` to the beginning of `init.ts`, and then a bit less than one second from there until the event listeners are added to the links. With network cache, the first time shrinks to about a second and the second one to ca. 100 ms; the first one is still largely due to waiting on the server to return 304 Not Modified, while the second one doesn’t seem to hit the server at all (though I don’t understand why). The time spent in our own code, e. g. to identify the links, is negligible as far as I can tell. On Beta, custom performance marks aren’t available, but the server is generally faster. However, there’s a suspiciously long gap between the end of the network request for the init module and the beginning of the network request for the app module – slightly over half a second, with or without cache, whereas locally it’s more on the order of 0.3 s. I suppose that might be due to the larger number of things running on Beta in general – are we really running that much synchronous JS in the various modules? > Can we change the order in which the initial modules are loaded? We probably can with some more-or-less evil hacks (register some hook to reorder `$wgResourceModules` <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgResourceModules>, register some hook that makes a core module depend on our init module so it gets elevated in the dependency graph, …), but I’m not convinced that’s fair to other modules :) I see two options to improve performance (independent of each other): - **Register the click handlers earlier.** Currently, we wait for ResourceLoader to finish loading the app module (and wbRepo etc.) before we add event handlers to the bridge links. I see no reason to do this – we can //start// that load, but then immediately add our event handlers, and await the load within those event handlers if necessary (after stopping native click handling). This should completely remove the second time mentioned above (some 100 ms with cache on my local wiki, about a second without cache), or rather, if the user clicks fast enough they will have to wait for that duration before we begin setting up the dialog. (If we’re smart about it, we can even start setting up the OOUI dialog before waiting for the ResourceLoader to finish, though I’m not sure if that’s worth the effort. - **Drastically reduce the size of the init module.** This is supposed to be a simple preloader for the real code, and yet it’s more than 80 KiB, 10.5% (before compression) of the main ResourceLoader request (which loads all the non-startup modules at once – ULS data, CentralAuth, Vector, jQuery, OOUI, …) on Beta. I’m still very tempted to rewrite it in plain JS and serve that as a regular old ResourceLoader module – according to `find src/mediawiki/ -type f -name '*.ts' -exec cat {} + | wc -l` it’s some 306 lines of TypeScript, that’s not the end of the world – but we can also first look into why it’s so bloated, and what kind of code webpack is including in that bundle. TASK DETAIL https://phabricator.wikimedia.org/T233305 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Lucas_Werkmeister_WMDE, Michael, Aklapper, Lydia_Pintscher, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
