このページは Cloud Translation API によって翻訳されました。

最新のウェブブラウザの詳細（パート 4）

Mariko Kosaka

Twitter

コンポジタに入力されます

全 4 部構成のブログシリーズの最後となります。今回は Chrome の内部を見て、コードの処理によってウェブサイトを表示する方法について解説します。前回の投稿では、レンダリングプロセスを確認し、コンポジターについて学習しました。この投稿では、コンポジタがユーザー入力を受け取ったときにスムーズな操作を可能にする仕組みについて説明します。

ブラウザの視点からイベントを入力する

「入力イベント」と聞くと、テキストボックスへの入力またはマウスクリックのみを思い浮かべるかもしれませんが、ブラウザの観点からは、入力はユーザーのあらゆるジェスチャーを意味します。マウスホイールのスクロールは入力イベントであり、タップまたはマウスオーバーも入力イベントです。

画面のタップなどのユーザージェスチャーが発生したとき、最初にそのジェスチャーを受け取るのはブラウザプロセスです。ただし、タブ内のコンテンツはレンダラプロセスによって処理されるため、ブラウザプロセスはそのジェスチャーが発生した場所のみを認識します。したがって、ブラウザプロセスはイベントタイプ（touchstart など）とその座標をレンダラプロセスに送信します。レンダラプロセスは、イベントターゲットを見つけてアタッチされているイベントリスナーを実行することで、イベントを適切に処理します。

コンポジタが入力イベントを受け取る

図 2: ページレイヤにカーソルを合わせた状態のビューポート

前回の投稿では、ラスター化されたレイヤを合成することで、コンポジタがスクロールをスムーズに処理する方法について説明しました。ページに入力イベントリスナーがアタッチされていない場合、コンポジタスレッドは、メインスレッドから完全に独立して新しい複合フレームを作成できます。では、ページにイベントリスナーがアタッチされていたらどうなるでしょうか。イベントの処理が必要かどうかをコンポジタスレッドはどのように判断するのでしょうか。

高速スクロールできない領域について

JavaScript の実行がメインスレッドのジョブであるため、ページが合成されると、コンポジタスレッドは、イベントハンドラがアタッチされているページ領域を「高速スクロール以外の領域」とマークします。この情報を保持することで、コンポジタスレッドは、メインスレッドでイベントが発生した場合にメインスレッドに入力イベントを確実に送信できます。入力イベントがこの領域外で発生した場合、コンポジタスレッドはメインスレッドを待たずに新しいフレームの合成を続行します。

高速でスクロールできない一部の領域 — 図 3: 高速スクロールできない領域への入力の説明

イベントハンドラを作成する際は注意する

ウェブ開発における一般的なイベント処理パターンは、イベント委任です。イベントはバブルであるため、最上位の要素に 1 つのイベントハンドラをアタッチし、イベントターゲットに基づいてタスクをデリゲートできます。以下のようなコードを見たり作成したりしたことがあるかもしれません。

document.body.addEventListener('touchstart', event => {
    if (event.target === area) {
        event.preventDefault();
    }
});

すべての要素に対してイベントハンドラを 1 つ記述するだけで済むため、このイベント委任パターンのエルゴノミクスが便利です。しかし、ブラウザからこのコードを見ると、ページ全体が高速スクロールできない領域としてマークされています。つまり、アプリがページの特定の部分からの入力を考慮しない場合でも、コンポジタスレッドはメインスレッドと通信して、入力イベントが発生するたびにそれを待機する必要があります。したがって、コンポジタのスムーズなスクロール機能が無効になります。

ページ全体、高速スクロールできない領域 — 図 4: ページ全体を覆う、高速スクロールできない領域への入力の説明図

この問題を軽減するには、イベントリスナーで passive: true オプションを渡します。これは、引き続きメインスレッドでイベントをリッスンする必要があることをブラウザに伝えますが、コンポジタは新しいフレームを合成することもできます。

document.body.addEventListener('touchstart', event => {
    if (event.target === area) {
        event.preventDefault()
    }
 }, {passive: true});

イベントがキャンセル可能かどうかを確認する

ページスクロール — 図 5: ページの一部が横スクロールに固定されたウェブページ

ページ内に、スクロール方向を水平方向のスクロールのみに制限するとします。

ポインタイベントで passive: true オプションを使用すると、ページのスクロールは滑らかになりますが、スクロール方向を制限するために preventDefault を設定する時点までに垂直スクロールが開始されている可能性があります。これを確認するには、event.cancelable メソッドを使用します。

document.body.addEventListener('pointermove', event => {
    if (event.cancelable) {
        event.preventDefault(); // block the native scroll
        /*
        *  do what you want the application to do here
        */
    }
}, {passive: true});

別の方法として、touch-action などの CSS ルールを使用して、イベントハンドラを完全に削除することもできます。

#area {
  touch-action: pan-x;
}

