サイトやアプリがスムーズに動作していないと、ユーザーは気付きます。そのため、レンダリング パフォーマンスを最適化することは非常に重要です。
現在のウェブのユーザーは、アクセスするページがインタラクティブでスムーズであることを期待しています。そのため、時間と労力をより多く注ぐ必要があります。ページは読み込みが速いだけでなく、ライフサイクル全体を通じてユーザー入力にすばやく応答する必要があります。実際、ユーザー エクスペリエンスのこの側面こそが、Interaction to Next Paint(INP)指標で測定されるものです。INP が高い値を示しているページは、ユーザーのニーズに常に確実に応答しています。
ページの応答性が速く感じられる主な要因は、ユーザー操作に応じて実行される JavaScript の量ですが、ユーザーが期待しているのはユーザー インターフェースの視覚的な変化です。ユーザー インターフェースの視覚的な変更は、複数のタイプの処理の結果であり、多くの場合、まとめてレンダリングと呼ばれます。この処理は、ユーザー エクスペリエンスが高速で信頼できるものになるように、できるだけ迅速に行う必要があります。
ユーザー操作に迅速に応答するページを作成するには、HTML、JavaScript、CSS がブラウザでどのように処理されるかを理解し、作成したコードと、組み込んだサードパーティ コードが可能な限り効率的に実行されるようにする必要があります。
デバイスの更新レートに関する注意事項

ほとんどのデバイスは、画面を1 秒あたり 60 回更新します。各更新で表示されるビジュアル出力は、一般にフレームと呼ばれます。次の動画では、フレームのコンセプトについて説明しています。
デバイスの画面は常に一定のレートで更新されますが、デバイスで実行されるアプリが、その更新レートに合わせて十分なフレームを生成できるとは限りません。たとえば、アニメーションや遷移が実行されている場合、ブラウザはデバイスの更新レートに合わせて、画面の更新ごとに 1 つのフレームを生成する必要があります。
一般的なディスプレイが 1 秒あたり 60 回更新されることを考えると、簡単な計算で、ブラウザが各フレームを生成するのに 16.66 ミリ秒かかることがわかります。ただし、実際にはブラウザにはフレームごとに独自のオーバーヘッドがあるため、すべての処理を 10 ミリ秒以内に完了する必要があります。このバジェットを満たさないと、フレームレートが低下し、ページ コンテンツが画面上でジッターが発生します。この現象は、よくジャンクと呼ばれます。
ただし、目標は、実行する作業の種類によって異なります。アニメーションでは、画面上のオブジェクトが 2 つのポイント間の一連のフレーム間で補間されるため、10 ミリ秒のしきい値を満たすことが重要です。ユーザー インターフェースの個別の変更(つまり、中間のモーションがない場合に状態を切り替える)については、ユーザーが即時に感じられる時間枠で変更を行うことをおすすめします。このような場合、100 ミリ秒という値がよく引用されますが、INP 指標の「良好」のしきい値は 200 ミリ秒以下に設定されています。これは、さまざまな機能を備えた幅広いデバイスに対応するためです。
ジャンクを回避するためにアニメーションに必要な多数のフレームを生成することや、ユーザー インターフェースの視覚的な変化をできるだけ早く生成することなど、どのような目標であっても、ブラウザのピクセル パイプラインの仕組みを理解することは、作業に不可欠です。
ピクセル パイプライン
ウェブ デベロッパーとして知っておくべき、注意すべき 5 つの主要な分野があります。これらの 5 つの領域は、最も制御が可能な領域であり、それぞれがピクセルから画面へのパイプラインの重要なポイントを表します。

