さて、これをすぐに邪魔にならないようにしましょう。 私は嫌いウェブサイトを添付します wheel
(また touchstart
と touchmove
)ページへのイベント。 それらを完全に嫌います。 主な理由は、特にモバイルでの恐ろしい結果のパフォーマンスです。 ご覧のとおり、イベントはキャンセルできるため、ブラウザはイベントリスナーの実行が終了するまでページの再描画を待機する必要があります。 イベントがすべてのスクロールで実行される場合、特にイベントをデバウンスしない場合、ページのスクロールは非常にぎこちなくなります。 ありがたいことに、解決策があります:パッシブイベントリスナー。
パッシブイベントリスナーを使用すると、キャンセルできないハンドラーをイベントにアタッチして、ブラウザーでイベントリスナーを最適化できます。 これにより、ブラウザは、たとえば、イベントハンドラが実行を終了するのを待たずに、ネイティブの速度でスクロールし続けることができます。
これらは仕様に比較的新しく追加されたものですが、ほとんどの大手プレーヤーによってすでにサポートされています。 (基本的に、IE、Edge、Opera Miniを除くすべての人。)
さらに、それらの使用法は、既存の動作を実際に壊さないようなものです。 他のブラウザをサポートする必要がある場合は、このpolyfillを使用できます。
使用法
残念ながら、パッシブイベントの使用はかなり複雑です。
元のコードが次のようなものだとします。
// Really, if you're using wheel, you should instead be using the 'scroll' event, as it's passive by default.
document.addEventListener('wheel', (evt) => {
// ... do stuff with evt
}, true)
これに置き換える必要があります:
document.addEventListener('wheel', (evt) => {
// ... do stuff with evt
}, {
capture: true,
passive: true
})
うん。 知っている。 頭を包むことはほとんど不可能です。 😉
説明してみましょう。
したがって、スクロールイベントを登録するときに、最後のパラメータを追加することがよくあります。 true
、イベントをキャプチャフェーズで実行する必要があることを示します。 (すなわち。 ボトムアップではなくトップダウン)
パッシブイベントを有効にする新機能の1つは、EventListenerOptions仕様です。 怖いように聞こえますが、実際には、そのキャプチャブール値をいくつかのプロパティを持つオブジェクトに置き換えるだけです。 この場合、 capture
に true
最初の例と同じ結果を取得してから、 passive
に true
イベントをパッシブにします。
パフォーマンスをさらに向上させるには、イベントを抑制またはデバウンスしていることを確認してください。 🙂
用途
モバイルで最大のパフォーマンスペナルティ(たとえば5倍速い)が認識されるイベントは、スクロール、ホイール、タッチスタート、およびタッチムーブです。 。 スクロールはデフォルトですでにパッシブであるため、方程式から1つのイベントが除外されます。 Chrome 55以降、touchstartとtouchendもパッシブです。
したがって、モバイルでこれら4つのイベントのいずれかを処理している場合は、その小さなポリフィルを投入して追加しても問題はありません。 { passive: true }
それらのイベントに。 99 % o fとにかくそれらのイベントをキャンセルする必要がなく、 { passive: true }
パフォーマンスを大幅に向上させることができます。 では、なぜですか?