Performance
Extracting critical CSS without breaking the rest
Critical CSS is the part of the stylesheet the first screen needs, inlined in the HTML. This article page loads 93,756 bytes of CSS before it paints.
Key points
- Critical CSS holds only the rules the first screen needs and travels inside the HTML.
- The article page loaded 5 stylesheets totalling 93,756 bytes before the first paint, measured on 1 November 2026.
- Regenerate the critical part on every deploy: it is a snapshot of one route and one viewport.
Critical CSS is the part of the stylesheet the first screen needs, inlined in the HTML; the rest arrives later and never blocks the paint. The article page of this site loads 93,756 bytes of CSS before it paints.
What belongs in the critical part
| Part of the sheet | In the critical part | Later |
|---|---|---|
| Reset and base typography | yes, a few rules | no |
| Header and hero of the first screen | yes | no |
| Component grid | no | yes, at the end of the page |
| Print styles | no | yes, with media=print |
| Dark theme | only the initial values | yes, the rest |
The practical rule: if a rule does not change what the reader sees without scrolling, it is not critical. The rest goes into an external sheet fetched with preload and applied with onload.
The markup to serve
preload fetches the sheet in parallel with the HTML, onload applies it when ready, and noscript covers visitors who run no JavaScript. The sheet stays cacheable once, instead of being repeated in every page.
The command
npx critical https://example.com/blog --inline --base ./dist --dest ./dist/blogcritical opens the page in a headless browser, works out the rules used above the fold, inlines them in the HTML and defers the rest. Run it on every deploy: a changed sheet without a new snapshot leaves stale rules in the HTML.
The limitation
The critical part is a snapshot: it depends on viewport, route and page state. The 93,756 bytes measured here describe the page before any optimisation, so they are not a result; and inline CSS is not cached, so every page carries its own weight.
Where to continue
In the EneUI catalogue: the components, the block empty state and the record spotlight card, three examples of markup the first screen does not need. The guides: route-level code splitting and font preload; the comparison Tailwind versus CSS Modules shows how much CSS each approach produces.
Frequently asked questions
How much CSS should the critical part hold?
A few rules: reset, base typography, header and hero. Past 14 KB inlined the gain disappears, because the HTML grows on every page and is not cached.
Do I still need critical CSS with HTTP/2?
Yes. HTTP/2 lowers the cost of several requests, not the time the browser stays blocked by a sheet it does not have yet. The critical part removes that block.
How do I generate it without loading the production page?
Run critical against a local server with the full build, pointing base and dest at it. Ship the result with the deploy instead of computing it at runtime.
What happens to visitors who run no JavaScript?
The noscript tag serves the full sheet. Without it the page keeps only the critical rules and loses every style below the fold.
Does inline CSS hurt caching?
Yes, each page carries its own critical part inside the HTML and cannot share it. That is why it must stay short and be regenerated only when the layout changes.