Critical CSS

Original Article ↗ Hacker News Discussion ↗

Tool and Implementation

  • Web app extracts “critical CSS” for a URL using Puppeteer and the Penthouse library, with a configurable delay after page load.
  • Author notes main difficulty was running headless Chrome on Cloud Run; existing hosted tools failed for dynamic pages because they didn’t wait long enough.
  • Several commenters want it as a library or build‑step plugin (Vite/Astro, SSR/SSG) rather than a manual copy‑paste tool.

Bugs, Limitations, and Feature Requests

  • Errors reported when:
    • A site has no external CSS, or CSS is only inline (<style>), leading to “css should not be empty”.
    • CSS is missing entirely.
    • Used in Safari; some users see “done” with an empty result.
  • Edge case: site without CSS throws an error instead of a friendly message.
  • Suggestions:
    • Handle responsive variants and dedupe breakpoint rules.
    • Optionally strip unused custom properties / variables to minimize payload.
    • Improve UX around errors and support inline CSS.

Value of Critical CSS (Pros & Cons)

  • Pro:
    • Helpful for large, legacy, or template/WordPress sites with megabytes of CSS where manual extraction is painful.
    • Can boost Lighthouse scores, improve first paint on low‑end devices/slow networks, and matters for SEO‑sensitive or ad‑driven sites.
    • Some teams report clients explicitly demand 100/100 Lighthouse, making these optimizations commercially important.
  • Con:
    • Many see it as premature or benchmark‑driven optimization in an era of HTTP/2, CDNs, and caching.
    • Overhead: extra complexity, risk of layout shifts, bigger HTML per page, and incompatibility with strict CSPs (no inline styles).
    • Several argue better returns from simply writing clean, small CSS and avoiding bloated frameworks/builders.

Loading Strategies & CSP / FOUC Concerns

  • Debate over placing non‑critical CSS at end of <body> vs using <link rel="preload" as="style" onload="this.rel='stylesheet'" and similar techniques.
  • Some warn the JS “async CSS” preload hack can conflict with CSP (no unsafe-inline) and cause multiple reflows.
  • Critical CSS must fully cover above‑the‑fold to avoid FOUC/CLS; otherwise this becomes a “footgun”.
  • Strict CSP setups may disallow inline <style>; nonces and hashes are proposed but seen as operationally and security‑wise contentious in some orgs.

Performance, Caching, and Bandwidth Tradeoffs

  • One camp emphasizes latency: inlining small critical CSS can avoid an extra round trip for the first view, especially under high RTT.
  • Others stress caching: external stylesheets are fetched once and reused; inlining critical CSS into every page is “anti‑caching” and wastes bandwidth, especially for repeat visitors.
  • Disagreement over whether the micro‑gain (tens of ms) is worth more than added bytes and complexity, particularly when average JS payloads are already massive.
  • Some suggest only serving critical CSS on likely first‑hit or landing pages, but note difficulty reliably detecting first‑time visitors.

Alternatives and Broader Frontend Philosophy

  • Alternatives mentioned: style budgets, mobile‑first CSS, reducing overall stylesheet size, atomic/tailwind‑style systems, HTML that works without CSS, and tools like beasties/critters or mod_pagespeed.
  • Several argue that modern CSS features (variables, content‑based units, layout primitives) and simple markup often eliminate the need for “above‑the‑fold” slicing altogether.
  • Others counter that in the real world, developers inherit messy stacks; for them, an automated critical‑CSS extractor remains very appealing.