GitHub

CSS Optimization

Critical CSS: Inline Above-the-Fold Styles

CSS is render-blocking by default — the browser won’t paint anything until it has downloaded, parsed, and built the CSSOM from all linked stylesheets. On a 3G connection, even a 50KB CSS file can delay first paint by several hundred milliseconds. Critical CSS extraction solves this by inlining the minimum styles needed for above-the-fold content directly in the HTML <head>, then loading the rest asynchronously.

The goal is to keep inlined critical CSS under 14KB compressed — the maximum payload deliverable in the first TCP roundtrip due to TCP slow start. Everything above that threshold adds an extra roundtrip before first paint.

Critical (by Addy Osmani) is the most established tool. It uses Penthouse under the hood to launch a headless Chromium, render the page at specified viewport dimensions, and extract only the CSS rules that apply to visible elements. It supports multiple viewport sizes, automatic inlining, and removal of critical rules from the deferred stylesheet. Integration works via Gulp, Webpack, or the Node.js API directly.

Critters (by Google Chrome Labs) takes a different approach — instead of headless rendering, it analyzes the HTML statically and inlines all CSS rules matching elements in the document. This makes it dramatically faster (no browser launch), but it inlines all used CSS, not just above-the-fold CSS. For SSR’d Single Page Applications where the initial HTML represents the above-the-fold state, this distinction often doesn’t matter. Critters supports data-critters-container markers to hint at viewport boundaries, and /* critters:exclude */ comments to control inclusion.

The async loading pattern for remaining CSS:

<head>
  <!-- Inlined critical CSS -->
  <style>/* critical styles here, <14KB */</style>

  <!-- Async load full stylesheet -->
  <link rel="preload" href="styles.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

For framework integrations: Next.js automatically inlines critical CSS when using CSS Modules or styled-jsx. Astro has astro-critical-css integration wrapping Critical. Vite projects can use vite-plugin-critical for build-time extraction.

Resources:

CSS-in-JS: The Zero-Runtime Revolution

The traditional CSS-in-JS approach (styled-components, Emotion) generates styles at runtime in the browser — parsing template literals, computing styles, and injecting <style> tags into the DOM on every render. This incurs measurable cost: larger JavaScript bundles, main-thread style computation, and incompatibility with React Server Components (which can’t run client-side JavaScript). The industry has decisively shifted toward zero-runtime CSS-in-JS: libraries that compile styles to static CSS at build time, shipping no JavaScript for styling.

vanilla-extract is the most mature zero-runtime solution. You write styles in TypeScript files (.css.ts), and they compile to standard CSS with locally scoped class names at build time. It provides full type safety, theming via CSS custom properties, and a sprinkles API for type-safe atomic CSS. vanilla-extract integrates with Vite, webpack, esbuild, and Next.js, and is used by Shopify’s Polaris and other large design systems.

Panda CSS (from the Chakra UI team) combines the developer experience of CSS-in-JS with zero-runtime output and a utility-first approach inspired by Tailwind. Styles are defined using a css() function or JSX style props, but are extracted at build time via static analysis. Panda offers full TypeScript autocomplete, token-based design systems, conditional styles (responsive, hover, dark mode), and recipes for component variants. It draws from the best of Chakra UI, vanilla-extract, Stitches, Tailwind, and Styled System.

Pigment CSS is MUI’s (Material UI) zero-runtime solution, developed to make MUI components compatible with React Server Components. Built on ideas from Linaria and Compiled, it extracts styled() and sx prop styles at build time. This is significant because MUI is the most widely used React component library — its migration away from Emotion’s runtime CSS-in-JS signals the direction of the entire ecosystem.

CSS Modules remain the simplest zero-runtime option: standard CSS files with automatic local scoping via build-tool class name hashing. No new API to learn, no runtime cost, excellent caching (CSS is a separate cacheable file), and broad framework support. For teams that don’t need the dynamic expressiveness of CSS-in-JS, CSS Modules offer the best performance-to-complexity ratio.

Resources:

Tailwind CSS v4: The Oxide Engine

Tailwind CSS v4.0, released January 22, 2025, is a ground-up rewrite that replaces the Node.js/PostCSS pipeline with a Rust-powered engine called Oxide, integrated with Lightning CSS for parsing, vendor prefixing, and minification. The performance gains are massive: full builds are 3.5–10× faster (median dropping from 378ms to 100ms on the Catalyst UI kit), incremental builds are 8× faster (44ms → 5ms), and incremental builds that don’t produce new CSS are over 100× faster, completing in microseconds. Hot module replacement for style changes is essentially instantaneous.

