csso vs clean-css vs cssnano vs postcss-clean
CSS圧縮ライブラリ
cssoclean-csscssnanopostcss-clean類似パッケージ:
CSS圧縮ライブラリ

CSS圧縮ライブラリは、ウェブ開発においてスタイルシートのサイズを削減し、ページの読み込み速度を向上させるために使用されます。これらのライブラリは、不要なスペース、コメント、改行を削除し、CSSコードを最適化することで、ファイルサイズを小さくし、パフォーマンスを向上させます。特に、モバイルデバイスや低速回線でのユーザーエクスペリエンスを改善するために重要です。

npmのダウンロードトレンド
3 年
GitHub Starsランキング
統計詳細
パッケージ
ダウンロード数
Stars
サイズ
Issues
公開日時
ライセンス
csso20,921,6623,798606 kB104-MIT
clean-css18,818,2074,200493 kB422年前MIT
cssnano14,400,7124,9447.37 kB1001ヶ月前MIT
postcss-clean20,27043-125年前MIT
機能比較: csso vs clean-css vs cssnano vs postcss-clean

圧縮効率

  • csso:

    cssoは、CSSの構造を解析し、冗長なコードを削除することで、圧縮効率を最大化します。特に、複雑なセレクタやプロパティを持つCSSに対して効果的です。

  • clean-css:

    clean-cssは、非常に高い圧縮率を誇り、特にパフォーマンスを重視した最適化を行います。複雑なCSSでも効果的に圧縮し、ファイルサイズを大幅に削減します。

  • cssnano:

    cssnanoは、さまざまな最適化手法を提供し、特にモジュール化されたCSSに対して高い圧縮効率を発揮します。設定が柔軟で、プロジェクトに応じた最適化が可能です。

  • postcss-clean:

    postcss-cleanは、基本的な圧縮機能を提供し、他のPostCSSプラグインと組み合わせることで、圧縮効率を向上させることができます。

設定の柔軟性

  • csso:

    cssoは、特定の最適化手法を選択できる柔軟性がありますが、設定はやや複雑になることがあります。

  • clean-css:

    clean-cssは、シンプルな設定オプションを提供し、すぐに使用できるため、初心者にも優しいです。

  • cssnano:

    cssnanoは、豊富なプラグインと設定オプションを持ち、プロジェクトのニーズに応じた細かい調整が可能です。

  • postcss-clean:

    postcss-cleanは、PostCSSのエコシステムに統合されており、他のプラグインとの組み合わせによる柔軟な設定が可能です。

パフォーマンス

  • csso:

    cssoは、圧縮後のCSSの読み込み速度を向上させるために設計されており、特に複雑なスタイルシートに対して効果的です。

  • clean-css:

    clean-cssは、圧縮後のCSSのパフォーマンスを重視しており、特に大規模なプロジェクトでの使用に適しています。

  • cssnano:

    cssnanoは、圧縮後のCSSのパフォーマンスを維持しつつ、最適化を行うため、特にビルドプロセスでの使用に適しています。

  • postcss-clean:

    postcss-cleanは、基本的な圧縮機能を提供し、他のプラグインと連携することで、パフォーマンスを向上させることができます。

学習曲線

  • csso:

    cssoは、特定の最適化手法を理解する必要があるため、やや学習曲線が急ですが、効果的な圧縮が可能です。

  • clean-css:

    clean-cssは、シンプルなAPIとドキュメントが整備されているため、学習曲線が緩やかで、すぐに使い始めることができます。

  • cssnano:

    cssnanoは、PostCSSの知識が必要ですが、柔軟な設定が可能なため、学習する価値があります。

  • postcss-clean:

    postcss-cleanは、PostCSSの一部として動作するため、既存のPostCSSの知識があれば、比較的簡単に学習できます。

