Double Shot #1514

Flocker 1.0: Container Data Management for Docker – Portable data storage for your Docker infrastructure.
Introducing Empire: A self-hosted PAAS built on Docker & Amazon ECS – Sort of a roll-your-own Heroku.

CSS Preprocessor Benchmark

January 27, 2014

Results

The timings for processing a 200 KB file of plain CSS (lower is better):

Sass: 4.9 sec
Sass: 2.5 sec (with warm .sass-cache)
libsass: 0.2 sec
Stylus: 1.7 sec
Rework: 0.2 sec
LESS: 0.5 sec
r.js: 0.2 sec

Libsass (a C++ implementation of Sass) and Rework turn out to be extremely fast.

Background

The speed of your CSS preprocessor is important for developer/designer ergonomics. The preprocessing time measured by this benchmark will typically incur as a delay every time you edit the stylesheet sources and hit reload in the browser. Delays below 0.2 to 0.5 seconds tend to be perceived by the human brain as near-instantaneous. The higher the delay, the higher the mental overhead.

To see how fast preprocessors are, I recently ran an informal benchmark of CSS preprocessors. The benchmark garnered a lot of interest, so I’m posting this write-up in blog form.

Methods

I chose 200 KB of minified ungzipped CSS to simulate a large-ish web application, because that’s approximately the amount that the Yahoo homepage uses.

The file contents were artificially simple:

.x0{color:green;}
.x1{color:green;}
...
.x9999{color:green;}

Benchmark script: css-preprocessor-benchmark.sh

I used Ruby 2.1.0p0, Node 0.10.24, and the master branches of each library (Sass 767c53f, libsass 991bc26, Stylus f539ef0, Rework c60edd3, less.js 281a895, r.js 84f325c).

Discussion

Libsass, Rework, LESS, and r.js came in below the 0.5 second threshold.

Ruby Sass and libsass

Libsass, a re-implementation of Sass in C++, provides a massive (>10x) speed improvement over the original Sass written in Ruby, dropping processing time from 2.5 seconds to 0.2 seconds. It is not quite a drop-in replacement for Sass yet, but it’s getting a lot of development love from Aaron Leung. It might be worth considering for new applications.

People’s biggest worry about libsass seems to be losing the Ruby-based Compass. Perhaps there will be an alternative/re-implementation of Compass that is not Ruby-based. But even without that, we might think about whether the massive speed increase of libsass might justify going without Compass completely.

Given the speed difference, I’d like to suggest that the move from Ruby Sass to libsass is inevitable, and I hope that it will see copious contributions from the community to bring it up to par.

Update: Read Aaron’s notes on the state of libsass.

Others

A surprising contender is the newer Rework coming in at only 0.2 seconds, written in JavaScript but nearly as fast as libsass. LESS.js also did fairly well at 0.5 seconds, while the third JavaScript-based preprocessor, Stylus, fell on the slow side with 1.7 seconds. Perhaps it can be improved though.

I also included r.js, which was the fastest of all. While it’s not strictly a preprocessor, it can inline @import statements, and so it can be used to concatenate your project’s plain CSS files (if you are the minimalist type).

Discuss on Twitter

[…]

The Ruby Rails Aggregator