Hey guys! I have a question regarding Sass usage and Gzip compression. If anyone knows something, be sure to share. :)
It's good practice to use Sass @extend
rather than including mixins when possible because of the way Sass handles @extend
. To put it simple, it doesn't take the CSS content from the extended selector to place them in the extending one. It works the other way around: it takes the extending selector and append it to the extended selector.
%p { color: red; }
.a { @extend %p; }
.b { @extend %p; }
Output:
.a, .b {
color: red;
}
@mixin m { color: red; }
.a { @include m; }
.b { @include m; }
Output:
.a { color: red; }
.b { color: red; }
Now it is common knowledge that Gzip works best on repeated strings. The more a string is repeated, the better the compression. At least that's what I know from Gzip.
Knowing this, wouldn't it be better for final file size to use mixins rather than placeholders?
I'm applying this question to a Sass context, but that basically can be translated to: is DRY really the best option when it comes to file size?
I made a super-contrived little test to at least attach a few numbers to this. (I call it "super-contrived" because as you'll see the code isn't from a real-life-website example, but sort of an idealization of the difference between the two methods.)
I've been accumulating Sass utilities into a library (http://davidtheclark.github.io/scut/index.html) and in that library any mixin for which all variables either are optional or have default values is paired with an extend-placeholder that is the equivalent. For example,
@include scut-clearfix
is the same as@extend %scut-clearfix
because there are no arguments for that one; and@include scut-vcenter-ib
(passing no arguments, just taking the default values) is the same as@extend %scut-vcenter-ib
.So what I did was list all the mixins that have equivalent extend-placeholders, then make one file that uses each of those mixins 200 times, and another file that uses each of those extend-placeholders 200 times; then compiled each to CSS; then minified the CSS with
grunt-contrib-cssmin
with thegzip
option on, so it would give a readout of what the filesize would be gzipped.Here's what the SCSS files looked like: https://gist.github.com/davidtheclark/9999225
And the results were:
So the mixin version uncompressed was 4.9x bigger; with just minification it was 3.7x bigger; and after GZIP it was only 1.4x bigger.
So it looks from this like GZIP does really significantly cut down on the difference between the efficiency of the two techniques. Also, the artificiality of this test probably magnified the efficiency-difference significantly (the differences between real stylesheets using the occasional mixin or extend would not be nearly so large).
With that in mind, I'm totally in agreement with @scottkellum that, when deciding between equivalent mixins and extends, authoring preferences and maintainability should have more weight than the apparent efficiency of extends -- as long as you're gzipping. And I also agree that mixins are preferable for those reasons.
(Anybody see any problem with this test, any reason it doesn't mean what it seems to me to mean?)