web-dev-qa-db-ja.com

！importantはパフォーマンスに悪いですか？

私はそれらが嫌いです。CSSのカスケードの性質を無視し、注意してそれらを使用しないと、!importantを追加するループになってしまいます。

しかし、私は彼らがパフォーマンスに悪いことを知りたいですか？

[〜＃〜] edit [〜＃〜]
（高速）返信から、パフォーマンスに（重大な）影響はないと結論付けることができます。しかし、他の人を思いとどまらせるための追加の引数としてだけであっても、知っておくといいです;）。

編集2
BoltClockは、2つの!important宣言がある場合、仕様では最も具体的な宣言が選択されると指摘しています。

cssperformance
191
janw

実際にはパフォーマンスに影響を与えないはずです。 firefoxのCSSパーサーを /source/layout/style/nsCSSDataBlock.cpp#572で見ると、それが関連するルーチンであり、上書きを処理していると思いますのCSSルール。

「重要」の単純なチェックのようです。

  if (aIsImportant) {
    if (!HasImportantBit(aPropID))
      changed = PR_TRUE;
    SetImportantBit(aPropID);
  } else {
    // ...

また、source/layout/style/nsCSSDataBlock.h#219のコメント

    /**
     * Transfer the state for |aPropID| (which may be a shorthand)
     * from |aFromBlock| to this block.  The property being transferred
     * is !important if |aIsImportant| is true, and should replace an
     * existing !important property regardless of its own importance
     * if |aOverrideImportant| is true.
     * 
     * ...
     */

  1. Firefoxは、手動で記述されたトップダウンパーサーを使用します。どちらの場合も、各CSSファイルはStyleSheetオブジェクトに解析され、各オブジェクトにはCSSルールが含まれます。

  2. Firefoxは、すべてのルールを正しい順序で適用した後、終了値を含むスタイルコンテキストツリーを作成します

CSS Parser Firefox

From：http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing

これで、上記のオブジェクトモデルの場合のように、パーサーは!importantの影響を受けるルールを簡単にマークでき、その後のコストはあまりかかりません。パフォーマンスの低下は!importantに対する適切な引数ではありません。

ただし、メンテナビリティは（他の回答で述べたように）ヒットします。これは、それらに対する唯一の引数かもしれません。

267
Anirudh Ramanathan

ブラウザがルールと一致する速さの点で_!important_が本質的に悪いとは思わない（セレクタの一部ではなく、宣言の一部のみを形成する）

ただし、既に述べたように、コードの保守性が低下するため、将来の変更によりコードが不必要に大きくなる可能性があります。 _!important_を使用すると、開発者のパフォーマンスも低下する可能性があります。

本当にうるさい場合は、_!important_がCSSファイルに11バイトを追加すると言うこともできますが、これはあまり多くありませんが、かなり少ない_!important_ sスタイルシートに追加できます。

残念ながら、_!important_がパフォーマンスにどのように影響するかについてのベンチマークを見つけることができませんでした。

113
Sean

!importantには場所があります。その上で私を信頼してください。それは私を何度も救い、あなたの問題に対するより長くより洗練された方法が見つかる前に、しばしば短期的な解決策としてより有用です。

ただし、ほとんどの場合と同様、悪用されていますが、「パフォーマンス」を心配する必要はありません。 1つの小さな1x1 GIFは、！importantよりもWebページのパフォーマンスに大きな打撃を与えることになります。

ページを最適化する場合は、さらに多くの！important取るルートがあります;）;）

58
Michael Giovanni Pumo

ここで行われているのは、CSSの処理中に、ブラウザーがそれを読み取り、!important属性に遭遇し、ブラウザーが戻って!importantで定義されたスタイルを適用することです。この余分なプロセスは小さな追加ステップのように思えるかもしれませんが、多くのリクエストを処理している場合、パフォーマンスが低下します。 （ソース）

CSSで！importantを使用することは、通常、開発者の自己陶酔的で利己的または怠zyなことを意味します。開発者を尊重してください...

!importantを使用する場合の開発者の考え方：

  1. 私のロッキングCSSは機能していません... grrrr。
  2. 私は今どうすればいい？？
  3. そして!importantええ....今は問題なく動作しています。

ただし、CSSをうまく管理しなかったという理由だけで、!importantを使用するのは良い方法ではありません。パフォーマンスの問題よりも悪い多くの設計上の問題が発生しますが、!importantで他のプロパティをオーバーライドし、CSSが無駄なコードで混雑するため、多くの余分なコード行を使用せざるを得ません。代わりに行うべきことは、最初にCSSを非常にうまく管理し、プロパティが互いにオーバーライドしないようにすることです。

私たちはcan!importantを使用できます。ただし、他の方法がない場合にのみ、控えめに使用してください。

enter image description here

31
NullPoiиteя

パフォーマンスに関係なく、それは悪い習慣なので、使用しないことに同意します。それらの理由だけで、可能な限り!importantの使用を避けたいと思います。

しかし、パフォーマンスの問題については、いいえ、目立ってはいけません。何らかの効果があるかもしれませんが、気づかないほど小さいので、should心配する必要はありません。

注目に値するほど重要な場合は、単に!importantよりもコードに大きな問題がある可能性があります。使用しているコア言語の通常の構文要素を単純に使用することは、パフォーマンスの問題になることはありません。

見返りに、質問に答えてみましょう。おそらく考慮しなかった角度：どのブラウザを意味しますか？

各ブラウザには、明らかに最適化された独自のレンダリングエンジンがあります。質問は次のようになります：各ブラウザのパフォーマンスへの影響は何ですか？おそらく!importantは、あるブラウザではパフォーマンスが低下しますが、別のブラウザでは本当に良好ですか？そして、おそらく次のバージョンでは、それは逆になりますか？

ここでの私のポイントは、Web開発者として、使用している言語の個々の構文構造のパフォーマンスへの影響について考えてはならない（または考える必要がない）ことだと思います。これらの構文構造は、実行方法が理由でしたくないことを達成するための正しい方法であるため、使用する必要があります。

パフォーマンスの質問は、プロファイラーを使用して、ピンチポイントがシステム内のどこにあるかを分析することと併せて質問する必要があります。最初に本当に遅くなるものを修正します。個々のCSSコンストラクトのレベルに到達する前に、修正すべきはるかに大きな問題があることはほぼ確実です。

13
SDC

以前に!importantを数回使用しなければならなかったので、私は個人的に、それを使用するときに実証可能なパフォーマンスヒットがないことに気付きました。

注として このスタックの質問への答え を参照してください。理由は!importantを使用することです。

また、私は他の誰もが言及しなかったことを言及します。 !importantは、javascript関数を書くことなくインラインcssをオーバーライドする唯一の方法です（ほんの少しでもパフォーマンスに影響します）。そのため、インラインcssをオーバーライドする必要がある場合、実際にはsaveある程度のパフォーマンス時間を要する可能性があります。

7
Ryan

パフォーマンスに目立った影響はありません。ただし、コードの保守性が低下するため、長期的にはパフォーマンスが低下する可能性があります。

7
Henrik

うーん...！重要または!!重要？

この手順をステップごとに見ていきましょう。

  1. パーサーは、使用するかどうかに関係なく、プロパティごとに！importantをチェックする必要があります。したがって、ここでのパフォーマンスの違いは0です。
  2. プロパティを上書きするとき、パーサーは上書きされるプロパティが！importantであるかどうかを確認する必要があります。そのため、ここでのパフォーマンスの差は再び0です。
  3. 上書きされるプロパティが!! importantである場合、プロパティを上書きする必要があります。！importantを使用しない場合は-1のパフォーマンスヒット
  4. 上書きされるプロパティが！importantである場合、プロパティの上書きをスキップします。！importantを使用すると、パフォーマンスが+1向上します。
  5. 新しいプロパティが！importantの場合、上書きされるプロパティが！importantまたは!! importantであるかどうかに関係なく、解析はそれを上書きする必要があります-パフォーマンスの差異0

つまり、！importantは、パーサーがスキップしない多くのプロパティをスキップするのに役立つため、実際にはパフォーマンスが向上していると思います。

そして、@ ryanが以下で言及するように、インラインcssをオーバーライドしてjavascriptの使用を回避する唯一の方法...

うーん...重要なことが重要であることが判明

また、

  • ！importantを使用すると、開発者の時間を大幅に節約できます
  • 時には、CSS全体を再設計することからあなたを救います
  • 時々htmlまたは親のcssファイルがあなたのコントロールにないので、そこにあなたの命を救います
  • 重要な要素が他の重要な要素によって誤って上書きされるのを明らかに防止します。
  • また、ブラウザーはセレクターを特定しすぎることなく適切なプロパティを選択しない場合があるため、！importantを使用することが非常に重要になり、CSSで特定のCSSセレクターを大量に記述する必要がなくなります。したがって、！importantの書き込みにさらにバイトを使用しても、他の場所でバイトを節約できると思います。そして、私たちは皆、CSSセレクターが乱雑になる可能性があることを知っています。

だから！importantを使用することで開発者を幸せにすることができ、それは非常に重要だと思う：D

6
xtrahelp.com

とにかく本質的にではなく、パフォーマンスを妨げる_!important_を予測することはできません。ただし、CSSが_!important_で埋め尽くされている場合は、セレクターの修飾が過剰であり、特定性が高すぎて、特定性を追加するための親または修飾子が不足していることを示します。その結果、CSSは肥大化し（パフォーマンスを妨げる）、維持が困難になります。

Important CSS rule meme

効率的なCSSを作成する場合は、onlyを必要に応じて特定し、 modular CSS を作成します。 ID（ハッシュ付き）、チェーンセレクター、または修飾セレクターの使用を控えることをお勧めします。

CSSで_#_で始まるIDは、 255クラスはidを上書きしない （フィドル： @ Faust ）という点まで、悪質な特定です。 IDには、より深くルーティングされた問題もありますが、IDは一意である必要があります。つまり、IDを重複したスタイルに再利用できないため、スタイルが繰り返される線形CSSを書くことになります。これを行うことの影響は、規模に応じてプロジェクトごとに異なりますが、保守性は非常に低下し、Edgeの場合はパフォーマンスも低下します。

_!important_、連鎖、修飾、またはID（つまり_#_）なしでどのように特異性を追加できますか

[〜＃〜] html [〜＃〜]

_<div class="eg1-foo">
    <p class="eg1-bar">foobar</p>
</div>
<div id="eg2-foo">
    <p id="eg2-bar">foobar</p>
</div>
<div class="eg3-foo">
    <p class="eg3-foo">foobar</p>
</div>
_

[〜＃〜] css [〜＃〜]

_.eg1-foo {
    color: blue;
}
.eg1-bar {
    color: red;
}
[id='eg2-foo'] {
    color: blue;
}
[id='eg2-bar'] {
    color: red;
}
.eg3-foo {
    color: blue;
}
.eg3-foo.eg3-foo {
    color: red;
}
_

JSFiddle

さて、それではどのように機能しますか？

最初と2番目の例は同じように機能し、最初の例は文字通りクラスであり、2番目の例は属性セレクターです。クラスと属性セレクターは同一の特異性を持っています。 _.eg1/2-bar_は独自のルールがあるため、_.eg1/2-foo_から色を継承しません。

3番目の例は、セレクターの修飾または連鎖のように見えますが、どちらでもありません。連鎖は、セレクタの前に親、祖先などを付ける場合です。これにより、特異性が増します。修飾も同様ですが、セレクタが適用される要素を定義します。修飾：_ul.class_および連鎖：_ul .class_

このテクニックを何と呼ぶか​​はわかりませんが、動作は意図的であり、 W3Cによって文書化されています

同じ単純なセレクターの繰り返し発生が許可され、特異性が向上します。

2つのルール間の特異性が同じ場合はどうなりますか？

@ BoltClockが指摘した のように、！important宣言が複数ある場合、specは最も具体的な宣言を優先するように指示します。

以下の例では、_.foo_と_.bar_の両方が同一の特異性を持っているため、動作はCSSのカスケードの性質にフォールバックします。これにより、CSSで宣言された最後のルールが優先権を主張します（つまり_.foo_）。

[〜＃〜] html [〜＃〜]

_<div>
    <p class="foo bar">foobar</p>
</div>
_

[〜＃〜] css [〜＃〜]

_.bar {
    color: blue !important;
}
.foo {
    color: red !important;
}
_

JSFiddle

4
Jack Tuck