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

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

Mariko Kosaka

入力はコンポジタに送られます

今回は、Chrome の詳細について 4 部構成のブログシリーズの最後です。データがどのように処理されるかをウェブサイトを表示するためのコードです前回の投稿では、レンダリングプロセスとコンポジタについて学びました。この投稿ではユーザー入力を受け取ったときにコンポジタがスムーズなインタラクションをどのように実現しているかを見てみましょう。

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

「入力イベント」が聞こえた場合テキストボックスでの入力やマウスクリックだけと思えるかもしれませんが、ブラウザの観点から見ると、入力とはユーザーのあらゆる操作を指します。マウスホイールのスクロールは入力タップやマウスオーバーも入力イベントです。

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

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

</ph>

</ph> 図 2: ページのレイヤの上にホバーしているビューポート

前回の投稿では、コンポジタがスクロールをスムーズに処理するために、レイヤに分割されます。ページに入力イベントリスナーがアタッチされていない場合、Compositor スレッドはメインスレッドから完全に独立して新しい複合フレームを作成します。イベントでページにアタッチされたでしょうかコンポジタスレッドは、イベントにどうすればよいでしょうか。

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

JavaScript の実行はメインスレッドの仕事であるため、ページが合成されるとコンポジタスレッドがイベントハンドラが接続されているページの領域を「非高速スクロール可能領域」としてマークします。方法この情報があれば、コンポジタスレッドは入力イベントをメインスレッドにその地域でイベントが発生したときに通知を受け取ることができます入力イベントがこの領域の外側にある場合、コンポジタスレッドは、メインスレッドを待たずに新しいフレームの合成を続行します。

制限された非高速スクロール可能領域 — </ph> 図 3: 非高速スクロール可能領域への入力の図

イベントハンドラを作成するときの注意

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

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

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

全画面表示の非高速スクロール可能領域 — </ph> 図 4: ページ全体をカバーする非高速スクロール可能領域への入力の説明図

これを回避するには、イベントで passive: true オプションを渡して、呼び出すことができます。これにより、メインスレッドでイベントをリッスンすることをブラウザに通知しますが、コンポジタは先に進んで新しいフレームを合成することもできます。

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

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

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

ポインタイベントで 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 の実行が過剰に画面を更新できます。

フィルタ未適用のイベント — </ph> 図 7: イベントがフレームタイムラインにフラッドを引き起こし、ページジャンクが発生する

メインスレッドの過剰な呼び出しを最小限に抑えるために、Chrome では、 wheel、mousewheel、mousemove、pointermove、touchmove など）が表示され、ディスパッチが次の時点まで遅れます。次のrequestAnimationFrameの直前に表示されます

合併イベント — </ph> 図 8: 前と同じタイムラインだが、イベントが融合して遅延している

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

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

ほとんどのウェブアプリケーションでは、優れたユーザーエクスペリエンスを提供するには、統合されたイベントで十分です。ただし、描画アプリケーションや、アプリケーションベースのパスを touchmove 座標の場合、滑らかな線を引くために中間の座標が失われる可能性があります。その場合、ポインタイベントで getCoalescedEvents メソッドを使用して、これらの情報を取得できます。イベントです。

getCoalescedEvents — </ph> 図 9: スムーズなタッチジェスチャーパス（左側）、結合された限定的なパス（右側）

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、安田木久子氏 Nasko Oskov Charlie Reis です

このシリーズはいかがでしたか？今後の投稿についてご不明な点やご意見がございましたら、以下のコメント欄または @kosamari からご意見をお寄せください。。