- JavaScript: JavaScript は通常、ユーザー インターフェースの視覚的な変更につながる処理を処理するために使用されます。たとえば、jQuery の
animate
関数、データセットの並べ替え、ページへの DOM 要素の追加などです。ただし、視覚的な変更をトリガーするために JavaScript が厳密に必要というわけではありません。CSS アニメーション、CSS 遷移、Web Animations API を使用してページ コンテンツをアニメーション化できます。 - スタイルの計算: 一致するセレクタに基づいて、どの CSS ルールがどの HTML 要素に適用されるかを判断するプロセスです。たとえば、
.headline
は、headline
のクラスを含むclass
属性値を持つすべての HTML 要素に適用される CSS セレクタの例です。ルールが判明すると、ルールが適用され、各要素の最終的なスタイルが計算されます。 - レイアウト: ブラウザは、要素に適用されるルールを認識すると、要素が占有するスペースや画面上の表示場所など、ページのジオメトリの計算を開始できます。ウェブのレイアウトモデルでは、1 つの要素が他の要素に影響する可能性があります。たとえば、
<body>
要素の幅は通常、ツリー全体の子要素の寸法に影響するため、ブラウザにとってプロセスが非常に複雑になる可能性があります。 - ペイント: ペイントは、ピクセルを塗りつぶすプロセスです。ページ上のレイアウトが計算された後、テキスト、色、画像、境界線、シャドウなど、要素の視覚的な側面をすべて描画します。通常、描画は複数のサーフェス(レイヤと呼ばれることもあります)で行われます。
- 合成: ページの一部が複数のレイヤに描画されている可能性があるため、ページが想定どおりにレンダリングされるように、正しい順序で画面に適用する必要があります。これは、要素が重なり合う場合に特に重要です。誤って配置すると、要素が重なって正しく表示されなくなる可能性があります。
ピクセル パイプラインのこれらの部分はそれぞれ、アニメーションにジャンクを導入したり、ユーザー インターフェースの視覚的な変化があってもフレームのペイントを遅らせたりする可能性があります。そのため、コードがトリガーするパイプラインの部分を正確に把握し、変更をレンダリングに必要なピクセル パイプラインの部分に限定できるかどうかを調査することが重要です。
「ラスタライズ」という用語は「ペイント」と組み合わせて使用されることがあります。これは、ペイントは実際には 2 つのタスクであるためです。
- ドローコールのリストを作成します。
- ピクセルの塗りつぶし。
後者は「ラスタライズ」と呼ばれます。そのため、DevTools でペイント レコードを見ると、ラスタライズが含まれていると見なす必要があります。一部のアーキテクチャでは、描画呼び出しとラスタライゼーションのリストの作成は異なるスレッドで行われますが、これはデベロッパーが制御できるものではありません。
パイプラインのすべての部分をフレームごとに変更する必要はありません。実際には、視覚的な変更を加えたときに、パイプラインが特定のフレームで通常実行される方法は 3 つあります。JavaScript、CSS、Web Animations API のいずれかです。
1. JS / CSS > スタイル > レイアウト > ペイント > 合成

要素のジオメトリ(幅、高さ、位置など)を変更する「レイアウト」プロパティ(left
や top
などの CSS プロパティなど)を変更すると、ブラウザは他のすべての要素をチェックし、ページを「再フロー」する必要があります。影響を受ける領域は塗り直す必要があり、最終的に塗装された要素を再合成する必要があります。
2. JS / CSS > スタイル > ペイント > 合成

CSS で要素の「ペイントのみ」プロパティ(background-image
、color
、box-shadow
などのプロパティ)を変更した場合、ページのビジュアル アップデートを commit するためにレイアウト ステップは必要ありません。可能であればレイアウト ステップを省略することで、次のフレームの生成に大幅なレイテンシをもたらす可能性のある、費用のかかるレイアウト作業を回避できます。
3. JS / CSS > スタイル > 複合

レイアウトもペイントも必要のないプロパティを変更した場合、ブラウザはコンポジション ステップに直接ジャンプできます。これは、ページのライフサイクルにおける負荷の高いポイント(アニメーションやスクロールなど)に使用できる、ピクセル パイプライン経由で最も低コストで望ましいパスです。豆知識: Chromium では、可能な限りコンポーザ スレッドでのみページのスクロールが行われるようにページのスクロールが最適化されています。つまり、ページが応答しなくても、ページをスクロールして、以前に画面に描画された部分を表示できます。
ウェブ パフォーマンスとは、必要な処理の効率を最大限に高めながら、処理を回避する技術です。多くの場合、ブラウザと連携して動作させる必要があります。パイプラインで示した作業は、計算コストが異なります。タスクによっては、他のタスクよりも本質的にコストが高いものもあります。
パイプラインの各部分について詳しく見てみましょう。ここでは、よくある問題と、その診断と修正方法について説明します。
ブラウザのレンダリングの最適化

パフォーマンスはユーザーにとって重要です。優れたユーザー エクスペリエンスを構築するには、ユーザー操作に迅速に反応し、スムーズにレンダリングするウェブサイトを構築する必要があります。パフォーマンス エキスパートの Paul Lewis が、ジャンクを排除し、1 秒あたり 60 フレームのパフォーマンスを維持するウェブアプリを作成する方法をご紹介します。このコースでは、アプリのプロファイリングに必要なツールを学び、レンダリング パフォーマンスが最適でない原因を特定します。また、ブラウザのレンダリング パイプラインについても学び、ユーザーが快適に使用できる高速なウェブサイトを簡単に構築するためのパターンを探ります。