How to get critical CSS right
This is one of those topics that looks small until it costs you something. The short answer to critical CSS is that it is mostly a sequence of small decisions, not one big one.
Speed is a feature people notice only in its absence, and then they leave rather than complain. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
The reason this keeps coming up
Inlining what is needed first shortens time to first paint. That sounds obvious written down. It is still the thing most often skipped. If it only works because one person remembers to do something, it does not work yet.
The steps
- Establish what you have today before changing anything
- The rest can load without blocking
- Only worth the complexity on high-traffic pages
- Write down the decision so the next person does not re-litigate it
Only worth the complexity on high-traffic pages. None of that requires a large budget, only a decision and someone to own it. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
Where to go from here
What this looks like day to day
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
- 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
Worth checking on your own setup before it becomes someone else's problem to fix.