Mixin_html/css_WEB-ITnose によるパフォーマンスの向上

原文リンク: Mixins Better for Performance

この記事は原文の翻訳の許可を得ていますので、翻訳を転載する場合は原文リンクと翻訳を添付してください。翻訳

翻訳リンク: Mixin を使用してパフォーマンスを向上させます

翻訳: Yu Kun

プリプロセッサに関しては、最も一般的な質問は、@extend と mixin のどちらを使用するかということです。私は常に @extend を使用しないようにするという観点を強く支持しています。理由は次のとおりです。

1. CSS の順序が変更されるため、潜在的なリスクがあります。

2. 無関係なセレクターをまとめて、厄介なグループ化を生成します

3、これは貪欲です。@extend は、本当に必要なインスタンスだけでなく、すべてのインスタンスを継承します

4、コードはすぐに制御不能になります (図 1、図 2)

@extend は設計パターンに準拠していないため、奇妙な使用法が徐々に減っていき、これは喜ばしいことです。しかし、まだ十分ではないと思います。

昨日クライアントに講義をしていたときに、@extend について言及しました。私は答えます、@extend は絶対に使用しないでください。お客様は、@extend の方がパフォーマンスが良く、生成されるコードが少ないと言っています。

@extend が (正しく使用された場合) 生成されるコードが少なくなるのは事実ですが、私の答えはやはり、いいえ、パフォーマンスの点ではミックスインの方が優れていますです。

テストしなくても、自信を持ってこれに答えることができます。理由は非常に適切だからです。

gzip はコンテンツの繰り返しを好むため、1,000 個の異なる宣言よりも 1,000 個の繰り返しステートメントの方が優れているからです。圧縮率。

パフォーマンスについて話すとき、通常はファイル サイズについて話しますが、gzip 圧縮をオンにした後 (あなたもオンにしましたか?)、ネットワーク送信時のファイル サイズを考慮する必要があります。

私の考えは、gzip を使用して css を圧縮すると、元の css ファイルのサイズに関係なく、繰り返しの文字列を多く含むファイルは、基本的に繰り返しの内容が含まれないファイルよりもはるかに小さくなるということです。私は、重複コンテンツが多い大きなファイルは、圧縮後には小さくなるだろうと結論付けました。

ホテルに戻って私は自分の理論を検証しました。

実験

私の手順は次のとおりです

1. 2 つの CSS ファイルを作成します。 2. 各ファイルには、sass で生成された 1000 個の異なるクラスがあります

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

3. 各クラスに独立した宣言を与え、クラス名にランダムな文字列を追加し、意味のない名前とセレクターを生成します。

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

4、次にこれら 1000 クラスと共有する 3 つの共通 CSS ステートメントを選択します:

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

5、mixin を使用してこれら 3 つのスタイル ステートメントを共有します

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

6、もう 1 つは @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) にあります

Twoファイルはこの方法で生成され、各ファイルには 1000 個の独立したクラス、1000 個の独立した宣言、および 2 つの方法で共有される 3 つの CSS ルールが含まれます。予想どおり、どちらのファイルが大きくてどちらが小さいですか:

– mixin.css 108K

– extend.css 72K

– 2 つのファイルの違いis 36K

– mixin を使用して生成されたファイルは、@extend を使用したファイルの 150% です

これは予想どおりで、mixin によって生成されたファイルは確かに @extend よりも大きいです。しかし！ファイル システム内のファイル サイズを心配するのではなく、gzip 圧縮後のファイル サイズを心配する必要があります。 gzip で圧縮した後:

– mixin.css 12K

– extend.css 18K

– 2 つのファイルの差は 6K

– mixin を使用すると、@extend と比較してファイル サイズが 33.333% 削減されます。

違いがすごい！最初、ミックスインは @extend の 1.5 倍の大きさでしたが、現在は @extend の 0.3 倍小さくなりました。私の理論は正しいです！

テストをより現実的にする

上記のテストは公平だと思います。クラス名は圧縮を防ぐために一意の文字列を使用しています。これにより、共有ルールの圧縮効果をより適切に示すことができます。言い換えれば、このテストは理想的すぎて非現実的です。そこで、より説得力のあるテストを行うことにしました。コンパイルされた CSS ファイルを実際のプロジェクトから取り出し、コピーを 2 つ作成し、生成された 2 つのテスト ファイルを @import します。この時点で、私のテスト ファイルは、プロジェクトで使用されている 1794 行の実際の CSS とまとめられています。生成されたテスト ファイルは次のとおりです:

– mixin.css 16K

– extend.css 22K

– 2 つのファイル間のギャップは 6K

– mixin を使用すると、@extend を使用するよりも 27% 小さくなります。

絶対的な数はわずか (わずか 6K) ですが、相対的な値としては、帯域幅の 27% が節約されます。この調整は、 @extend を使用する代わりに mixin を使用して繰り返しステートメントを生成するだけです。繰り返しの選択肢を生成します。

ミックスインを使用するとパフォーマンスが向上します

私のテストでは、大きなファイルを非圧縮にし、gzip の動作により帯域幅を節約できるため、ネットワーク上で @extend を使用するよりもミックスインのパフォーマンスが向上することがわかりました。これは、@extend にはパフォーマンス上の利点がなく、CSS にも悪影響を与えるため、もう使用しないでください。

原文リンク: Mixins Better for Performance

この記事は原文の翻訳を転載する場合、原文のリンクと翻訳のリンクを添付してください。許可なく転載することを禁じます

翻訳リンク: パフォーマンスを向上させるために Mixin を使用する

翻訳: Yu Kun