Three myths about critical CSS

This is cheap to get right at the start and expensive to retrofit. A few things about critical CSS that get repeated more often than they get checked.

Performance work is mostly subtraction, which makes it unpopular and effective. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

“It only matters for big sites”

Inlining what is needed first shortens time to first paint. It is worth being explicit about, because assumptions differ quietly. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

“We can deal with it after launch”

Sometimes true, usually expensive. The cost of getting this wrong is rarely visible on the day it happens.

“Our platform handles it”

Only worth the complexity on high-traffic pages. The reasoning matters more than the rule, because the rule has exceptions. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What this looks like day to day

Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about critical CSS before you move on:

• Someone can say what the current setup is without going to look
• The rest can load without blocking — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.