Post

CSS is render- but not parser-blocking. This means that while a browser is fetching CSS, it is permitted to continue parsing the rest of your HTML but not render it. HOWEVER! If you’re not careful, you can inadvertently end up in parser-blocking territory.

Take this demo HTML file. A stylesheet and 10,000 paragraphs. Here we can see that the browser is permitted to parse the HTML while the CSS is in flight. This is A Good Thing™.

Now let’s introduce one little change. A script with a single space character immediately after the stylesheet. What happens now?

The Parse HTML tasks are bolted onto the end of the CSS’ fetch. The main thread wasn’t allowed to do anything else while the CSS was in flight.

They are interleaved with rendering tasks, which shows is the browser’s ability to progressively render HTML, but one space character held up the main thread completely!

And why did this happen? Defensively, browsers will not run any synchronous JS if any synchronous CSS is still in flight. This is because the JS could read/write from/to the CSSOM, so the browser will build the CSSOM first, just in case.

Statistically, this isn’t behaviour you actually need or want very often, so placing JS after CSS often leads to main thread inefficiencies that you could probably circumvent.

I have a client at the moment who has a FIVE MEGABYTE STYLESHEET which just took 6s to fetch over train wifi.

This is misleading. It’s about 600KB over the wire; 5MB decompressed.

5MB depressed 😓 Would love to get my hands on that stylesheet to help make @projectwallace.com faster in a bunch of areas.

Because this stylesheet is defined before some JS, for that entire 6 seconds, their main thread was unable to do any work (other than some receive data events). Totally blocked by CSS. That goes some way toward explaining this: