[人間の脳サプリメント機械翻訳] CSS セレクターのパフォーマンスが変わりました (良い方へ) by Nicole Sullivan_html/css_WEB-ITnose

CSS选择器的执行效率已经改变了（增强）

像Dave Hyatt的Writing Efficient CSS这样优秀的文章已经帮助开发者们掌握了基本的选择器匹配优化原理. 我们从Steve Souders等大牛那里学到, 选择器是从右到左进行匹配的. 有的选择器匹配方式比较复杂所以应尽量避免使用. 比如说,后代选择器的匹配速度就比较慢,尤其是最右侧的选择器匹配了页面中大量元素的时候. 这些知识在早些年是很有用的. 但随着时间的发展, 感谢Antti Koivisto的努力, 很多选择器的效率问题我们已经无须过于担心了.

Antti致力于Webkit内核的改进工作. 他最近对CSS选择器的匹配机制进行了重要优化. 这些工作已经完成. 他表示:"我认为网页开发者已经无须对选择器进行优化了,那是浏览器引擎开发工程师的工作."

听起来很棒. 我喜欢以对文档结构更有意义的方式来使用选择器,选择器匹配效率优化这方面交给浏览器渲染引擎就好. 那么Antti到底对渲染引擎作了哪些优化呢? 事实上他对webkit渲染引擎的选择器匹配机制进行了多方面的优化. 我们来看看其中最主要的4项:

1. 样式共享(Style Sharing)
   
2. 规则散列(Rule Hashes)
   
3. 祖先过滤器(Ancestor Filters)
   

4. 快速路径(Fast Path)

   样式共享

样式共享使得浏览器允许样式列表中的元素与之前的相同元素重复相同的样式而不是重复计算渲染.

例如:

foo

bar

ブラウザー カーネルが最初の

タグのスタイルをすでに計算している場合、このシンプルだが賢明な改善により、多くの作業が軽減されます。ブラウザ

ルール ハッシュ

さて、セレクターは右から左に一致することは誰もが知っているので、右端のセレクターは非常に重要であり、たとえば次のスタイル シートのように右端のセレクターを使用してスタイル シートをスタイルします。 3 つのグループに分けられます:
a {}
div p {}
div p.legal {}
#sidebar a {}
#sidebar p {}
|a|p.legal|
|-|- |-|
|a {}|div p {}|div p.legal {}|
|-|-|-|
|#sidebar a {}|#sidebar p { }|

ブラウザがルールを使用する場合ルール ハッシュは、スタイル シート全体の単一のセレクターを解析する必要はありませんが、一致する可能性のあるグループのより狭い範囲を解析します。これにより、個々の HTML 要素を解析する必要性が大幅に軽減されます。

祖先フィルター

祖先フィルターはもう少し複雑で、セレクターの一致の可能性を計算します。そのため、関係する要素が祖先を照合する必要がない場合、祖先フィルターは関連するルールを迅速に除外できます。子孫セレクターとサブセレクター、およびクラス、ID、タグに基づく照合。これまでは、子孫セレクターは照合のためにさまざまな祖先ノードをループする必要がありましたが、ブルーム フィルターを使用することでこの問題を解決できました。フィルターは、特定のセレクターが特定のセットに含まれるかどうかをテストするデータ構造です。ブルーム フィルターは、CSS ルールが現在テストされている要素の CSS ルールのサブセットと一致するかどうかをチェックします。ブルーム フィルターの優れた点は、ポジティブの誤検知は発生する可能性がありますが、ネガティブな誤検知は発生しないことです。ブルーム フィルターがセレクターが現在の要素と一致しないことを示した場合、ブラウザーはクエリを停止して次のページに進みます。一方、ブルーム フィルターは、現在のセレクターが一致することを示します。一致が 100% 確実になるまで、ブラウザは通常の一致戦略を実行します。

Ancestor フィルターは子孫セレクターを高速化します。また、サブセレクターのマッチング速度を向上させるため、他の低速セレクターを小さなサブツリーに分割するために使用することもできます。ブラウザーがこれらの非効率なセレクターを処理する必要がある可能性はわずかです。

Fast Path Path)

Fast Path は、非再帰的で完全なインライン ループを使用して、より一般的なマッチング ロジックを再実装します。これは、以下の任意の組み合わせを含むセレクターを照合するために使用されます。以下:

1. 子孫セレクター、サブセレクター、下位派生セレクター

2. タグ セレクター、ID セレクター、クラス セレクターおよび属性で構成されるセレクター
高速パスにより、多数のリレーショナル セレクターのパフォーマンスが向上します。セレクターの全体的なパフォーマンスが 25 % 向上し、その中で子孫セレクターとサブセレクターのパフォーマンスが 2 倍向上しました。また、querySelectorAll() メソッドのスタイル マッチングにも使用されます。非常に多くのセレクターが改善されましたが、どれがまだ比較的遅いですか?

どれがまだ遅いですか?

Antti さんは、直接および間接の子孫関係セレクターはまだ遅いと言いました。彼は、Webkit には疑似クラスと疑似要素の解析効率を向上させる余地がまだたくさんあるとも述べましたが、いずれにしても、それらの解析速度は Javascript の DOM 操作よりもはるかに高速です。実際、まだ改善の余地はありますが、彼は次のように述べています。

「スタイル マッチングの観点からは、すべてのセレクターを適度に使用すると適切なパフォーマンスが得られます。」

要するに、これを聞くのが好きです。スタイル シートを通常のサイズに制御し、さまざまなセレクターを合理的に使用します。Antti に感謝します

CSS のパフォーマンスに関する Paul Irish のプレゼンテーションをご覧ください。