Performance Benchmarks
Note
Benchmarks are automatically collected on every commit to the main branch using:
- Hyperfine: Command-line benchmarking tool for measuring csskit's end-to-end processing time on real CSS files.
- Criterion.rs: Statistical micro-benchmarking for precise measurements of core parsing operations.
This is not meant as a comparison, endorsement, or value judgement of any css frameworks, libraries or tools! They're used to gauge speed for this tool, nothing more.
All benchmarks run on GitHub Actions. This can result in varied performance depending on contention. There are some details about the hardware GitHub Actions run on but these numbers should be viewed as relative performance, and your hardware will likely be different.
CSS Files Tested
19Micro-benchmarks
71Avg. Size Reduction
19.9%Avg. Throughput
14.2 MB/sCSS Processing Performance
Hyperfine timing results for processing popular CSS frameworks with csskit min command.
| File | Processing Time | Throughput | Input Size | Output Size | Compression |
|---|---|---|---|---|---|
| 960 | 1.62ms ±0.04ms | 5.9 MB/s | 9.8KB | 5.5KB | 43.6% smaller |
| animate.4.1.1 | 5.42ms ±0.15ms | 16.8 MB/s | 93.2KB | 77.4KB | 16.9% smaller |
| blueprint.1.0.1 | 2.29ms ±0.05ms | 7.2 MB/s | 17KB | 10.6KB | 38% smaller |
| bootstrap.4.6.2 | 11.67ms ±0.43ms | 16.4 MB/s | 195.7KB | 160.7KB | 17.9% smaller |
| bootstrap.5.3.0 | 13.52ms ±0.41ms | 19.8 MB/s | 274.2KB | 228.3KB | 16.7% smaller |
| bootstrap.5.3.0.min | 12.22ms ±0.48ms | 18.2 MB/s | 227.5KB | 226.8KB | 0.3% smaller |
| font-awesome-all.5.15.4 | 5.06ms ±0.13ms | 13.9 MB/s | 71.9KB | 57.8KB | 19.5% smaller |
| foundation.6.7.5 | 9.1ms ±0.29ms | 20.8 MB/s | 194.1KB | 161.7KB | 16.7% smaller |
| foundation.6.7.5.min | 7.05ms ±0.19ms | 18.2 MB/s | 131.7KB | 131.6KB | 0.1% smaller |
| inuitcss.6.0.0 | 3.41ms ±0.09ms | 14.9 MB/s | 51.9KB | 17.9KB | 65.6% smaller |
| mini.css.3.0.1 | 4.24ms ±0.11ms | 12.4 MB/s | 54KB | 45.8KB | 15.2% smaller |
| missing.1.2.0 | 4.57ms ±0.09ms | 14.1 MB/s | 66.1KB | 54.8KB | 17% smaller |
| open-props.1.5.10.min | 2.17ms ±0.03ms | 8.6 MB/s | 19.2KB | 19.2KB | 0% smaller |
| primer.21.5.1 | 22.56ms ±0.43ms | 31.5 MB/s | 728KB | 717KB | 1.5% smaller |
| pure.2.0.3 | 2.32ms ±0.12ms | 11.9 MB/s | 28.2KB | 16.9KB | 39.9% smaller |
| reset.2.0 | 1.27ms ±0.03ms | 0.8 MB/s | 1.1KB | 0.8KB | 29.3% smaller |
| sakura.1.5.1 | 1.52ms ±0.04ms | 2.6 MB/s | 4KB | 3.1KB | 23.3% smaller |
| tailwind.2.2.19.min | 112.58ms ±0.43ms | 24.9 MB/s | 2865.3KB | 2861.7KB | 0.1% smaller |
| water.2.1.1 | 3.02ms ±0.06ms | 10.2 MB/s | 31.6KB | 26.6KB | 16% smaller |
CSS Tool Comparison
This comparison shows how csskit performs relative to other widely-used CSS minification tools:
- lightningcss: Fast native CSS processor built with Rust
- cssnano: Popular PostCSS-based minifier
- esbuild: Fast JavaScript/CSS bundler with minification
Processing Time Comparison
What this measures: End-to-end processing time for minifying real CSS files from popular frameworks using the tools minify command.
This chart tracks how long it takes for popular css tools to minify various CSS files, compared with each other. Smaller bars are better.
Output Size Comparison
What this measures: Size of the resulting minified CSS files from popular frameworks using the tools minify command.
This chart tracks how small each tool can compress a CSS file by. Smaller file sizes, represented by smaller bars, are better.
Historical Trends
Performance data collected across 32 benchmark runs.
Processing Time Trends
What this measures: End-to-end processing time for minifying real CSS files from popular frameworks using the csskit min command.
This chart tracks how long it takes csskit to completely process various CSS files, including reading, parsing, minifying, and writing the output. Smaller is better.
We can perceive changes in as little as 13000 microseconds (13ms), anything under that would be considered "instant". csskit aims to minify most content in under that time.
Throughput Trends
What this measures: Data processing speed in megabytes per second (MB/s) - how much CSS csskit can process per unit of time.
This chart tracks how much css data csskit can read per second. The lines in this chart should be closer together than processing time proving that performance is consistent between different css, and there aren't performance weak spots or bottlenecks depending on the css content.
Lines closer together means more consistent performance. Lines further parts means unstable performance. Ideally all lines would be within 1mbps of each other.
Compression Ratio Trends
What this measures: How much smaller the output CSS files are compared to their original size after minification.
This shows csskit's effectiveness at reducing file sizes through minification techniques like removing whitespace, shortening values, and eliminating redundant rules. Higher percentages mean better compression. 100% would mean the minified file is half the size of the authored file, while 0% means it did not compress it at all. Some of the benchmark files are already minified, which helps to determine if csskit is compressing better than industry standard tools.
Criterion Benchmark Trends
These micro-benchmarks isolate specific parts of csskit's processing pipeline to identify performance bottlenecks and validate optimizations at a granular level.
Parsing Performance
What this measures: Time spent converting CSS text into csskit's internal Abstract Syntax Tree (AST) representation.
Parsing is a critical step that happens before any transformations. This benchmark measures the core parsing engine's speed on real-world CSS files. Optimizations here improve performance for all csskit operations since parsing is always the first step. Lower numbers are better.
Lexing Performance
What this measures: Time spent breaking CSS text into tokens (keywords, identifiers, values, etc.) - the first step of CSS processing.
Lexing (tokenization) is the foundation of CSS processing. The lexer must scan every character and classify them into meaningful tokens. Lexer performance directly impacts all downstream operations.
The target is to have most files lex in under 2ms (2000 microseconds).
Minification Performance
What this measures: Time spent applying minification transformations to already-parsed CSS.
This isolates the minification logic from parsing overhead, measuring how efficiently csskit can compress CSS once it's already in memory. Improvements here make the csskit min command faster without affecting other operations.
String Parsing by Length
What this measures: The time it takes for csskit to look up a keyword. CSS has a lot of keywords for a programming language, with close to 2,500 different keywords like width, inherit, red, and so on. An important but small aspect of parsing is determining one keyword from another.
Comparing strings between a list of 2500 possibilities would take too long so instead csskit performs some tricks to speed this up. Extracting a keyword should take mere nanoseconds, and should be roughly consistent for keywords of any length. The target is under 20ns per lookup, regardless of the length.