Five mistakes teams make with critical CSS

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. These are the ones we run into repeatedly when we audit critical CSS.

Speed is a feature people notice only in its absence, and then they leave rather than complain. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The mistakes we see most

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Inlining what is needed first shortens time to first paint
• The rest can load without blocking
• Never checking whether the fix actually worked

Only worth the complexity on high-traffic pages. Getting it slightly wrong is survivable. Ignoring it entirely is not. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Making it stick

How to tell if yours is fine

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. Three things worth confirming about critical CSS before you move on:

• Someone can say what the current setup is without going to look
• Only worth the complexity on high-traffic pages — 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.