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.

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.

In our case, the browser held off executing one little space character while it waited for a CSS file. Was the impact here that great? No. BUT!