How I made cssnano ~30% faster

Introduction

In 2026 I started contributing to cssnano, the CSS minifier that runs at the end of a lot of build pipelines. If you use PostCSS, there's a good chance it processes your CSS on every production build. I came for a couple of correctness bugs, and then I stayed for performance.

cssnano is an old project. The core plugins carry about ten years of edge cases, and most of that code was written to be correct, not fast. For a minifier that's the right priority. But it also means there's room to make it faster without taking risks.

I had one rule for the whole effort: the output must not change. A minifier that produces different bytes after an "optimization" isn't optimized, it's broken. So every change had to keep all fixtures green and produce the exact same CSS, just in less time.

Results first

I measured the full default preset over a set of real framework CSS files — Bootstrap, Bulma, Foundation, UIkit and others. master is 100% of the current time, lower is faster.

Together that's about a third off the default preset, and none of it changed the output.

Before the techniques, a few words about how I measured, because it shaped everything else.

How I measured

My previous post was about colordx, and those wins were mostly V8 micro-optimizations. cssnano was a different kind of problem. The wins here come from not doing work you don't need to do, plus fixing one bad algorithm. To find that kind of thing you need a profiler and an honest benchmark.

The profiler is the easy part. Node ships one:

node --cpu-prof --cpu-prof-dir=./prof run-preset.mjs

You open the .cpuprofile, sort functions by self-time, and the hot spots stop being a guess.

The honest benchmark is harder. A dev machine is noisy. Background processes, garbage collection and CPU scheduling all add time to a run, and they never subtract it. So if you report the median of your runs, one noisy stretch pulls the middle value up, and a real improvement can look like a regression. This happened to me: a 7% win showed up as +4% because one of three rounds got unlucky.

The fix is to report the minimum. Noise can only make a run slower than its true compute time, so the fastest sample you observe is the closest one to "the code with nothing in its way". I run each version many times, interleave the baseline and the branch to spread out drift, and then check that min and median agree before I trust the number.

The other thing to watch is what you compare. Measuring a single plugin in isolation makes its win look huge, because you removed everything else from the pipeline. A plugin that is "64% faster in isolation" might be 2% of the real run. So I report the whole-preset number, because that's the one a user actually feels.

Now the techniques.

1. Skip the selector parser on the common path

postcss-unique-selectors deduplicates the selector list of a rule. For example, a, a, b becomes a, b. To do this correctly — including comments, order and whitespace — it runs the full postcss-selector-parser on every rule, then clones and walks each parsed node to build a key for deduplication.

That's a second parser, called once per rule, over the whole stylesheet.

But most rules don't need any of that. A rule with a single selector has nothing to deduplicate. And the parser only earns its cost when there are comments to strip out of the key. Both cases can be detected with a plain string check, before anything is allocated:

function generateUniqueSelector(selectors) {
  // No comma means a single selector; nothing to dedupe or sort.
  if (selectors.indexOf(',') === -1) {
    return selectors;
  }

  const uniqueSelectors = new Map();
  // Without comments the node's own toString is already a usable key.
  const hasComments = selectors.indexOf('/*') !== -1;

  // ...the full parser path only runs from here
}

A comma anywhere, including inside :is(a, b), still falls through to the real parser, so correctness doesn't change. But the common rule — one selector, no comments — now returns after a single indexOf instead of starting a parser.

That guard is three lines, and it's the −19%. The fastest code is the code you can prove you don't have to run.

2. Skip processors with nothing to do

postcss-merge-longhand collapses longhand properties into shorthands. There are four property families: border, column, margin and padding. The original code ran all four processors on every rule:

css.walkRules((rule) => {
  processors.forEach((p) => {
    p.explode(rule);
    p.merge(rule);
  });
});

Each processor walks the rule's declarations on its own. So a rule that only has color and font-size still gets walked four times, looking for borders and margins that aren't there.

Most rules touch one of these families at most. So I scan the declarations once and run only the processors whose family is actually present:

css.walkRules((rule) => {
  let hasBorder = false;
  let hasColumn = false;
  let hasMargin = false;
  let hasPadding = false;

  for (const node of rule.nodes) {
    if (node.type !== 'decl') continue;
    const prop = node.prop.toLowerCase();
    if (prop.startsWith('border')) hasBorder = true;
    else if (prop.startsWith('column')) hasColumn = true;
    else if (prop.startsWith('margin')) hasMargin = true;
    else if (prop.startsWith('padding')) hasPadding = true;
  }

  if (hasBorder)  { borders.explode(rule);  borders.merge(rule);  }
  if (hasColumn)  { columns.explode(rule);  columns.merge(rule);  }
  if (hasMargin)  { margin.explode(rule);   margin.merge(rule);   }
  if (hasPadding) { padding.explode(rule);  padding.merge(rule);  }
});

