レンダリングの最適化と兄弟セレクタ

Question

WebKitブラウザには、スタイルレンダリングのための最適化手法が組み込まれているため、ページ上の要素の約60％をスタイルに一致させる必要がありません。場合

しかし、その最適化はページ全体のために完全にオフになっている「すべての兄弟セレクタは、スタイルシート内の任意の場所に遭遇した...これは:first-childと:last-childなどの+セレクタとセレクタが含まれています。」

誰もこの最適化を無効にするセレクタタイプの完全なリストを知っていますか？

-

詳細

• 最適化は、ブラウザの内部にタリGarsielの研究で議論されている：How Browsers Work。

• ここでは明らかに、ブラウザのコードを執筆しDave Hyattから兄弟セレクタの完全な引用は、です：「すべてで使用中の兄弟セレクタがあってはならないWebCoreは、単に任意の兄弟セレクタが検出されたグローバルスイッチをスローし、スタイルの共有を無効にします。 first-childと：last-childのようなセレクタとセレクタが含まれています。
  
  を（今後のSafariのリリースで）」WebCoreは、私は本当にクールな最適化があります。引用は、彼はより詳細（前回と同じソース）でそれを論じ下ハイアットが2005年に書いた記事から来るように思われること

• 要素に適用される一連の宣言を計算する必要もなくなりました。実際にこの最適化を行うと、ページ上の要素の約60％をスタイルに一致させる必要はありません。ページ内の2つの要素がDOM（および他の状態）検査によって同じスタイルを持ち、可能であればこれらの2つの要素の間でフロントエンドスタイル情報を単に共有する場合。

• このarticle by Nate Koechleyはアルゴリズムをより詳細に説明しています。彼はそれを以下のようにまとめています：
  
  "ウェブ開発では、同じことをするには6つの異なる方法がよくありますが、良いウェブ開発者は常に、ほとんど区別がつかない最善の方法を選んでいます。ブラウザーの勇気をより完全に理解し、最良の方法を選択するのに役立ちます」

• ハイアットもまた、ライアンKinalからStack chatで簡単に思いついたこのW3C mailing list archive

• で最適化を議論：「うわーだけすごい私は再び別の兄弟セレクタを使用することはありません。。。「

私が知ることに特に興味：

• 子セレクタはまた、トライデント/ IEが

• かどうか任意の同様の最適化を使用するかどうかを最適化

• をオフにするかどうかどのような違いがレンダリングのパフォーマンスに与える影響が大きいかを示すテストが存在します

Answer 1

私は完全なリストを持っていませんが、mozillaとServoのこのテキストは参考になると思います。

属性スタイルの更新の

WebKitの取り扱いは、すでにスタイルの再計算を持っていない要素がフラグを立てた場合

を変更し、属性のいずれかは、id属性があるか、またはこれはセレクタが存在する場合属性には、スタイルrecalcのフラグが付けられます。これらのセレクタが要素と何か関係があるかどうか、およびこの段階で '~'と '+'を含むケースを処理しようとする試みは何もないかどうかを再確認する試みはありません。クラス属性が変更されたときに呼び出される別のフックもあります。これは、他のものの中で、スタイルリカルクを必要とする要素に無条件にフラグを付けます。ここでも、「~」と「+」は処理されません。 これらのケースでは、子孫のセレクタ一致を最適化しようとする試みはありません。

状態が

のWebKitの状態変化のための統一された設定はありませんが変更されます。 Geckoのブール状態を介して処理される各擬似クラスについて、セレクタマッチングは、その擬似クラスがマッチするかどうかをテストするために呼び出すことができる専用関数を持っています。要素内でのその状態への変更は、その要素をスタイル再計算を必要とするものとして直接マークする責任があります。 もう一度、子孫のセレクタマッチングを最適化するか、「+」または「~」を処理する試みは行われません。ここでは、Geckoが:hoverのために作成したものと同じような最適化がいくつかあり、それらは:hover、:active,と何かをドラッグするものです。挿入および欠失の

取り扱い

RenderStyleは、その子供たちが様々な構造擬似クラスと「+」または「~」コンビネータの影響を受けているかどうかを示すフラグを持っています。 DOMの突然変異では、変更後の最初の影響を受けた要素（子リスト順）はスタイルの再計算を必要とするか、再計算が必要な場合は親の最初の1つの子としてマークされます。変更の前にもっと多くの事が再計算を必要とするかもしれないならば、親はスタイルの再計算を必要としているとマークされ、そのすべての子を再計算します。 これらのすべてのケースで、要素のスタイルを実際に再計算するときに、その子が '+'または '~'の影響を受けるかどうかを確認するチェックが行われます。そうであれば、いずれかの子にstyle recalcが必要であるとフラグが立てられている場合、その子の後の子またはそれに続くすべての子（「+」または「~」のいずれかに依存する）にもstyle recalcが必要であるとフラグが立てられます。複数のチェーン「+」の周りにいくつかのバグがあります。

結局のところ、WebKitはGeckoよりもはるかに多くの要素でスタイルを再計算してしまうことがありますが、他の多くの要素でスタイルを再計算することになります。たとえば、 ".foo ~ span"のようなセレクタとdivを "foo"から "bar"に変更するdivを指定すると、Geckoはdivの後のすべての兄弟を再スタイルしますが、WebKitは "span "子供たちは、その場合には、親に '+'の影響を受けると印を付けたことはないので、私は挿入の振る舞いにどの程度影響を及ぼしているのかは分かりませんが、2つがもっと似ているように見えます。 何とか WebKitはHTML5の単一ページ仕様のスクリプトでGeckoよりも優れているようですが、この時点でなぜ私は理解できません。おそらく、これは単純にそのスタイルの再計算がGeckoの実際の実行よりもずっと安いようだからです。

もう1つの欠点は、個々の属性や状態の変更に関連する作業が、Geckoよりはるかに少ないことです。これは、スタイルの再計算が増えます。 DOMの挿入/削除に関連する作業はほぼ同じです。

source

Answer 2

セレクタのスタイルをロードするのに時間がかかる重い画像であるまで、私は、セレクタを持つ任意のこのような問題を見ていません。

CSSセレクタにW3の仕様に応じて、セレクタのいずれかの種類に問題に直面してはならない作り付けのウェブカラーである場合..

次のルールは除いて、前の例のものと類似していますそれはクラスセレクタを追加します。したがって、特別なフォーマッティングは、H1、クラス=「オープナー」を有する場合に発生：

h1.opener + h2 { margin-top: -5mm } 

をSO規則は標準化されているが、特定のセレクタ待ちで停止しWebKitのブラウザでいくつかのバグが存在しなければなりません。