Critical CSS extraction without a headless browser
By Otto Schaaf
The headless browser problem
Critical CSS — the minimal set of styles needed to render above-the-fold content — is one of the most impactful web performance optimizations. By inlining it directly into the HTML <head>, you eliminate render-blocking stylesheet requests and let the browser paint meaningful content faster. The trouble is how most tools extract it.
The standard approach today involves spinning up a headless Chromium instance, navigating to the target page at multiple viewport sizes, and recording which CSS rules were actually applied to elements visible in the viewport. Tools like Critical, Penthouse, and CriticalCSS all follow this pattern. It works, but it comes with serious operational costs.
First, there is the resource footprint. A headless Chromium process consumes 200-400 MB of memory and takes 2-5 seconds per page to render and evaluate. If you are processing thousands of pages across a large site, you need a pool of browser instances, careful queuing, and crash recovery logic. Second, headless browsers introduce a fragile dependency chain. Chromium updates can change rendering behavior, break Puppeteer APIs, or shift element geometry in ways that alter which CSS rules are considered critical. Third, there is the latency problem: you cannot extract critical CSS on-the-fly during a request because the extraction itself takes seconds. You must run it as a batch job, which means your critical CSS may be stale when it is finally served.
For a system like ModPageSpeed 2.0 that operates at the reverse-proxy level with no application changes, requiring a headless browser would be a non-starter. The optimization process must be lightweight, self-contained, and fast enough to run asynchronously for every new page the worker encounters.
Our heuristic approach
ModPageSpeed 2.0 takes a fundamentally different path. Instead of rendering the page in a browser, the factory worker scans the HTML statically and matches CSS selectors against the DOM structure using tuned heuristics. The process unfolds in four steps within the factory worker.
First, when the nginx interceptor records a cache miss for an HTML page, it stores the original response at the default capability mask and sends a fire-and-forget notification to the worker over a Unix socket. The worker reads the HTML back from the shared Cyclone cache and feeds it to the HtmlScanner, which parses the document and collects elements with their tag names, IDs, classes, and DOM depth — without modifying the HTML.
Second, the scanner gathers all CSS available for the page: inline styles from <style> tags, plus external stylesheets referenced by <link rel="stylesheet"> elements. External CSS is looked up from the Cyclone cache, where it may already have been stored by a previous request. The worker combines all CSS into a single input for the extractor.
Third, the CriticalCssExtractor evaluates every CSS rule against the collected elements and the configured heuristics. It produces a filtered subset of rules — the critical CSS — along with statistics about how many rules were total versus how many were retained.
Finally, the InjectCriticalCss function inserts the extracted CSS into the HTML as a <style data-pagespeed-critical> block. The injection follows a fallback chain: it prefers inserting before </head>, falls back to before </body>, then after <head>, and as a last resort, at the document start. The modified HTML is written back to the cache as a variant at the requesting client’s capability mask.
This entire pipeline — scan, gather, extract, inject — completes in single-digit milliseconds. There are no external processes, no browser binaries, and no network calls beyond the shared-memory cache reads.
Which selectors matter
The heuristic engine in CriticalCssExtractor uses a layered set of rules, each with a clear rationale drawn from analysis of common website structures.
Always included regardless of element matching. Universal selectors (*), html, body, and :root are included unconditionally. These selectors set base typography, box-sizing resets, CSS custom properties, and background colors that affect every page. Excluding them would cause a visible flash of unstyled content on almost any site.
Included by element position. The first 25 DOM elements (configurable via CriticalCssConfig::max_elements) are treated as above-the-fold. Any CSS rule whose selector matches one of these elements is included. The threshold of 25 was chosen because it typically captures the full header, navigation bar, hero section, and the beginning of the main content area. For most layouts, that covers everything visible in a 1080px-tall viewport before scrolling.
Included by semantic patterns. Elements whose tag names, class names, or IDs contain header, nav, hero, banner, masthead, or above-fold are always treated as critical, regardless of their position in the DOM. These naming conventions are used across virtually every CSS framework and custom site, so matching on them catches above-the-fold content that might appear deeper in the DOM due to wrapper elements.
Excluded by depth. Elements deeper than 10 levels in the DOM tree are assumed to be nested within below-the-fold content (deeply nested cards, accordion items, or comment threads). Rules matching only these deep elements are excluded. The depth limit of 10 is generous — most header and navigation structures sit within 4-6 levels of nesting.
Excluded by semantic patterns. Elements matching footer, lazy, defer, below-fold, or lazyload in their classes or IDs are excluded. These are overwhelmingly associated with content that is not visible on initial render. Additionally, entire @media print blocks are excluded, since they never affect screen rendering.
Benchmarks and trade-offs
In testing across a corpus of real-world sites — e-commerce product pages, WordPress blogs, news portals, and single-page application shells — the heuristic extractor typically retains 15-35% of the total CSS rules as critical. The extraction step itself (excluding HTML parsing and cache I/O) completes in under 5 milliseconds for stylesheets up to the 2 MB size limit enforced by the worker’s max_css_size configuration.
The impact on Core Web Vitals is meaningful. Inlining critical CSS eliminates render-blocking requests, which directly improves First Contentful Paint (FCP). On pages with large external stylesheets (common with Bootstrap, Tailwind, or custom frameworks), FCP improvements of 200-500 ms are typical on 3G connections. The worker also stores preload hints at a reserved cache key (mask 0xFFFFFFFF), enabling the nginx module to send 103 Early Hints responses with Link: <url>; rel=preload; as=style headers on subsequent misses, stacking the improvement further.
The honest trade-off is precision. A headless browser knows exactly which pixels are visible; heuristics do not. The extractor will sometimes include rules that are not strictly above-the-fold (a CSS rule targeting .hero-secondary that is only visible after scrolling, for example). This over-inclusion is deliberate: a small amount of extra CSS adds negligible bytes (typically under 2 KB of overhead), while missing a critical rule causes a visible layout shift or flash of unstyled content. Over-inclusion is a cosmetic non-issue; under-inclusion is a user-visible defect. The heuristics are tuned toward the former.
The other trade-off is dynamically-inserted content. If JavaScript inserts a <div class="popup-overlay"> into the DOM after load, the heuristic extractor has no knowledge of it. However, such content is by definition not above-the-fold on initial render, so its CSS is correctly excluded.
Future improvements
Several enhancements are planned for the critical CSS pipeline. The current element-count and depth thresholds are static; a future version will support per-site tuning through the worker configuration, allowing operators to adjust max_elements and max_depth based on their specific layouts.
CSS Container Queries (@container) are becoming widely adopted for component-level responsive design. The selector matching logic will be extended to handle container query blocks, treating them similarly to @media rules with format-specific inclusion heuristics.
The capability mask system already differentiates viewport classes (Mobile, Tablet, Desktop). A natural extension is to store different critical CSS extractions per viewport class, since mobile and desktop layouts often have substantially different above-the-fold content. The cache variant architecture supports this directly — the worker would write separate HTML variants at different mask values, each with viewport-appropriate critical CSS.
Finally, for teams that want to validate heuristic accuracy against ground truth during staging, an optional headless-browser comparison mode is under consideration. This would run the heuristic extraction alongside a Chromium-based extraction on a configurable sample of pages, logging precision and recall metrics without affecting production performance.