[bigethan]

Seriously.

CSS loading/parsing is render blocking. By loading CSS that isn't needed immediately asynchronously in a way that will use the browser cache if it's available, it makes the page visible much faster. It feels like overkill in the simple example, but it's a tried and true method. ( https://github.com/filamentgroup/loadCSS has > 2k stars if that kinda thing means anything)

From my experience on a large website (m.trulia.com), On a 3G connection with an 'average' (nexus 5) phone, this technique made almost a 2 second difference in perceived load time.

[fkooman]

I guess it is time for this one again: http://idlewords.com/talks/website_obesity.htm

if the CSS isn't needed immediately, simply don't load it :)

[bzbarsky]

> CSS loading/parsing is render blocking.

Sometimes. Sometimes not. The problem is that browsers disagree on when it is and that some of them block way too much, which leads to the ugly workarounds.

There were some proposals for a <link rel="async stylesheet"> that didn't really seem to get much traction so far, but they're really the right way to solve this problem.

[freshyill]

In a few hours, I'm launching a very large website that relies heavily on LoadCSS(). Page load times have been excellent in the pre-public phase, even though our critical styles contain a mountain of Autoprefixer-generated flexbox prefixes.

My understanding is that all of this will become an antipattern once we can support http/2. For today, however, it provides a very real performance boost.

[Flimm]

My understanding is that concatenation will be become an anti-pattern with http/2, but not `<script async..>`, `<script defer..>`, or loadCSS.