統合性

  • csso:

    cssoは、独立したツールとして使用できますが、他のツールとの統合にはやや手間がかかることがあります。

  • clean-css:

    clean-cssは、単体で使用することができ、特にシンプルなプロジェクトに適しています。

  • cssnano:

    cssnanoは、PostCSSのエコシステムに統合されており、他のプラグインと組み合わせて使用することで、さらなる機能を追加できます。

  • postcss-clean:

    postcss-cleanは、PostCSSの一部として動作し、他のプラグインとの統合が容易で、ワークフローに組み込みやすいです。

選び方: csso vs clean-css vs cssnano vs postcss-clean
  • csso:

    cssoは、CSSの構造を分析し、最適化を行うことに特化しています。特に、複雑なCSSを扱う場合や、特定の最適化手法を利用したい場合に選択してください。

  • clean-css:

    clean-cssは、シンプルで使いやすいAPIを提供し、特にパフォーマンスを重視するプロジェクトに適しています。複雑な設定が不要で、迅速にCSSを圧縮したい場合に選択してください。

  • cssnano:

    cssnanoは、PostCSSプラグインとして動作し、柔軟な設定が可能です。特に、他のPostCSSプラグインと組み合わせて使用する場合や、特定の最適化を行いたい場合に最適です。

  • postcss-clean:

    postcss-cleanは、PostCSSの一部として動作し、他のプラグインと連携することで、より高度なカスタマイズが可能です。既存のPostCSSワークフローに統合したい場合に適しています。

csso のREADME

NPM version Build Status Coverage Status NPM Downloads Twitter

CSSO (CSS Optimizer) is a CSS minifier. It performs three sort of transformations: cleaning (removing redundants), compression (replacement for the shorter forms) and restructuring (merge of declarations, rules and so on). As a result an output CSS becomes much smaller in size.

Install

npm install csso

Usage

import { minify } from 'csso';
// CommonJS is also supported
// const { minify } = require('csso');

const minifiedCss = minify('.test { color: #ff0000; }').css;

console.log(minifiedCss);
// .test{color:red}

Bundles are also available for use in a browser:

  • dist/csso.js – minified IIFE with csso as global
<script src="node_modules/csso/dist/csso.js"></script>
<script>
  csso.minify('.example { color: green }');
</script>
  • dist/csso.esm.js – minified ES module
<script type="module">
  import { minify } from 'node_modules/csso/dist/csso.esm.js'

  minify('.example { color: green }');
</script>

One of CDN services like unpkg or jsDelivr can be used. By default (for short path) a ESM version is exposing. For IIFE version a full path to a bundle should be specified:

<!-- ESM -->
<script type="module">
  import * as csstree from 'https://cdn.jsdelivr.net/npm/csso';
  import * as csstree from 'https://unpkg.com/csso';
</script>

<!-- IIFE with an export to global -->
<script src="https://cdn.jsdelivr.net/npm/csso/dist/csso.js"></script>
<script src="https://unpkg.com/csso/dist/csso.js"></script>

CSSO is based on CSSTree to parse CSS into AST, AST traversal and to generate AST back to CSS. All CSSTree API is available behind syntax field extended with compress() method. You may minify CSS step by step:

import { syntax } from 'csso';

const ast = syntax.parse('.test { color: #ff0000; }');
const compressedAst = syntax.compress(ast).ast;
const minifiedCss = syntax.generate(compressedAst);

console.log(minifiedCss);
// .test{color:red}

Also syntax can be imported using csso/syntax entry point:

import { parse, compress, generate } from 'csso/syntax';

const ast = parse('.test { color: #ff0000; }');
const compressedAst = compress(ast).ast;
const minifiedCss = generate(compressedAst);

console.log(minifiedCss);
// .test{color:red}

Warning: CSSO doesn't guarantee API behind a syntax field as well as AST format. Both might be changed with changes in CSSTree. If you rely heavily on syntax API, a better option might be to use CSSTree directly.

Related projects

API

minify(source[, options])

Minify source CSS passed as String.

