Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/ben-eb/css-minifier-tests

A comparison of CSS minification engines.
https://github.com/ben-eb/css-minifier-tests

Last synced: 7 days ago
JSON representation

A comparison of CSS minification engines.

Awesome Lists containing this project

README 

        
# css-minifier-tests



> A comparison of CSS minification engines.



## Usage



Run the tests with:



```sh

node cli

```



Optionally, you can localise to an engine, or engines, of your choice by passing

the `--engines` flag, with a comma separated list of engines:



```sh

node cli --engines cssnano,csso

```



And you can also run specific tests by passing the `--suites` flag.



```sh

node cli --suites 19,84

```



## About



This project has been heavily inspired from [GoalSmashers' benchmark][1],

covering Node.js minifiers on a variety of CSS frameworks. But rather than

comparing minification sizes at a macro-level, it intends to provide a suite of

test cases on what the optimiser actually compresses. The aim of this project is

to improve the quality of Node.js minifiers (and provide thorough test cases for

new projects) - so that it isn't necessary to run several minifiers on a single

CSS file.



See https://github.com/ben-eb/css-minifiers for details on which engines are

covered.



The test cases do not resemble a standard unit test style of pass/fail, because

each minifier may yield slightly different output to the others, even when the

ending CSS size is the same. So they are graded on these criteria instead:



### outstanding



The minification path chosen is considered 'above and beyond' what one would

expect from a minifier; it either improved the structure of the CSS without

losing its semantics, or it did some other transform which was beneficial. Note

that this criteria does not appear on the majority of test cases.



### optimal



The minifier performed a safe optimisation which reduced the size of the CSS.



### sub-optimal



The size of the minified code is greater than an *optimal* optimisation, but it

is still fine to use in production.



### broken/crashed



The optimisation either breaks the author's original intentions, or a browser's

capability to render the CSS generated by the minifier. Or worse, the minifier

crashed when trying to parse the test case.



## Limitations



Some of these tests may appear deliberately contrived to try and break the

minifiers. Indeed, there are some tests that contain CSS that no sane person

would write. However, this is intentional; it is entirely possible that such

code can end up in minified stylesheets, through aggressive optimisations such

as selector and declaration merging. By testing every circumstance, we can

ensure that any code we throw at the minifier will not break our stylesheets.



Note that if an optimisation is classified as *sub-optimal*, **it is still fine

to use in production code**. But, we can always do better - so that if only one

minifier supports a *safe* optimisation which yields a smaller result than the

rest, it will be the recommended (optimal) solution.



*This test suite should not be a replacement for thorough unit testing of a CSS

minifier - it should be used alongside one.*



## Why?



When searching for different CSS optimisation tools as part of my build process,

it was found that running *more than one* tool on a single CSS file resulted in

greater compression than using a single tool. So why is this? Well, many CSS

compressors that exist out there today perform optimisations other than simple

whitespace compression. The more advanced ones will apply *structural

minimisation* to CSS; code that optimises the structure of a CSS file beyond the

author's original intent. A simple example:



```css

h1 {

    color: red;

}



h1 {

    font-weight: bold;

}

```



Structurally optimised, this can look like:



```css

h1{color:red;font-weight:bold}

```



Whereas a traditional minifier will just collapse the spacing around the

ruleset:



```css

h1{color:red}h1{font-weight:bold}

```



This kind of optimisation is important when considering that many developers use

CSS frameworks today; it means that authors can write additional styles *on top*

of the framework, and have the minifier compress those rules together

automatically.



## Contributing



Thinking of contributing? Great! Fork away, do your work on a separate branch

and send a pull request with your feature or fix. The aim of this project is to

produce a robust suite of test cases that are small in scope; please do not

contribute test cases that contain a full site's CSS. If you think that this

project is missing test cases that you feel are relevant, then please:



* Fork the project and create a branch for your test case.

* Add a `camelCased` test directory in `tests`.

* Create a `fixture.css` with your input. As much as possible, make your input

test a limited case, so that tests can be small and meaningful.

* Create an `optimalX.css` with the expected minified CSS - where X is any

number of cases.

* If some minifiers produce broken output, log it into `brokenX.css` - where X

is any number of cases.

* If some minifiers produce better than optimal output, log it into

`outstandingX.css` - where X is any number of cases.

* Optionally, add a README.md in the folder for further test case description.

* Commit your changes and send the pull request.

* You're awesome. :)



## License



MIT © Ben Briggs



[1]: https://github.com/GoalSmashers/css-minification-benchmark