The architectural changes go beyond speed. Tailwind v4 is now a CSS-first framework:

CSS-first configuration replaces tailwind.config.js with @theme directives directly in your CSS. Design tokens become CSS custom properties available natively in the browser, enabling runtime theme switching without rebuilds. Configuration is a single @import "tailwindcss" line.

Zero-configuration content detection automatically finds template files — via Vite’s module graph (most accurate, no false positives) or filesystem crawling with .gitignore heuristics. No content array to maintain.

Built on modern CSS features including cascade layers (@layer), registered custom properties (@property), color-mix(), and P3 color gamuts via OKLCH. The output CSS uses @layer base, components, utilities for deterministic specificity ordering.

Unified toolchain — Tailwind v4 bundles @import resolution, vendor prefixing (via Lightning CSS), and minification. No separate postcss-import or autoprefixer configuration needed. The @tailwindcss/vite plugin provides even faster builds than the PostCSS plugin by leveraging Vite’s native module graph.

For existing projects, the npx @tailwindcss/upgrade tool handles ~90% of the migration from v3 automatically, including renaming legacy class aliases (e.g., flex-shrink-0 → shrink-0) and converting JavaScript configuration to CSS @theme directives.

Resources:

Cascade Layers (@layer): Ending Specificity Wars

CSS Cascade Layers, available in all modern browsers since 2022 (Chrome 99+, Firefox 97+, Safari 15.4+, >96% global support in 2026), introduce a new level of cascade control that sits above specificity. Layer priority is evaluated before selector specificity, meaning a simple .btn selector in a higher-priority layer beats #main .sidebar .content .btn.btn-primary in a lower layer — regardless of specificity. This is a fundamental shift in how CSS conflicts are resolved.

Layers are declared with @layer and their priority is determined by declaration order (last declared wins):

/* Declare layer order — last layer has highest priority */
@layer reset, base, components, utilities, overrides;

/* Third-party resets go in the lowest layer */
@layer reset {
  *, *::before, *::after { box-sizing: border-box; margin: 0; }
}

/* Design tokens and typography */
@layer base {
  body { font-family: system-ui; line-height: 1.5; }
}

/* Component styles */
@layer components {
  .btn { padding: 0.5rem 1rem; border-radius: 0.25rem; }
}

/* Utilities always win over components */
@layer utilities {
  .text-center { text-align: center; }
}

The killer use case is taming third-party CSS. Import a framework’s styles into a low-priority layer, and your component styles in a higher layer will always win — no !important needed, no specificity hacks:

@layer framework, custom;
@import url("bootstrap.css") layer(framework);

@layer custom {
  .btn { /* always overrides Bootstrap's .btn */ }
}

Tailwind CSS v4 uses layers internally: @layer base, components, utilities ensures utility classes always override component classes regardless of source order. This is why Tailwind v4 styles are more predictable than v3.

An important subtlety: !important within layers reverses priority order (inner/lower layers’ important declarations beat outer/higher layers’), following the same logic as user-agent vs. author style !important inversion. Use !important in layers sparingly and understand the inversion.

Resources:

CSS @scope: Native Style Scoping

CSS @scope, now supported in all major browsers as of December 2025 (Chrome 118+, Safari 17.4+, Firefox 146+), provides native style scoping without Shadow DOM, BEM naming conventions, CSS Modules, or build tools. It confines selectors to a DOM subtree with both an upper bound (scope root) and optional lower bound (scope limit), creating what’s called a “donut scope” — styles apply within the ring but stop at the inner boundary.

/* Styles apply inside .card but NOT inside .card-content */
@scope (.card) to (.card-content) {
  h2 { font-size: 1.2rem; color: var(--heading); }
  p { color: var(--text-muted); }
  /* These styles won't leak into nested .card-content or its children */
}

The donut scope pattern is the unique capability that no other CSS methodology offers — neither BEM, CSS Modules, nor CSS-in-JS can prevent a parent’s styles from reaching into nested sub-components. Only @scope with the to keyword provides this native boundary.