イベントのターゲットを見つける

コンポジタスレッドが入力イベントをメインスレッドに送信したら、まず、ヒットテストを実行してイベントターゲットを見つけます。ヒットテストでは、レンダリングプロセスで生成されたペイントレコードデータを使用して、イベントが発生したポイント座標の下に何があるかを調べます。

メインスレッドへのイベントのディスパッチを最小限に抑える

前回の投稿では、一般的なディスプレイが 1 秒間に 60 回更新する方法と、スムーズなアニメーションを実現するために必要なことについて説明しました。入力の場合、一般的なタッチスクリーンデバイスでは 1 秒間に 60 ～ 120 回、マウスは 1 秒間に 100 回イベントを配信します。入力イベントの忠実度が画面の更新能力よりも高い。

touchmove などの継続的なイベントがメインスレッドに 1 秒間に 120 回送信された場合、画面の更新速度に比べ、大量のヒットテストと JavaScript の実行がトリガーされる可能性があります。

フィルタ未適用のイベント — 図 7: ページジャンクを引き起こすフレームタイムラインへのフラッディングが発生するイベント

Chrome では、メインスレッドへの過剰な呼び出しを最小限に抑えるため、継続的なイベント（wheel、mousewheel、mousemove、pointermove、touchmove など）を統合し、次の requestAnimationFrame の直前までディスパッチを遅らせます。

統合されたイベント — 図 8: 前と同じタイムラインだが、イベントが統合されて遅延している

keydown、keyup、mouseup、mousedown、touchstart、touchend などの個別のイベントは直ちにディスパッチされます。

`getCoalescedEvents` を使用してフレーム内イベントを取得する

ほとんどのウェブアプリケーションでは、イベントの統合だけで良好なユーザーエクスペリエンスを実現できます。ただし、touchmove 座標に基づいて描画アプリケーションやパスの配置などを作成している場合、滑らかな線を描画するために中間の座標が失われる可能性があります。その場合は、ポインタイベントで getCoalescedEvents メソッドを使用して、統合されたイベントに関する情報を取得できます。

window.addEventListener('pointermove', event => {
    const events = event.getCoalescedEvents();
    for (let event of events) {
        const x = event.pageX;
        const y = event.pageY;
        // draw a line using x and y coordinates.
    }
});

次のステップ

このシリーズでは、ウェブブラウザの内部動作について説明しました。DevTools でイベントハンドラに {passive: true} を追加することが推奨される理由や、スクリプトタグに async 属性を記述する理由について、これまで考えたことがない方は、このシリーズが、高速でスムーズなウェブエクスペリエンスを実現するためにブラウザでこの情報が必要な理由を理解していただければ幸いです。

Lighthouse を使用する

ブラウザにはなじみのないコードにしたいけれど、どこから手を付けたらよいかわからない場合は、Lighthouse がウェブサイトの監査を実施して、何が適切か、何を改善すべきかに関するレポートを提供するツールです。監査のリストを確認することで、ブラウザがどのようなことに注意を払っているかを把握できます。

パフォーマンスの測定方法

パフォーマンスの微調整はサイトによって異なる可能性があるため、サイトのパフォーマンスを測定して、サイトに最適な方法を決定することが重要です。Chrome DevTools チームには、サイトのパフォーマンスを測定する方法に関するチュートリアルがいくつか用意されています。

サイトに機能ポリシーを追加する

さらに、機能ポリシーは新しいウェブプラットフォーム機能で、プロジェクトをビルドする際のガードレールとして利用できます。機能ポリシーをオンにすると、アプリの特定の動作が保証され、ミスを防ぐことができます。たとえば、アプリが解析をブロックしないようにするには、同期スクリプトポリシーでアプリを実行します。sync-script: 'none' を有効にすると、パーサーをブロックする JavaScript は実行されなくなります。これにより、どのコードもパーサーをブロックする必要がなく、ブラウザはパーサーの一時停止を気にする必要がなくなります。

まとめ

ウェブサイトを作り始めたとき、私はコードをどのように記述するか、何が生産性の向上に役立つかということしか考えていませんでした。これらは重要ですが、記述したコードをブラウザがどのように受け取るかについても考える必要があります。最新のブラウザは、優れたウェブエクスペリエンスをユーザーに提供する方法に投資を続けてきました。コードを整理してブラウザに配慮すると、ユーザーエクスペリエンスが向上します。ブラウザへの対応にぜひご協力ください。

本シリーズの初期の下書きをレビューしていただいた皆様に心より感謝いたします。以下はその一例です。Alex Russell、Paul Irish、 Meggin Kearney、Eric Bidelman、 Mathias Bynens、 Addy Osmani、 Od.ovisOsmani、Osmani、Osmani、Osmani 氏

このシリーズはいかがでしたか？今後の投稿についてご質問やご提案がありましたら、以下のコメントセクションまたは Twitter の @kosamari からお寄せください。