const result = csso.minify('.test { color: #ff0000; }', {
    restructure: false,   // don't change CSS structure, i.e. don't merge declarations, rulesets etc
    debug: true           // show additional debug information:
                          // true or number from 1 to 3 (greater number - more details)
});

console.log(result.css);
// > .test{color:red}

Returns an object with properties:

Options:

  • sourceMap

    Type: Boolean
    Default: false

    Generate a source map when true.

  • filename

    Type: String
    Default: '<unknown>'

    Filename of input CSS, uses for source map generation.

  • debug

    Type: Boolean
    Default: false

    Output debug information to stderr.

  • beforeCompress

    Type: function(ast, options) or Array<function(ast, options)> or null
    Default: null

    Called right after parse is run.

  • afterCompress

    Type: function(compressResult, options) or Array<function(compressResult, options)> or null
    Default: null

    Called right after syntax.compress() is run.

  • Other options are the same as for syntax.compress() function.

minifyBlock(source[, options])

The same as minify() but for list of declarations. Usually it's a style attribute value.

const result = csso.minifyBlock('color: rgba(255, 0, 0, 1); color: #ff0000');

console.log(result.css);
// > color:red

syntax.compress(ast[, options])

Does the main task – compress an AST. This is CSSO's extension in CSSTree syntax API.

NOTE: syntax.compress() performs AST compression by transforming input AST by default (since AST cloning is expensive and needed in rare cases). Use clone option with truthy value in case you want to keep input AST untouched.

Returns an object with properties:

  • ast Object – resulting AST

Options:

  • restructure

    Type: Boolean
    Default: true

    Disable or enable a structure optimisations.

  • forceMediaMerge

    Type: Boolean
    Default: false

    Enables merging of @media rules with the same media query by splitted by other rules. The optimisation is unsafe in general, but should work fine in most cases. Use it on your own risk.

  • clone

    Type: Boolean
    Default: false

    Transform a copy of input AST if true. Useful in case of AST reuse.

  • comments

    Type: String or Boolean
    Default: true

    Specify what comments to leave:

    • 'exclamation' or true – leave all exclamation comments (i.e. /*! .. */)
    • 'first-exclamation' – remove every comment except first one
    • false – remove all comments
  • usage

    Type: Object or null
    Default: null

    Usage data for advanced optimisations (see Usage data for details)

  • logger

    Type: Function or null
    Default: null

    Function to track every step of transformation.

Source maps

To get a source map set true for sourceMap option. Additianaly filename option can be passed to specify source file. When sourceMap option is true, map field of result object will contain a SourceMapGenerator instance. This object can be mixed with another source map or translated to string.

const csso = require('csso');
const css = fs.readFileSync('path/to/my.css', 'utf8');
const result = csso.minify(css, {
  filename: 'path/to/my.css', // will be added to source map as reference to source file
  sourceMap: true             // generate source map
});

console.log(result);
// { css: '...minified...', map: SourceMapGenerator {} }

console.log(result.map.toString());
// '{ .. source map content .. }'

Example of generating source map with respect of source map from input CSS:

import { SourceMapConsumer } from 'source-map';
import * as csso from 'csso';

