Lessons Learned from Building a CSS Minifier • Stoyan Stefanov • GOTO 2014

Summary: CSS performance, minification, and CSS Shrink

Motivation: CSS is performance-critical

Browsers treat CSS as a rendering “critical path”—they generally wait for CSS to arrive before rendering.

The talk also highlights perceived slowness thresholds: users start noticing delays after roughly ~200ms if meaningful UI isn’t shown quickly.

Strategies for dealing with CSS blocking

Key approaches include splitting styles so that the “most needed” CSS arrives first:

• Split CSS into critical vs. later styles
  • Deliver top-of-page “critical” CSS first.
  • Load remaining styles later via async patterns.
• Inline critical CSS
  • Optionally inline critical CSS directly at the top of the HTML.
  • Tradeoffs:
    • Reduced caching benefits
    • Larger HTML payload

Real-world examples mentioned

• Google-like strategies: inline CSS for faster first render.
• Facebook Social Plugins / Bing-style approach:
  • Inline on the first load
  • Use a cookie to prevent re-inlining on subsequent visits.
• Guardian-like strategy:
  • Store CSS in localStorage and reuse it.

Why CSS becomes hard over time

CSS is described as easy to begin with, but it grows complicated due to:

• Specificity
• Cascade
• Inheritance
• The tendency for longer selectors to override earlier rules
• Refactoring difficulty as the stylesheet tangles

A common symptom: devtools show many unused or crossed-out rules, yet the payload cost still impacts users.

Core message: write your own CSS transformation tools

The talk encourages developers to build CSS parsing/transformation tools, similar in spirit to JS transpilers.

The goal is not only “polyfills,” but syntax transpilation and structural transformations to:

• make CSS usable across older environments
• optimize payload size

Review/analysis of existing minifiers

Existing CSS minifiers generally fall into two categories:

1. Regex-based minification (often fragile)
2. “Partial parsing” minification
   • Builds an AST-like structure
   • But does not fully and robustly handle values/properties

Typical problems with regex/partial parsing

• Shorthand properties and complex declarations are hard to handle reliably
• Some values (e.g., backgrounds, gradients) require a real parser to be safe
• Subtle correctness issues occur (e.g., spacing around +)

How the speaker’s tool is built: “CSS Shrink”

Background

• Initially supported a Yahoo/YUI CSS minifier (Java, regex-based)
• Later rewrote tooling in JavaScript

Parsing and tooling approach

The speaker experimented with JS parsers and ultimately used richer parsing:

• gonzales parser for a detailed AST (Abstract Syntax Tree)
• A separate library for safe formatting/minification steps (described as “pretty ugly”)

Architecture and delivery

• Command-line install via npm
• Also includes a web UI (leveraging browser tooling)
• Shows:
  • before/after byte savings
  • structural changes (e.g., merged media queries)

Key minification transformations implemented

Safe whitespace and comment removal

• Removes whitespace/comments while being aware that space can matter in certain contexts.

Color minification

• Uses an npm color library to output the shortest valid form
• Supports additional targets such as HSL (optional)

Numeric simplifications

• Remove units for zeros (except where required, such as angles)
• Remove % when safe (e.g., 0 instead of 0%)
  • but keep % where required (e.g., keyframes)
• Strip leading zeros

Quote normalization

• Remove unnecessary quotes in contexts like comma-separated lists (e.g., font-family)
• Normalize quoting style (settled on double quotes)
• Convert single → double quotes in contexts where required

Shorter token forms and legacy tweaks

• Convert from to 0% when shorter and valid
• Convert 100% to two (described as intended as 2)
• Pseudoselector shorthand and legacy IE syntax tweaks (with caveats)

IE filter / legacy syntax shortening

• Mentions older IE opacity filter syntaxes
• Includes a shorter alpha/IE4-style variant
• Discusses (but downplays) Microsoft’s performance warning, suggesting it was negligible in modern contexts

Value normalization

• Normalize bold ↔ numeric equivalents depending on shortest valid representation
• Normalize casing to improve gzip reuse benefits for repeated lowercase strings

Structural CSS optimizations

The tool also performs CSS structural improvements, such as:

• Remove empty rule sets
• Remove duplicate declarations within a block (same key + value)
• Merge adjacent media queries when compatible (after transformation)
• Remove unused/meaningless fonts in fallbacks
  • e.g., redundant generic fonts after an already-generic font
• Remove invalid/unnecessary properties/values
  • notes this can be unsafe without full validation; suggests an “advanced mode”
• Remove duplicate keyframes when the same name appears multiple times (last wins)

Not fully implemented / in progress

• Full shorthand property minimization (explicitly not finished)
• Unit conversions like milliseconds → seconds (partly discussed/partly commented out)
• Selector “deep” correctness for some transformations requires validation

Testing strategy for correctness

Because CSS transformations are risky (tiny changes can break layout across browsers), the approach emphasizes:

• Divide-and-conquer
• Many small packages/components
• Pixel-perfect visual testing:
  • Transform CSS
  • Render HTML before/after
  • Compare screenshots pixel-by-pixel
  • Fail if even one pixel differs

Tools mentioned:

• PhantomJS
• References to other engines such as TrioJS (for IE)
• Later mention of DJs as a promising alternative for real-browser loading

Additional optimization ideas: browser-specific CSS

The talk proposes sending only what a browser needs based on capabilities:

• Server-side browser sniffing
• Example with Bootstrap:
  • compiling for older IE reportedly reduced payload by ~48%

Also mentioned:

• Generating separate bundles for:
  • IE6–11
  • Chrome vs Firefox
• Rationale: minification alone can’t reliably remove whole blocks/properties unless you target known browser support.

Learning/resources pointers

Recommendations focused on architectural and long-term CSS learning:

• Nicholas Zalas presentations
• Object-Oriented CSS
• SMACSS (“CSS for grown-ups” / “CSS for grumpy old men”)

Status / claims

• “CSS shrink” is not yet production-ready
• No benchmark results yet
• Speaker suggests it “should” become best-in-breed once all planned transformations are in place.

---

Main speakers / sources (as stated in the talk)

Speaker

• Stoyan Stefanov (Facebook software engineer; presented the CSS minifier project as a personal pet project)

Referenced people/tools

• Patrick (The Guardian) (slide about blank-page waiting for CSS)
• Douglas Crockford (quote describing CSS as long/fragile/self-contradictory)
• Brett S… / Brett Szym… (credited as inspiring the parser direction; referenced as “Brett mentioned…”)

Referenced parsers/minifier tooling

• Mench (CSS parser)
• Nicholas Zakas parser (used in CSS lint)
• TJ Holowaychuk (mentioned via rework tool and CSS tools)
• Gonzales (richer AST parser used for the tool)

Referenced testing/rendering tools

• PhantomJS
• TrioJS (mentioned for IE)
• DJs (mentioned as a promising alternative)