Question for Timo...
Is this plausible?
What would be the impact?
Are we crazy?
Why is this currently in the head?
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Declined | None | T100255 [EPIC] Load ResourceLoader startup module from the bottom of the HTML | |||
Resolved | Jdlrobson | T106756 mobile.site module should not be loaded in head | |||
Resolved | Jdlrobson | T100378 ext.imageMetrics.head should only load on File pages | |||
Open | None | T100372 CentralNotice mobile modules should not be loaded in the head |
Event Timeline
It's in the head because of these modules being loaded in the head:
view-source:https://en.m.wikipedia.org/wiki/Main_Page
mw.loader.load([ "mediawiki.page.startup", "mobile.head", "mobile.site", "ext.centralNotice.bannerController.mobiledevice", "ext.centralNotice.bannerController.mobile", "ext.centralNotice.bannerController.lib", "ext.centralNotice.bannerChoiceData", "ext.centralauth.centralautologin.clearcookie", "ext.imageMetrics.head" ]);
@Jdlrobson Is this feasible?
I've added the blocking tasks. Couldn't find anything for "mediawiki.page.startup" and "mobile.head".
Probably not at current time given we have no control over ext.centralNotice and mediawiki.page.startup
We could however explore moving all mobile code to bottom.
If it is worth it would you mind putting your thoughts into a task/spike as a blocker of this one @Jdlrobson?
Unfortunately mediawiki.page.startup is not within our control, and I'd suggest the performance team evaluate if it makes sense.
The central notice resources should be addressed in a CentralNotice refactor.
Mobile.site and mobile.head are in our control and we should think about what we gain and lose with these (the former is happening this sprint but mobile.head will have some consequences on reducing interactive time).