Critical CSS: Visible Area Loaded in Milliseconds

To understand why Critical CSS is so effective, you need to understand the browser's rendering process. When the browser receives an HTML document, it builds the DOM tree (Document Object Model). In parallel, it loads referenced CSS files and builds the CSSOM tree (CSS Object Model). Only when both trees are fully constructed can the browser create the Render Tree -- the combination of DOM and CSSOM that determines which elements are visible and how they are displayed. Until the CSSOM is complete, the browser renders nothing.

This behavior is intentional: the browser waits for CSS to prevent a Flash of Unstyled Content (FOUC) -- the brief flash of unstyled HTML before CSS is loaded. Without this blocking, the user would first see raw text without layout, colors or typography that then suddenly snaps into the styled design. This is a poor user experience that the browser prevents through render-blocking.

The problem arises when CSS files are large and take long to load. A typical Shopware installation loads 150-300 KB CSS (uncompressed), a WordPress theme with multiple plugins 200-500 KB. Even with Brotli compression to 40-80 KB, the download on a 3G mobile connection takes 300-800 milliseconds -- time during which the user sees a white screen. Critical CSS reduces render-blocking time to the duration the browser needs to parse 5-14 KB of inline CSS: typically under 50 milliseconds.

Critical CSS (also called Critical-Path CSS or Above-the-Fold CSS) is the minimal subset of all CSS rules on a page needed for rendering the visible area (viewport). This includes all CSS rules applied to elements visible on initial page load: header, navigation, hero area, first text sections and their layout, typography, colors and spacing.

Extracting Critical CSS is conceptually simple: determine which HTML elements are visible in the initial viewport, collect all CSS rules applied to those elements (including media queries, pseudo-elements and inherited styles) and remove everything else. In practice, this process is complex because it depends on the viewport (mobile vs. desktop), dynamic content (JavaScript-rendered elements) and CSS specificities (a rule for an element below the fold can affect styles for an element above the fold).

The ideal Critical CSS size is under 14 KB (compressed). This value is not arbitrary: the TCP protocol uses an Initial Congestion Window of typically 10 TCP segments (approximately 14,600 bytes). Everything that fits in this first window is transmitted in a single network roundtrip. If the HTML document including Critical CSS stays under 14 KB, the browser can render the visible area after the first roundtrip -- without waiting for additional data packets (Source: Google, 2024).

Critical CSS extraction can be done manually or automated. Manual extraction is practical for small websites with few template types: the Chrome DevTools Coverage function (Ctrl+Shift+P, 'Coverage') shows for each CSS file which rules are used on the current page and which are not. Unused rules are removed, used rules for the above-the-fold area are identified and extracted into a separate Critical CSS file.

For larger websites and automated workflows, specialized tools exist. Penthouse (Node.js) opens the page in a headless Chrome, determines the viewport and extracts all CSS rules for visible elements. Critical (npm package by Addy Osmani) builds on Penthouse and additionally offers the ability to inline Critical CSS directly into the HTML and load the remaining CSS asynchronously. Critters (Google, Webpack plugin) takes a different approach: instead of rendering the page, it statically analyzes CSS selectors and identifies which elements are present in the HTML.

Each tool has strengths and weaknesses. Penthouse and Critical deliver the most precise results because they actually render the page -- they account for JavaScript-generated content, media queries and dynamic styles. The downside: they require a headless browser and are slower (1-5 seconds per page). Critters is significantly faster but cannot detect JavaScript-generated elements. For most projects we recommend Critical as a build-time tool integrated into the frontend optimization process.

Critical CSS can be embedded in two ways: as an inline