@scope also introduces scoping proximity as a new cascade criterion, slotted between specificity and source order. When two @scope rules with equal specificity target the same element, the one whose scope root is closer in the DOM tree wins. This elegantly solves the classic nested theme problem (light theme inside dark theme inside light theme) without JavaScript or complex selector chains.

As Chris Coyier noted at CSS Day 2025, CSS is fundamentally about scope — selectors, media queries, container queries are all scoping mechanisms. @scope makes this explicit and adds the proximity dimension that was previously impossible. For component libraries, @scope means styles are self-contained without the weight of Shadow DOM or the build-tool dependency of CSS Modules.

Resources:

content-visibility: Skip Rendering Off-Screen Content

content-visibility: auto is one of the highest-impact, lowest-effort CSS performance properties available. It tells the browser to skip layout, paint, and rendering for off-screen elements until they approach the viewport, while maintaining accessibility (content remains in the DOM, accessible to screen readers, and searchable with find-in-page). It became Baseline Newly Available in September 2025 with support across all three major engines.

The web.dev article by the Chrome team demonstrated a 7× rendering performance improvement on an article demo by applying content-visibility: auto to content sections. DebugBear’s testing on their own blog (200+ posts) showed measurable improvements in Style, Layout, and Paint metrics. For long pages with heavy off-screen content, scrollable lists, or complex DOM structures, it’s often the single biggest rendering optimization you can make.

The critical companion property is contain-intrinsic-size, which reserves space for unrendered elements to prevent scrollbar jumping and layout shifts:

/* Apply to repeating content sections below the fold */
.article-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* For scrollable lists */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

The auto keyword in contain-intrinsic-size: auto 500px tells the browser to remember the actual rendered size once the element has been displayed, using it for subsequent off-screen calculations instead of the placeholder. This means accuracy improves over time as the user scrolls.

content-visibility: auto directly improves INP by reducing the rendering work on the main thread during interactions. When users interact with a page, the browser only needs to process the visible content, freeing the main thread to respond to input faster.

It’s essentially a CSS-only virtual scroll — you get most of the performance benefits of virtualized lists (like TanStack Virtual) without the complexity of managing scroll positions, item heights, or JavaScript-controlled rendering. The trade-off: Safari currently doesn’t make content-visibility: auto content findable via find-in-page (though it’s in the accessibility tree), so test cross-browser behavior.

Resources:

Native CSS Nesting: Dropping the Preprocessor

Native CSS nesting, supported in all modern browsers since 2023 (Chrome 112+, Firefox 117+, Safari 16.5+, 96%+ global coverage in 2025), eliminates one of the last major reasons to use Sass or Less. You can nest selectors, media queries, container queries, and other at-rules directly in your .css files with no build step.

.card {
  padding: 1.5rem;
  border-radius: 0.5rem;

  & h3 {
    margin: 0 0 0.5rem;
    font-size: 1.25rem;
  }

  & p { color: var(--text-muted); }

  &:hover { box-shadow: 0 4px 12px rgba(0,0,0,0.1); }

  &.card--featured { border: 2px solid var(--accent); }

  /* Nest media queries directly */
  @media (min-width: 768px) {
    & { padding: 2rem; }
  }

  /* Nest container queries */
  @container sidebar (min-width: 300px) {
    & { flex-direction: row; }
  }
}

The & is required for element selectors to disambiguate from property declarations. Unlike Sass, native CSS nesting does not support selector concatenation (&--modifier won’t expand to .card--modifier), so BEM modifiers need the full class repeated. Nested at-rules (@media, @container, @supports) can be nested directly without &.

The performance consideration: Sass compiles nested selectors to flat CSS before shipping to the browser. With native nesting, the browser parses the nested structure directly. In practice, this parsing overhead is negligible for reasonable nesting depths (the universal recommendation: avoid nesting deeper than 3 levels). The DX benefits — colocated styles, reduced repetition, smaller stylesheet file sizes — outweigh any micro-overhead.

Combined with custom properties, container queries, and cascade layers, native CSS nesting means Sass is no longer needed for most projects as of 2025. The remaining Sass advantages (mixins, functions, @extend, partials/file splitting, complex loops) are being addressed by upcoming native CSS features.

Resources:

Registered Custom Properties (@property): Type-Safe, Animatable Variables

