Detailed explanation
Critical CSS is the smallest practical set of styles required to render a page’s initial viewport, often called above-the-fold content. It typically includes layout, typography, colours, and responsive rules for visible elements such as the header and hero section. These styles are inlined in a <style> element inside the document’s <head>, while the remaining stylesheet is loaded without blocking the initial render. The goal is not to reduce the total CSS automatically, but to put essential styling on the fastest path to the screen.
Normally, a matching external stylesheet linked with rel="stylesheet" is render-blocking. The browser discovers it while parsing HTML, downloads it, and builds the CSS object model, which combines with the DOM to support rendering. Until blocking stylesheets are ready, the browser generally delays painting page content to avoid displaying it unstyled. Inlining critical rules removes the separate network request for those rules. Once enough HTML and other rendering prerequisites are available, the browser can paint the initial content without waiting for the complete stylesheet.
In the example, rel="preload" with as="style" fetches main.css early but does not apply it as a stylesheet. The onload handler changes rel to "stylesheet", allowing the downloaded CSS to take effect. A <noscript> stylesheet fallback supports users with JavaScript disabled; restrictive Content Security Policy settings may also require an alternative to inline event handlers. This approach can improve First Contentful Paint and may improve Largest Contentful Paint when CSS was delaying the largest visible element. It cannot eliminate delays caused by slow HTML delivery, images, fonts, or scripts.
Correct extraction is the difficult part: critical styles must cover the relevant viewport, route, inherited properties, and dependencies such as custom properties. Missing rules can cause flashes of unstyled content or layout shifts; excessive inline CSS increases HTML size and cannot be cached separately across pages. Teams commonly automate extraction during builds and verify representative pages and screen sizes. Interviewers expect these trade-offs, plus measurement using browser performance traces and real-user metrics rather than assuming that inlining always helps.
Key points to remember
- Inline only the CSS needed for the initial viewport, including essential dependencies.
- Defer the remaining CSS; leaving a full render-blocking stylesheet can undermine the benefit.
- Preloading downloads CSS but does not apply it until the link becomes a stylesheet.
- Critical CSS can improve FCP and CSS-limited LCP, but does not solve every rendering bottleneck.
- Validate responsive coverage, layout stability, HTML size, caching trade-offs, and CSP compatibility.
Common mistakes candidates make
- Inlining the entire stylesheet, unnecessarily increasing HTML size and sacrificing separate caching.
- Assuming rel="preload" applies CSS automatically or forgetting JavaScript-disabled and CSP considerations.
- Extracting styles for only one page or viewport and claiming improvements without measuring.
Likely follow-up questions
How do you identify critical CSS?
Use build-time tools that render representative routes at selected viewport sizes and extract the rules required for visible content. Review the output for inherited styles, custom properties, responsive rules, and states that automated extraction may miss.
How is critical CSS different from removing unused CSS?
Critical CSS prioritises when styles become available, while removing unused CSS reduces stylesheet size by eliminating rules the application does not need. Below-the-fold styles are non-critical for the initial viewport but are not necessarily unused.
Can critical CSS make performance worse?
Yes: excessive inlining enlarges HTML, and aggressively preloading non-critical CSS can compete with more important resources. Incomplete extraction can also cause visual changes when the full stylesheet arrives, so compare loading metrics and layout stability before and after implementation.
Interview tip: Explain the render-blocking problem first, walk through the preload-to-stylesheet switch, and finish with one measurable benefit and one trade-off.