Maison >interface Web >tutoriel HTML >使用 Mixin 性能更好_html/css_WEB-ITnose

使用 Mixin 性能更好_html/css_WEB-ITnose

WBOYoriginal: 2016-06-21 08:50:191259parcourir

原文链接: Mixins Better for Performance

本文已获得原作翻译授权，转载译文时请附上原文链接以及译文链接，未经允许不得随意转载译文

译文链接：使用 Mixin 性能更好

翻译：于坤

谈到预处理器，最常见的问题就是用 @extend 还是 mixin？我一直强烈支持一个观点，尽量不要用 @extend，原因有很多：

1，它会改变你的 css 顺序，有潜在风险

2，它会产生尴尬的分组，将无关的选择器放到一起

3，它很贪婪，@extend 会继承每一个实例，而不仅仅是你真正需要的那个

4，它会让你的代码很快失控（图1，图2）

现在，因为 @extend 不符合设计模式，奇葩用法逐渐减少，令人欣慰，但我觉得还是不够。

昨天跟一个客户讲课时，提到 @extend。我回答，永远不要用 @extend！客户说，但是 @extend 性能更好啊，生成更少的代码。

确实 @extend（正确使用的话）会产生更少的代码，但是我的回答依然是， 不，mixin 对性能更好。

就算没有测试，我也能很自信的这样回答，因为我的理由很充分：

因为 gzip 偏爱重复的内容，所以1000个重复的声明，比1000个不同的声明有更好的压缩率。

大家在说性能的时候，通常都是在说文件大小，但我们开启了 gzip 压缩以后（你也开启了吧？），就应该考虑网络传输中的文件大小。

我的想法是，我们用 gzip 压缩 css 以后，含有更多重复字符串的文件，比基本上没有重复内容的要小很多，无论原来的 css 文件大小怎样。我断定，大一点的，但是重复内容更多的文件，压缩后更小。

回到酒店我测试了一下我的理论。

实验

我的步骤是这样的

1，创建两个css文件2，每个文件都有1000个不同的 class，用 sass 生成

@for $i from 1 through 1000 {  .#{unique-id()}-#{$i} {    ...  }}

3，我给每一个 class 一个独立的声明，用类名加随机字符串，生成无意义的名称和选择器。

@for $i from 1 through 1000 {  .#{unique-id()}-#{$i} {    content: "ibf#{&}jaslbw";  }}

4，然后选择三个常见的 css 声明，给这1000个 class 共用：

color: red;font-weight: bold;line-height: 2;

5，一个用 mixin 共享这三句样式声明

@mixin foo {  color: red;  font-weight: bold;  line-height: 2;}   .#{unique-id()}-#{$i} {  @include foo;  content: "ibf#{&}jaslbw";}

6，另外一个用 @extend 共享

%foo {  color: red;  font-weight: bold;  line-height: 2;}   .#{unique-id()}-#{$i} {  @extend %foo;  content: "ibf#{&}jaslbw";}

测试代码都在 github（https://github.com/csswizardry/extend-vs-mixin）

这样生成了两个文件，每个都有1000个独立的 class，1000个独立的声明，还有分别用两种方法共享三条 css 规则。文件谁大谁小应该不出所料：

– mixin.css 108K

– extend.css 72K

– 两个文件的差距有 36K

– 使用 mixin 产生的文件是使用 @extend 的150%

这跟我的期望一样，mixin确实比 @extend 产生的文件更大。但是！我们不用担心文件系统中的文件大小，而应该关心 gzip 压缩后的文件大小。我用gzip压缩后：

– mixin.css 12K

– extend.css 18K

– 两个文件相差 6K

– 使用 mixin 比 @extend 减少了33.333%的文件大小。

差距惊人！一开始 mixin 是 @extend 的1.5倍，现在却比 @extend 小 0.3倍。我的理论是对的！

让测试更真实

我认为上面的测试很公平，类名用独特的字符串阻止压缩，这样更能提现共享规则的压缩效果。也就是说，这个测试太理想，不真实。所以我决定做更有说服力的测试，从真实的项目中拿出编译后的 css 文件，复制两份，然后分别 @import 刚才生成的两个测试文件。这时我的测试文件和1794行真正的、实际项目里正在用的 css 放在一起。生成的测试文件如下：

– mixin.css 16K

– extend.css 22K

– 两个文件差距是 6K

– 使用 mixin 比使用 @extend 小27%。

绝对数字微不足道（才6K）但是相对值却是节省27%的宽带，做的调整仅仅是用 mixin 生成重复的声明，代替用 @extend 生成重复的选择器。