Critical CSS.

Critical CSS is the minimum set of styles needed to paint the page’s first visible area, applicable immediately without waiting for a separate file.

The browser paints nothing before downloading and parsing the stylesheets. This rule makes stylesheets render-blocking: each one is a request and a wait. With three separate stylesheets on the page, the first paint waits for all three.

The critical CSS approach aims to shorten that wait: the rules needed to paint the first visible area are extracted and embedded directly into the page, while the rest loads later in a non-blocking way. The first paint then waits for no network request.

When it pays, when it does not

The technique is powerful but not free, and not every site gets a return. The gain depends on the stylesheet’s size and the server’s speed; when both are good, the gain can stay too small to measure.

On this site the approach was evaluated and NOT chosen. The rationale was measured: two separate stylesheets were merged into one and the comments stripped; the result was 12.4 kilobytes after gzip. A single file of that size arrives from a good server in one round trip, and the gain critical CSS would bring does not justify the system’s complexity.

The decision was made with numbers. Before the merge, two files were blocking render in the mobile Lighthouse run: one for 821 milliseconds, the other for 221. The merge closed both. Critical CSS would have been an attempt to split the time remaining after that point — and no time remained to split.

A technique can be good and needless on your site; the two do not contradict.

If applied, how

There are cases where critical CSS is genuinely needed: large design systems, many-page applications, and sites whose stylesheets reach hundreds of kilobytes. There, the approach is set up like this.

1. Define the visible area — for which screen size? Usually the narrowest and most common breakpoint is chosen.
2. Extract the rules — a tool that collects the selectors used in that area; not done by hand.
3. Embed into the body — the extracted rules go inside the page, applied before the first paint.
4. Load the rest without blocking — the remaining styles arrive later via a method that does not block painting.
5. Produce per page type — the home page’s critical set is not the article page’s.
6. Automate — a hand-maintained critical set goes stale at the first design change.

The last item is this technique’s real cost. Critical CSS must be regenerated as the design changes; extracted once and forgotten, the first paint happens with wrong styles and the page visibly “jumps.” That is a worse outcome than using no critical CSS at all.

The tension with the content security policy

Embedding critical CSS in the body means using inline styles — and a strict content security policy blocks inline styles. The two goals conflict directly, and a choice must be made.

Loosening the policy is an option but has a security price; giving each inline block its own signature is possible but complicates the build chain. On this site the policy was kept strict and inline styles were never allowed — the second reason critical CSS was not chosen.

The general lesson: performance techniques cannot be evaluated in a vacuum. A technique is weighed together with your security policy, your maintenance capacity and your existing measurements. There is no list that is right for everyone; there is a list measured and decided.

The alternative: shrinking the file

The problem critical CSS tries to solve — waiting on the stylesheet — can also be reduced another way: genuinely shrinking the file. And on most sites that path is cheaper, more durable and less risky.

1. Remove the unused rules — on most sites the bulk of the stylesheet is used on no page.
2. Weigh the framework defaults — a ready-made CSS framework may let you use ten percent of the rules it brings.
3. Strip the comments — keep them in the source, not in production.
4. Verify the compression — is the server really sending compressed? Not to be assumed without checking.
5. Gather into one file — even on modern protocols, the styles needed for the first paint should arrive in one request.

On this site four of the five items were applied, and the measured result is 12.4 kilobytes gzipped. A file of that size arrives from a good server in one round trip; the gain of extracting critical CSS stays too small to measure and does not justify the complexity.

The general lesson: whether a technique is necessary is learned from the measurement taken before applying it. Critical CSS is a real solution for large stylesheets — but first check whether the file really is large.

A closing measurement suggestion: the first paint time should be measured before and after applying critical CSS, and the difference written down. The technique looks intuitively right, and precisely for that reason it gets applied without measuring — yet on small stylesheets the gain can stay inside measurement noise. An unmeasured optimization is an assumption; and an assumption carrying maintenance cost turns into a loss over time.

On this site the decision was made exactly this way: the technique was evaluated, the existing measurement examined, the gain estimated and compared with the complexity. The conclusion was not to apply it — and the rationale went on record so that when someone asks the same question in the future, the answer is ready.

There is also the matter of team size: critical CSS production adds a step that must rerun whenever the design changes, and when that step is forgotten the result is worse than having no critical CSS at all. In small teams the maintenance burden can exceed the gain. A technique must be weighed not only by its performance return but by the capacity to sustain that return.

A practical checklist

Turning this page into an audit step, here is what to check for the render cost of stylesheets. The list is kept short because long lists do not get walked; six items fit in one sitting.

1. How many stylesheets come down — more than one is a merge candidate.
2. What is the size after gzip — a file around ten kilobytes arrives in one round trip.
3. What share of rules is unused — framework defaults are the largest source of bloat.
4. Do comments reach production — keep them in the source, not in the output.
5. Is the server compressing — not to be assumed; to be measured.
6. Is critical CSS really needed — to be asked AFTER the file has shrunk.

The sixth item is this page’s thesis: the technique choice comes after the measurement. On this site the order ran exactly that way — first the merge and the stripping, the result was 12.4 kilobytes gzipped, and at that point the gain critical CSS would bring did not justify the complexity.