Scoring algorithm for rankings

[privatenumber]

In #787 (and the follow-up 2a859ce), we introduced a scoring algorithm that produces a single ranking reflecting both compression size and minification speed.

How does the scoring algorithm work?

• Base weights: Size is weighted at 85%, speed at 15%.
• Dynamic weighting: If a minifier is unusually slow compared to the median, the time weight gradually increases toward 50% using a logistic sigmoid function.
• Normalization: Both size and time are normalized relative to the fastest/smallest in the set, so the metrics are comparable.
• Result: Fast minifiers aren't penalized much, while very slow minifiers don't get a free pass for shaving a few extra bytes.

Algorithm source: https://github.com/privatenumber/minification-benchmarks/blob/master/packages/data/update-readme/analyzed-data.ts#L92-L124

What's the different perespectives?

Community discussion around this change has surfaced different but valid priorities:

• Size-first
  Compression size is the only important metric. Since code is minified once but served millions of times, minification time is negligible. Some argue weights should be closer to 99.9% size vs 0.1% time.

• Balanced
  Emphasis on build performance, CI/CD efficiency, and developer experience. Extremely slow minifiers are impractical, and efficiency is often a hallmark of good engineering.

• Speed-first
  Throughput is the most important metric. In use cases like CDNs or edge systems performing on-demand minification, every millisecond counts. Smaller output matters less than minimizing latency and cost at scale.

Discussion goals

The scoring algorithm was added to provide an extra lens, not to hide facts. Raw data (minified size, minzipped size, and time) is still in the table, and the 🏆 emoji still highlights top performers in each column.

However, the default ordering has a real impact on how people consume this benchmark. Since this affects methodology, I'd like to gather broader community feedback here:

• Should a default weighted score exist, or should the table stick to raw metrics only?
• If it exists, what weights feel most appropriate? Fixed (85/15, 75/25, 99/1), dynamic, or configurable?
• Would alternative presentations help? (e.g. a separate Markdown strictly ordered by size).

This benchmark exists to serve the community and we're open to change. The goal is to find a fair, transparent, and useful way to represent trade-offs between size and speed.

Please share your thoughts!

[o-alexandrov]

Should a default weighted score exist, or should the table stick to raw metrics only?

Raw metrics

If it exists, what weights feel most appropriate? Fixed (85/15, 75/25, 99/1), dynamic, or configurable?

99/1 (or no weighted score is even better, as 99/1 won't affect the score in most of the cases whereas when it does, it'd probably result in a confusion).
Minification happens once per at least 1000 downloads, some would argue millions, depending on the popularity.

• some argued to rather have minification time 8x faster than <1% size difference.
  • however, when the minification time is 1s vs 15s (even though 15s is an exaggeration); 14s don't matter in real life.
• some argued minification time affects energy efficiency, etc. completely disregarding the fact of bandwidth cost, which ends up being higher than the minification in ci/cd due to the proportion of builds vs downloads.

[privatenumber]

Thanks for the context!

Here's how those points map to what the repo currently provides:

1. For the absolute smallest output, the top performer in each column is marked with 🏆. It's a little harder to identify 2nd, 3rd place, but your goal is identifying the smallest size.
2. That particular metric isn't tracked in this repo.
3. There's some useful insight here: you can see which minifiers failed, and the AI analysis at the bottom highlights those failures with a warning.
4. The fastest minifier is also easy to spot with 🏆.

It seems like the current presentation already covers the information you're after.

Could you share what feels missing that makes you prefer ordering by minzipped desc?

[o-alexandrov]

1. I have an opposite opinion. Since I stated 4 points, it means I look at more than 1 option to take into account points 2 & 3.

I'm not looking for points 2, 3, 4 in this repo. imho, it'd be a good addition to see popularity as raw metrics column
The repo is good as-is; before weighted scoring, it was great.

[privatenumber]

There are really two types of viewers looking at these benchmarks:

1. The average user who just wants to know which minifier to pick, and will mentally balance size vs speed.
2. The edge cases who care only about size or only about speed.

I get that size is your top priority, but here's an example chart: even the worst minifier still cuts TypeScript's gzip size almost in half compared to unminified, and does it in only 0.1s.

That shows all minifiers already deliver significant compression, and the trade-offs quickly become seconds of minification time for very marginal byte savings.

That's why a balanced score helps the average viewer: it prevents someone from picking a painfully slow tool for a 1–2% win. The edge cases (pure size-first or speed-first) are still covered by the raw metrics, so keeping a weighted score as the default ranking offers a fairer picture and deters gaming one metric.

Instead of focusing only on the second type of viewer, could you propose a presentation idea that would serve both groups well?

[o-alexandrov]

You are welcome to keep the weighted score.
Even though it's worse for users like me, it's good that more people are going to use oxc, because this benchmark would make them to believe it's a good choice. Users like me would benefit from their switch in a year from now.

---

The results in the benchmark are way far off what happens in the full app usage.
There's by no means 1-2% difference between minifiers.
Libraries are typically pretty straightforward and being open source, popular libraries you test in this repo, are well optimized for tree-shaking, pure function comments, etc.

Whereas in less known libraries and especially in the users' own source code, almost no-one adds pure function comments, tree-shaking mostly doesn't work with classes, etc.

[o-alexandrov]

Just checked in one of our apps the output gzip size in the main chunk with latest versions by toggling different minifiers:

• [email protected] => 168.26KB
• [email protected] => 162.87KB; 3.2% less than esbuild
• [email protected] => 162.02KB; 3.71% less than esbuild
• swc AND terser => 161.32KB; 4.13% less than esbuild

If used w/ rollup.treeshake.preset = smallest, swc+terser => 145.48KB; 13.54% less than the default