const inputFile = 'path/to/my.css';
const input = fs.readFileSync(inputFile, 'utf8');
const inputMap = input.match(/\/\*# sourceMappingURL=(\S+)\s*\*\/\s*$/);
const output = csso.minify(input, {
  filename: inputFile,
  sourceMap: true
});

// apply input source map to output
if (inputMap) {
  output.map.applySourceMap(
    new SourceMapConsumer(inputMap[1]),
    inputFile
  )
}

// result CSS with source map
console.log(
  output.css +
  '/*# sourceMappingURL=data:application/json;base64,' +
  Buffer.from(output.map.toString()).toString('base64') +
  ' */'
);

Usage data

CSSO can use data about how CSS is used in a markup for better compression. File with this data (JSON) can be set using usage option. Usage data may contain following sections:

  • blacklist – a set of black lists (see Black list filtering)
  • tags – white list of tags
  • ids – white list of ids
  • classes – white list of classes
  • scopes – groups of classes which never used with classes from other groups on the same element

All sections are optional. Value of tags, ids and classes should be an array of a string, value of scopes should be an array of arrays of strings. Other values are ignoring.

White list filtering

tags, ids and classes are using on clean stage to filter selectors that contain something not in the lists. Selectors are filtering only by those kind of simple selector which white list is specified. For example, if only tags list is specified then type selectors are checking, and if all type selectors in selector present in list or selector has no any type selector it isn't filter.

ids and classes are case sensitive, tags – is not.

Input CSS:

* { color: green; }
ul, ol, li { color: blue; }
UL.foo, span.bar { color: red; }

Usage data:

{
    "tags": ["ul", "LI"]
}

Resulting CSS:

*{color:green}ul,li{color:blue}ul.foo{color:red}

Filtering performs for nested selectors too. :not() pseudos content is ignoring since the result of matching is unpredictable. Example for the same usage data as above:

:nth-child(2n of ul, ol) { color: red }
:nth-child(3n + 1 of img) { color: yellow }
:not(div, ol, ul) { color: green }
:has(:matches(ul, ol), ul, ol) { color: blue }

Turns into:

:nth-child(2n of ul){color:red}:not(div,ol,ul){color:green}:has(:matches(ul),ul){color:blue}

Black list filtering

Black list filtering performs the same as white list filtering, but filters things that mentioned in the lists. blacklist can contain the lists tags, ids and classes.

Black list has a higher priority, so when something mentioned in the white list and in the black list then white list occurrence is ignoring. The :not() pseudos content ignoring as well.

* { color: green; }
ul, ol, li { color: blue; }
UL.foo, li.bar { color: red; }

Usage data:

{
    "blacklist": {
        "tags": ["ul"]
    },
    "tags": ["ul", "LI"]
}

Resulting CSS:

*{color:green}li{color:blue}li.bar{color:red}

Scopes

Scopes is designed for CSS scope isolation solutions such as css-modules. Scopes are similar to namespaces and define lists of class names that exclusively used on some markup. This information allows the optimizer to move rules more agressive. Since it assumes selectors from different scopes don't match for the same element. This can improve rule merging.

Suppose we have a file:

.module1-foo { color: red; }
.module1-bar { font-size: 1.5em; background: yellow; }

.module2-baz { color: red; }
.module2-qux { font-size: 1.5em; background: yellow; width: 50px; }

It can be assumed that first two rules are never used with the second two on the same markup. But we can't say that for sure without a markup review. The optimizer doesn't know it either and will perform safe transformations only. The result will be the same as input but with no spaces and some semicolons:

.module1-foo{color:red}.module1-bar{font-size:1.5em;background:#ff0}.module2-baz{color:red}.module2-qux{font-size:1.5em;background:#ff0;width:50px}

With usage data CSSO can produce better output. If follow usage data is provided:

{
    "scopes": [
        ["module1-foo", "module1-bar"],
        ["module2-baz", "module2-qux"]
    ]
}

The result will be (29 bytes extra saving):

.module1-foo,.module2-baz{color:red}.module1-bar,.module2-qux{font-size:1.5em;background:#ff0}.module2-qux{width:50px}

If class name isn't mentioned in the scopes it belongs to default scope. scopes data doesn't affect classes whitelist. If class name mentioned in scopes but missed in classes (both sections are specified) it will be filtered.

Note that class name can't be set for several scopes. Also a selector can't have class names from different scopes. In both cases an exception will thrown.

Currently the optimizer doesn't care about changing order safety for out-of-bounds selectors (i.e. selectors that match to elements without class name, e.g. .scope div or .scope ~ :last-child). It assumes that scoped CSS modules doesn't relay on it's order. It may be fix in future if to be an issue.