Right now CSS added using addModuleStyles end up in the head regardless of their "position" value.
|mediawiki/core : master||Add ability to load plain CSS files at the bottom|
- Mentioned In
- T109837: Remove top/bottom queue distinction
T100697: Warning: OutputPage::getModuleStyles: style module should define its position explicitly: ext.geshi.language.bash ResourceLoaderGeSHiModule [Called from OutputPage::getModuleStyles in /srv/mediawiki/php-1.26wmf8/includes/OutputPage.php at line 603] in /srv/mediawiki/php-1.26wmf8/includes/debug/MWDebug.php on line 300
T100403: Fix "style module should define its position explicitly" warnings
rMWd6b4d3c537fa: Add ability to load plain CSS files at the bottom
- Mentioned Here
- rMWb7c0e537ebb7: Load all CSS in the top queue
T109837: Remove top/bottom queue distinction
T92747: Style modules should be considered "ready" when they are applied to a page
T92459: ResourceLoader should restrict addModuleStyles() to modules that only provide styles
T96797: Top-queue stylesheets should be versioned for improved caching
What kind of CSS is required for the no-js mode but is not required for a FOUC-less first rendering?
I think it's possible, but without an example use case it seems odd that you'd want to load no-js CSS from the bottom.
It seems like anything one would move to the bottom queue simply doesn't belong in addModuleStyles but should simply use addModules. Please provide a use case.
- "When (not) to use a top module", https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#Module_structure
- T96797: Top-queue stylesheets should be versioned for improved caching
- T92459: ResourceLoader should restrict addModuleStyles() to modules that only provide styles
- T92747: Style modules should be considered "ready" when they are applied to a page
@Krinkle can CSS-only modules added via addModules end up at the bottom in no JS mode?
The reason to be doing this is that on mobile web we are currently loading all the CSS in the head, including things that can appear later, such as icons. If addModules has the ability out-of-the-box to have specific CSS modules loaded at the bottom of the page in no JS mode, I'm interested. I couldn't find a way to do that, but maybe I missed something.
I know that it's easy to do with JS and RL, but the styles we're talking in my use case can't be JS-only. And there's no reason to make no-JS so much slower in terms of blocking rendering by shoving everything in the head when the solution is as simple as a <link> at the bottom of the body.
I agree, so load them from the regular bottom queue.
addModuleStyles is a hack meant only for the bare minimum styles required to make the no-js mode render correctly. It is not meant for all main stylesheets. See also Developing with ResourceLoader/addModuleStyles.
It's absolutely fine for a style-only module to be loaded through addModules(). Especially with regards to ability to cache and have dependencies. addModuleStyles has next to no caching and bypasses dependency resolution.
If these relevant styles are required for elements visible on first render, then they can't be deferred at all. If they are a separable component of the stylesheet that provides contained interaction or enhancements, we should consider removing them from addModuleStyles.
My question remains: does the regular bottom queue work in no-JS mode for styles modules? getScriptsForBottomQueue suggests otherwise and I've been unable to make the styles module I'm interested in show up as a bottom <link> when using addModules. It shows up at the bottom, but loaded via JS.
In no-JS mode all the CSS is loaded in the head with addModuleStyles. Because currently addModuleStyles only supports adding things to the head. That's a waste, since a lot of that CSS doesn't need to be render-blocking. The biggest low-hanging fruit is the module containing icons, which represents 27.5% of the weight of that head CSS. There's probably more gain to be had with images alone, since other modules also contain a bunch of embedded images.
Move that icon module to the bottom of the page in a way that works with no-JS and that's seconds shaved off the render-blocking stage on a slow connection. It's a tradeoff, since icons will show up after the main content if they're slower to load, but in-article images also show up later.
Per T109837 and (currently temporarily reverted) b7c0e537ebb7, further research shows the net result from splitting up the style queue is negative. We're better off having a single request higher up in the dom as opposed to having two (where one is toward the end of the body).