スタイル計算の範囲と複雑さを軽減

Jeremy Wagner

Paul Lewis

JavaScript は多くの場合、視覚的な変化を引き起こすトリガーとなります。場合によっては スタイル操作によって直接、場合によっては計算によって変更される データの検索や並べ替えなど、視覚的な変化をもたらすもの。タイミングが悪い、または JavaScript の実行時間がパフォーマンスの問題の一般的な原因である場合、 影響を最小限に抑えるよう心がけてください

スタイルの計算

要素の追加や削除、属性、クラスの変更による DOM の変更 またはアニメーションの再生を行うと、ブラウザが要素のスタイルを再計算し、 多くの場合はページの一部または全体のレイアウトです。このプロセスを スタイル計算

ブラウザでは、最初に一致するセレクタのセットが作成され、 特定の要素に適用するクラス、疑似セレクタ、ID を決定します。 次に、一致するセレクタからスタイルルールを処理して、 要素の最終的なスタイルを指定します。

インタラクションのレイテンシにおけるスタイル再計算の役割

Interaction to Next Paint（INP）: ユーザー中心のランタイム ユーザー入力に対するページの全体的な応答性を評価するパフォーマンス指標。 ユーザーがページを操作してから、インタラクションのレイテンシを測定します。 ブラウザは、次のフレームをペイントし、対応するビジュアル アップデートを表示します。 表示されます。

インタラクションの重要な要素の 1 つは、次のインタラクションのペイントに要する時間です。 クリックします。次のフレームを表示するために行われるレンダリング作業は、多くの部分で構成されます。 レイアウト、ペイント、およびその直前に発生するページスタイルの計算など、 複雑な処理ですこのガイドでは、スタイル計算のコストに焦点を当てていますが、 インタラクションのレンダリング時間の合計が減少すると、 レイテンシを短縮できます。

セレクタの複雑さを軽減する

CSS セレクタをシンプルにすると、ページのスタイル計算が速くなります。 最も単純なセレクタは、クラス名のみで CSS の要素を参照します。

.title {
  /* styles */
}

しかし、プロジェクトが拡大するにつれ、より複雑な CSS が必要になり、 次のようなセレクタを使用します。

.box:nth-last-child(-n+1) .title {
  /* styles */
}

これらのスタイルをページにどのように適用するかを決定するには、ブラウザは 「これは title のクラスを持つ要素で、そのクラスの親は box は親要素のマイナス n + 1 の子ですか？これを把握 時間がかかることがあります。これを簡素化するために、 より具体的なクラス名にする必要があります。

.final-box-title {
  /* styles */
}

クラス名を置き換えると不自然に思われるかもしれませんが、 はるかにシンプルになりますたとえば以前のバージョンでは 要素はその型の最後の要素であるため、最初にその要素に関する 他の要素を使用して、後続の要素に nth-last-child である。この方法では、モデルよりもコンピューティング コストが クラス名のみに基づいてセレクタと要素を照合できます。

スタイルを設定する要素の数を減らす

パフォーマンスに関するもう一つの考慮事項（多くの場合、セレクタよりも重要なもの） 複雑さとは、要素が変更されたときに行う必要のある作業の量です。

一般的に、計算された要素スタイルを計算するための最悪のケースのコストは 要素の数にセレクタ数を掛けた値になります。これは、 各要素を少なくとも 1 回はすべてのスタイルと照合して、 一致します。

スタイル計算で、無効化する代わりに、一部の要素を直接ターゲットにできる ページ全体に表示されます。最新のブラウザでは、これはあまり問題にならない傾向があります。これは、 ブラウザで、変更が影響を与える可能性のあるすべての要素を常にチェックする必要はありません。 一方、古いブラウザは、このようなタスクに必ずしも最適化されているとは限りません。説明 無効化される要素の数を減らす必要があります。

スタイルの再計算費用を測定する

スタイル再計算のコストを測定する方法はいくつかあります。 アクセスできます。それぞれ、ブラウザで測定するかどうかによって異なる または、このプロセスにかかる時間を測定したい場合も、 ウェブサイトの実際のユーザーを考慮します

Chrome DevTools でスタイル再計算コストを測定する

スタイル再計算のコストを測定する方法の一つは、 パネルを開きます。開始する手順は次のとおりです。

1. DevTools を開きます。
2. [パフォーマンス] タブに移動します。
3. [セレクタの統計データ] チェックボックスをオンにします（省略可）。
4. [Record] をクリックします。
5. ページを操作する。

録画を停止すると、次のような画像が表示されます。

</ph>

上部のストリップはミニチュアのフレームチャートで、 なります。アクティビティがストリップの下部に近いほど、早くなります。 ブラウザがペイントしている最中です。フレームチャートが平行になって 上に赤いバーが付いている場合、 実行時間が長くなります。

</ph>

スクロールのような操作中の長時間実行フレームは、閉じる価値があります。 見てください大きな紫色のブロックが表示されたら、アクティビティを拡大して、 「スタイルを再計算」というタイトルの作業を行い 時間をかける必要がありません。

</ph>

イベントをクリックすると、そのコールスタックが表示されます。レンダリング処理の原因が ユーザー操作により、スタイル変更をトリガーした JavaScript が呼び出されます。 また、変更の影響を受ける要素の数も示されており、900 を少し上回る 要素の内容と、スタイルの計算にかかった時間を示しています。こちらの コードを修正するための情報を探します

[セレクタの統計データ] チェックボックスをオンにした場合 [Performance Panel] 設定に移動し、 同じ名前の別のタブが表示されます。

</ph> <ph type="x-smartling-placeholder">

このパネルには、各セレクタの相対的なコストに関する有用なデータが表示されるので、 コストの高い CSS セレクタを特定できます

詳しくは、CSS セレクタの統計データに関するドキュメントをご覧ください。

実際のユーザーのスタイル再計算費用を測定する

スタイルが再計算されるのにかかる時間については、 Long Animation Frames API（ウェブサイトの実際のユーザー） ツールが用意されています。この API のデータは、 web-vitals JavaScript ライブラリ、 これにはスタイル再計算時間も含まれます

やり取りのプレゼンテーションの遅延が主な理由と考えられる場合は、 ページの INP に貢献したユーザーは 再計算に費やす時間が増えます詳細については、このモジュールの フィールドでのスタイル再計算時間を測定する方法をご確認ください。

リソース

• Chrome DevTools のセレクタの統計データ
• Blink でのスタイル無効化
• Interaction to Next Paint（INP）
• web-vitals JavaScript ライブラリ
• 現場でのスタイル再計算時間を測定する

Markus Spiske 著「Unsplash」のヒーロー画像