,
20 tweets,
6 min read
Read on Twitter
The issues are manifold. In theory, loading CSS anywhere in the BODY is 💯% a great idea in 2019. See here: csswizardry.com/2018/11/css-an… and, more thoroughly, here: jakearchibald.com/2016/link-in-b… by @jaffathecake.
Loading CSS in-BODY allows for a progressive render, as almost all browsers will only block rendering of *subsequent* content (that is to say, content beneath the rel=styleheet), as opposed to the traditional behaviour of blocking of all content.
Here’s what used to happen (credit: @jaffathecake):
And here’s what (in theory) happens now (credit: @jaffathecake). Neat, eh?!
In practice, however, it’s not so rosy. Browsers preload-scan the HTML response and look ahead for references to subresources defined later in the markup. The practical upshot is that these on-purpose late-defined stylesheets get hoiked up the request stack.
This is a current (and wonderful!) client of mine. We’re experimenting with in-BODY CSS. Entries 10–13 are declared on lines 2197, 2255, 2267, and 2375 respectively, yet are requested before entry 15 which is defined on line 24. 
This is Chrome’s resource scheduling which, IMO, is being overzealous in this case. Chrome engineers agree in principle, and I have opened the relevant bug: bugs.chromium.org/p/chromium/iss…
It’s a similar story in Firefox and Edge.
tl;dr: Simply whacking your CSS in-BODY (or even at the </body>) will likely be ineffective. The browser will still over-prioritise it.
You could try to circumvent this by flushing your <head> nice and early. As HTML is a streaming format (this is why SSR is fast by default), it’s possible to send discrete chunks to the client, so sending your <head> tags early means the browser can begin work on that first.
Old gold from @stoyanstefanov: phpied.com/progressive-re…
Once we’ve solved the network overhead, we hit a snag with rendering performance. Every time we append to the CSSOM, we need to do a cumulative style recalc. That is to say, add the new CSS to the existing CSS and recalc it *all*, ad infinitum.
We can’t just recalc the new CSS; we need to add it to all existing CSS and then recalc it *all* again. So it’s imperative that we tread carefully and be sure to de-dupe as much as we can.
Don’t import button.css for *every* button; load it once and once only. I would only recommend the in-BODY technique for ‘milestone components’ that will only appear once, such as your nav, carousel, footer, etc.
Any components that appear a lot (cards, buttons, form elements, etc.) you should bundle into one big package in the head. This means your in-BODY CSS usually becomes the exception rather than the rule.
So, although theoretically a promising new technique that we should be all using right now, it’s not quite so straightforward in practice. My advice? Hire me to look into it all for you: csswizardry.com/consultancy/
This thread brought to you by a non-trivial amount of Croatian wine, so I will gratefully accept any constructive clarification and improvement.
Interjecting here: Credit to Chrome: it does *return* in-HEAD assets before in-BODY ones, which is actually great! But it still assigns them HIGHEST priority and pulls them way up the request queue. I am now on the fence about this.
It’s been a couple of years since I decided to shift my focus toward performance, but CSS is still my first love. Where they intersect is my absolute favourite.
☕️ And if you enjoyed reading this thread as much I enjoyed putting it together, my @LaynesEspresso order is a long black 😉 paypal.me/csswizardry/2.8