The processors were already no-ops on rules without a matching property. They would walk, find nothing and return. This change just moves that "find nothing" check into one cheap pass instead of four expensive ones. The output is identical, and the result is −7%.

(I first wrote this with a bitmask. It was a few microseconds faster and much harder to read, so I threw it away. Four booleans say what they mean.)

3. Remove an O(N²) dedupe scan

This is the one that scales.

postcss-discard-duplicates removes duplicate rules. To find duplicates, it walked each rule and, for every rule, scanned all of its preceding siblings looking for one with the same selector:

function dedupeRule(last, nodes) {
  let index = nodes.indexOf(last) - 1;
  while (index >= 0) {
    const node = nodes[index--];
    if (node && node.type === 'rule' && node.selector === last.selector) {
      // ...merge last's declarations into the earlier rule
    }
  }
}

For N rules at the same level, that's an O(N²) scan. And it's quadratic even when there are no duplicates at all. Every rule still scans every rule before it, finds nothing and moves on. A stylesheet with 4000 unique rules pays the full quadratic cost for no benefit.

The fix is the standard one. Group the rules first, then compare only inside a group:

// One linear pass: bucket rules by selector.
let ruleGroups;
for (let i = 0; i < nodes.length; i++) {
  const node = nodes[i];
  if (node.type === 'rule') {
    if (!ruleGroups) ruleGroups = new Map();
    const group = ruleGroups.get(node.selector);
    if (group) group.push(node);
    else ruleGroups.set(node.selector, [node]);
  }
}

// Each rule now only compares against rules that share its selector.
const group = ruleGroups && ruleGroups.get(last.selector);
if (group && group.length > 1) {
  dedupeRule(last, group);
}

A selector that appears once — the common case — does no comparison work. Document order and last-wins behavior are preserved, so the output doesn't change.

On the framework files this is −7%, the same as the merge-longhand win, because those files have modest rule lists. The real difference shows up when the input grows. Here are synthetic stylesheets of N distinct-selector rules, this plugin only, with master at 100%:

The speedup grows with N, which is the sign that a quadratic term is gone. master roughly triples per doubling of N, while the new version roughly doubles. On a small file you wouldn't notice. On a large generated stylesheet it's the difference between a blip and a stall.

What didn't help

This is the part most posts skip, and it's the more useful one.

I wrote four more "optimizations" and dropped all of them, because the benchmark wouldn't back them up:

• Replacing per-call cache keys. A couple of plugins built keys like JSON.stringify({value, options, browsers}) per declaration, when options and browsers are fixed for the whole pass. Using just value is clearly cheaper, but it moved the whole-preset number by less than the noise. Real, but not measurable.
• Avoiding a small array allocation in a hot [a, b, c].includes(type) check. Same story. Looks good in a micro-benchmark, invisible end to end.
• Reordering cheap checks before an expensive selector check in merge-rules. Sound in theory, but it tangled the control flow for about 0% on the corpus.
• Guarding a regex behind an indexOf so it only runs when the token is present. Textbook, and also noise.

The lesson I keep relearning is that an optimization you can't measure isn't an optimization, it's a risk. Every one of these touched code where a small mistake produces wrong CSS. If the upside is below your noise floor, the honest move is to drop the change. I shipped the three the benchmark could see, and dropped the four it couldn't.

Lessons

• The biggest win was three lines that skip a parser. It was a guard, not a clever algorithm. A cheap check that lets you skip expensive work beats a faster version of the expensive work.
• Quadratic behavior hides in old code, especially in loops that scan siblings. They were written when stylesheets were small. They cost nothing on small input and everything on large input.
• Use the minimum, not the median. Interleave baseline and branch, and make them agree before you trust the number.
• Measure the whole pipeline, not one plugin. Isolated numbers are how you fool yourself.
• Be willing to drop correct code that doesn't move the needle. In a minifier, "harmless and pointless" is still a liability.

This was a different problem from colordx. There the wins came from understanding V8. Here they came from understanding the workload: what the common input looks like, and how much code runs for nothing on it.

All three changes are now merged into cssnano. The method behind the numbers is simple — run the full default preset over a folder of CSS files and take the minimum across many runs — so it's easy to reproduce on your own files. The code is in the cssnano repo.