The @property at-rule (part of CSS Houdini, Baseline since July 2024) lets you register custom properties with a declared type (syntax), inheritance behavior, and initial value. This transforms CSS variables from opaque strings into typed, validated values that the browser can interpolate — unlocking smooth animation of properties that were previously impossible to transition, such as gradients, individual transform components, and color channel values.

@property --gradient-angle {
  syntax: "<angle>";
  inherits: false;
  initial-value: 0deg;
}

.element {
  background: linear-gradient(var(--gradient-angle), #3490dc, #6574cd);
  transition: --gradient-angle 0.8s ease;
}
.element:hover {
  --gradient-angle: 180deg;
}

Without @property, the browser sees --gradient-angle as a string and can only animate it discretely (instant snap). With registration, the browser knows it’s an <angle>, can interpolate between values, and transitions smoothly.

Performance implications: web.dev benchmarks show that registered custom properties with inherits: false are significantly faster for style invalidation than unregistered properties (which always inherit). When you change a non-registered variable, the browser must re-evaluate the entire subtree for inheritance. With inherits: false, the invalidation scope is contained. For properties used in animations or frequently updated via JavaScript (theme toggles, scroll-driven effects), registration reduces style recalculation cost.

The @property rule enables:

  • Gradient animation: Register color stops as <color> types and animate between them smoothly.
  • Individual transform animation: Decompose transform into separate --rotate, --scale, --translate properties for independent animation timelines.
  • Type-safe theming: Catch invalid token assignments at the CSS level with fallback to initial-value.
  • Scroll-driven effects: Feed <number> or <percentage> registered properties into calc() expressions for GPU-friendly animations.

Resources:

Removing Unused CSS

CSS frameworks ship thousands of selectors, but most pages use only a fraction. The median Tailwind CSS output before purging can exceed 3MB; after purging, it’s typically 5–15KB. Removing unused CSS reduces file size, parse time, and style calculation cost.

PurgeCSS is the standard tool. It analyzes your content files (HTML, JSX, Vue, Svelte, etc.) and CSS files, matching selectors against content to remove unreferenced rules. PurgeCSS works through a simple but effective extractor system — it scans content for strings that could be class names and keeps matching selectors. Tailwind CSS v4 integrates an equivalent process internally via its JIT engine (only generating CSS for classes actually used), so separate PurgeCSS isn’t needed for Tailwind projects.

cssnano (PostCSS-based) handles CSS minification — removing whitespace, duplicate rules, comments, and merging overlapping declarations. It’s often used after PurgeCSS for maximum reduction.

Chrome DevTools Coverage tab shows which CSS (and JS) bytes are actually used on a given page. Open DevTools → Coverage tab → reload the page, and it highlights unused bytes in red. This is invaluable for identifying which stylesheets have the most waste before setting up automated removal.

For framework-specific approaches: Next.js automatically tree-shakes CSS Modules (unused exports are removed). Vite’s CSS code-splitting creates per-route CSS chunks. Astro’s zero-JS-by-default architecture means only the CSS for rendered components is included.

Resources:

The Horizon: Native CSS Mixins, Functions & What’s Next

The CSS specification is evolving faster than ever, with several features that will further reduce the need for preprocessors and JavaScript:

CSS Mixins (@mixin / @apply) are in active development, with a prototype available in Chrome Canary behind a flag as of March 2025. The syntax is clean and familiar to Sass users:

@mixin --sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
}

.visually-hidden {
  @apply --sr-only;
}

Mixins are distinct from functions: mixins return declarations (property-value pairs), while functions return values used within declarations. Both are being designed as part of the CSS Functions and Mixins Module. Miriam Suzanne’s explainer at OddBird documents the design decisions and open questions. The State of CSS 2025 survey shows mixins as the most-requested missing feature.

CSS Functions (@function) allow defining reusable value computations in CSS. Bramus Van Damme (Chrome team) has published introductory demos, and a prototype is also available in Canary.

Native CSS Masonry (grid-template-rows: masonry) is shipping, enabling Pinterest-style layouts without JavaScript. Gap Decorations (column-rule / row-rule for grid/flex) allow styling gaps between grid tracks without pseudo-elements. reading-flow fixes the accessibility problem where visual order (from flex reordering or grid placement) diverges from DOM/tab order.

Relative color syntax (oklch(from var(--base) ...)) and color-mix() have reached full cross-browser baseline, enabling entire color palette generation from a single token — no Sass color functions needed.

Resources: