This was intentional and made on the basis that any changes to template CSS would be better inside the template itself and top loaded CSS is very expensive. I've added the RFC that has been campaigning for more flexible in CSS templates, as it helps both improve performance and load.

In the mean time could you inline any CSS to avoid the disruptive flash? You probably don't want to load this CSS on every single page anyway.

Rather than have

.mw-tpl-portal-image {
    font-size: 160%;
    padding-top: .5em;
    text-align: center;
}

could you not use an inline style in the template? This seems to minimise flash.

In the particular instance I'm pointing to here I probably can figure out how to refactor things to use inline styles. In general I agree that getting T483: RfC: Allow styling in templates implemented would be a better solution to most site css hacks. I guess I'm not completely sold on the concept that MobileFE is measurably faster by omitting the equivalent of desktop's <link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=site&amp;only=styles&amp;skin=vector" />, but I'm not ready to find the data to prove that.

It depends... Probably on wikitech it doesn't but on wikis like enwiki common.CSS is bigger than all the existing styles needed for the skin :)

The potential is there without any sysadmin there to manage/monitor it.

Id suggest this would be made optional so sysadmins who don't care can apply them but then you are opening Pandora's box.

It depends... Probably on wikitech it doesn't but on wikis like enwiki common.CSS is bigger than all the existing styles needed for the skin :)

The potential is there without any sysadmin there to manage/monitor it.

Id suggest this would be made optional so sysadmins who don't care can apply them but then you are opening Pandora's box.

This shouldn't be blocked on T483: RfC: Allow styling in templates. Things are broken due to a contract violation with site CSS - causing FOUC bugs and such.

Mobile already dequeues Common.js and Common.css, introducing a much smaller Mobile.css. Similar to Common.css, virtually every single style in Mobile.css is layout related and causes a FOUC if loaded late. It's not a script module and should not be loaded as such.

I was surprised this doesn't cause a FOUC for infoboxes and such. Turns out MobileFrontend hardcodes styles for those as part of "Minerva hacks for Wikimedia wikis". Essentially cherry-picked part one wiki's Mobile.css to avoid the most obvious FOUC, ignoring the others. Collaborating with the community on their stylesheets can be hard. It may be ignored for early experiments, but after that it's part of the job.

Loading it late degrades perceived performance and overall user experience. Page load time and 85% render time (WebPageTest) are also higher now when loading it late due to it starting the fetch much later and causing many wasted repaint cycles along the way (FOUC).

Last year we experimented in ResourceLoader with a second style queue. It didn't improve things how we hoped and was subsequently reverted. In the long run, we'll need a more delicate split (see T127328), but for now I suggest the same strategy for Mobile.

Loading it late could make the technically recorded first paint (1% render) occur marginally faster. But at the aforementioned cost of degraded perceived performance, slower total page load time, and user-facing content reflows.

When we last experimented with top loading this stylesheet first paint was delayed by 2s (I think on 2g) but I remember there was also a delay for 3g too due to the additional stylesheet url. This may be less now but I still think this is unacceptable.

The strategy so far has been to put layout styles in a hacks module. I'm happy to shift more rules over there or explore ways to group the stylesheet in the existing skin styles url if that's an option.

In terms of the RFC I agree I just wanted to ensure these were linked as reading PMS are aware of this problem and needing examples of things this will help.

Agree with Krinkle.

Because of the asynchronous loading of the Mobile.css, we experience horrible FOUCs. Even on 4G.
This old "first paint was delayed by 2s (I think on 2g)" metric should be forgotten. 4G is, literally, a thousand times faster than 2G. And even on the terribly slow 2G, I'd prefer a delay of 2 seconds over a ton of FOUCs.

And completely removing the Mobile.css, leaving only TemplateStyles, would be a nightmare for editors.

Currently, the Mobile.css on enwiki is 2.5 KB minified. We should just load that CSS, and Bob's your uncle.

Because of the asynchronous loading of the Mobile.css, we experience horrible FOUCs. Even on 4G.

I believe there is no asynchronous loading of Mobile.css, at least going by enwp. The styles are loaded using a normal <link rel="stylesheet"> which loads synchronously, not asynchronously. I'm not sure if your asynchronous loading is being caused by some custom settings on your wiki, but if you're getting a FOUC on enwp then asynchronous loading is not it.

And if it was, then that'd be a much bigger issue than just to move it up somewhat in its order of importing. I mean asynchronous loading is intended to be used when loading supplementary stylesheets, such as those for additional tools that aren't shown on pageload anyway (i.e. dynamic page element styles). Any base stylesheets should always be loaded synchronously in the <head>.

I'm not sure what 'bottom loading' really has to do with anything here though; all styles in the head should be loaded before displaying the page. If the download of a large file is an issue, then that's exactly what the rel="preload" is meant for. There's no need to sacrifice functionality in order to achieve this. Example:

<link rel="preload" href="Common.css" as="style" />
<!-- all other stylesheets that need to have less priority than Common.css -->
<link rel="stylesheet" href="Common.css" />

That would actually fix the whole issue people are having, without having to sacrifice the Common.css precedence over other 'default' stylesheets.

I'll also post this to the currently open issue that is marked as this issue's duplicate.