投稿者：Nolan Lawson、Microsoft Edge Project Manager



スクロールは、Web上で最も古い相互作用の1つです。 プルトゥリフレッシュメソッドと無限のダウンロードリストが登場するずっと前に、控えめなスクロールバーがWeb上のスケーリングの元の問題を解決しました。利用可能な表示領域を超えるコンテンツと対話する方法ですか。



今日、スクロールは依然としてWeb上で最も基本的な相互作用であり、おそらく最も誤解されています。 たとえば、次のシナリオの違いを知っていますか？

• ユーザーは、タッチパッド上で2本の指でページをスクロールします。
• ユーザーは、タッチスクリーン上で1本の指でスクロールします。
• ユーザーがマウスホイールをスクロールします。
• ユーザーはスクロールバーをクリックして上下にドラッグします
• ユーザーがキーボードの上、下、PageUp、PageDown、およびスペースバーの矢印を押す

平均的なインターネットユーザー（または平均的なWeb開発者も）に尋ねると、これらのアクションは同等であることがわかります。 真実ははるかに興味深いです。



結局のところ、これら5つの入力メソッドは、特にパフォーマンスとブラウザー間の互換性の点で非常に異なる特性を持っています。 それらの一部（タッチスクリーンのスクロールなど）は、重いJavaScriptを使用しているページでもおそらくスムーズですが、他のキーボード（キーボードからのスクロールなど）からは同じページが遅れて応答しなくなります。 さらに、ある種のスクロールはDOMイベントハンドラーによって遅くすることができますが、他の種類はできません。 ここで何が起こっていますか？



この質問に答え、サイトに最もスムーズなスクロールを実装する方法を理解するために、ブラウザがマルチスレッドと入力をどのように処理するかを理解し理解するために戻ってみましょう。

マルチスレッドWeb

概念的には、Webはシングルスレッド環境です。 JavaScriptはDOMをブロックし、DOMはJavaScriptをブロックします。これは、両方が同じスレッド（多くの場合「メインスレッド」または「UIスレッド」と呼ばれる）を争うためです。



たとえば、この（ひどい）JavaScriptスニペットをページに追加すると、パフォーマンスの低下がすぐにわかります。

setInterval(() => { var start = Date.now(); while (Date.now() - start < 500) {/* wheeeee! */} }, 1000);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このJavaScriptが無限ループで回転している間、ボタンは機能せず、フォーム要素は応答せず、アニメーションGIFでさえ遅くなります。あらゆる意味で、ページがフリーズします。 シンプルなデモで実際の効果を調べることができます。







さらに、キーボードの上下キーを使用してページをスクロールしようとすると、JavaScriptの実行が停止するまでページが予測どおりにスタックします。 これはすべて、Webをシングルスレッド環境と見なしているという明確な証拠です。



面白い変則があります：タッチスクリーンをスクロールしようとすると、JavaScriptはページ上の他のすべてをブロックしますが、ページは完全に上下にスクロールします。 同じことは、タッチパッド、マウスホイールからのスクロール、およびクリックアンドドラッグカーソルでページをキャプチャした後のスクロール（ブラウザーによって異なります）にも当てはまります。



どういうわけか、一部のスクロールアクションはページの状態を変更できますが、他のすべて（ボタン、データ入力フィールド、GIF）は完全にフリーズします。 これをシングルスレッドWeb理論とどのように組み合わせることができますか？

2つのスレッドの履歴

結局のところ、一般に、「ブラウザーはシングルスレッド」という論文は正しいのですが、重要な例外があります。 スクロールは、その多様性すべてにおいて、そのような例外の1つです。



長年にわたり、ブラウザ開発者は、補助的な作業をバックグラウンドスレッドにアンロードすると、スムーズな操作と感度に大きなメリットがもたらされることに気付きました。 スクロールは主要なブラウザエクスペリエンスにとって非常に重要であるため、このタスクはそのような最適化のためにすぐに選択されました。 現在、すべての主要なブラウザーエンジン（Blink、EdgeHTML、Gecko、WebKit）は、実行のメインスレッドの外側でのスクロールをある程度サポートしています（Firefoxは、 Firefoxバージョン46からクラブに参加した最後の人です）。



バックグラウンドスクロールでは、すべてのスクロールが個別のスレッドで実行されるため、ページが乱雑になってもスムーズにスクロールします。 スクロールに関係のない外部メカニズムを介してページと対話しようとする場合のみ-キーを押し、入力フィールドにデータを入力し、リンクをクリックします-ファサードがリセットされ、サロントリックの本質が完全に明らかになります。 （うまくいくとすれば、これは素晴らしいトリックです！）



確かに、非同期スクロールには、チェッカーボード効果と呼ばれる一般的な副作用があります。 iOS用のSafariで最初に登場したのは、チェス盤のように灰色と白色のセルの形でした。 最新のブラウザのほとんどでは、ブラウザがページをレンダリングできる速度よりも速くスクロールすると、画面上の空白スペースとして効果が現れます。 これは理想的ではありませんが、ブロックされた、けいれんする、または応答しないスクロールと比較して許容できる妥協です。







残念ながら、スクロールを実行のバックグラウンドスレッドに転送することは必ずしも容易ではありません。 ブラウザは、オペレーティングシステムが同時入力を許可している場合にのみこれを行うことができ、これはデバイスごとに異なる場合があります。 特に、キーボード入力はマウスやタッチデバイスの入力ほど最適化されていないため、すべてのブラウザでキーボードから入力する場合、最終的には大幅な遅延が発生します。



ここでは、少し話が有益です。 WindowsやmacOSなどのオペレーティングシステムが最初に登場したとき、実行スレッドは1つしか許可されておらず、同時入力を提供する必要性をほとんど予見していませんでした。 マルチコアマシンが登場して初めて、オペレーティングシステムがアーキテクチャに並列性を組み込み始めました。



動物の初歩的な器官が進化の歴史を理解できるように、ウェブ上でスクロールする方法を見ると、オペレーティングシステムの単一スレッドの起源が現れます。 オペレーティングシステムが、マウス、キーボード、または他のデバイスからの並列入力を許可している場合にのみ、ブラウザは、実行のメインスレッドを混乱させるJavaScriptの長時間の実行に影響されないようにスクロールを効果的に最適化できます。



ただし、Microsoft Edge開発チームでは、その方法に関係なく、スムーズで応答性の高いスクロールを保証するために前進しています。 EdgeHTML 14（Windows 10 Anniversary Updateに含まれていた）では、次のメソッドのバックグラウンドスクロールをサポートしています。

• 1本指のタッチスクリーン
• 2本の指、タッチパッド
• マウスホイール
• スクロールバー

Edgeを他のデスクトップブラウザーと比較すると、スクロールバーを使用した非同期スクロール、つまり、マウスでスクロールバーを押したまま移動し、スクロールバーまたは矢印をクリックするだけがサポートされていることがわかります。 （実際、発表なしで、この機能をAnniversary Updateで導入しました！）



Windows 10（14393、Surface Book）およびmacOS Sierra（10.12、MacBook Air）のテスト結果によると、次の結果が得られました。

	2本指タッチパッド	タッチ	マウスホイール	スクロールバー	キーボード
エッジ14（Windows）	あります	あります	あります	あります	いや
Chrome 56（Windows）	あります	あります	あります	いや	いや
Firefox 51（Windows）	いや	いや	いや	いや	いや
Chrome 56（MacOS）	あります	N / a	あります	いや	いや
Firefox 51（macOS）	あります	N / a	あります	いや	いや
Safari 10.1（MacOS）	あります	N / a	あります	いや	いや

この表が*を示しているように、スクロールの動作はブラウザーごとに、さらにはOSごとに劇的に変化します。 1つのブラウザのみで1つのスクロール方法をテストすると、ユーザーが実際に操作する方法と比較して、サイトのパフォーマンスの結果が非常に不完全になります。



一般に、スクロールはWeb上で特別な場所にあり、ブラウザが非常に一生懸命に動作して、高速で受け入れやすいことは明らかです。 ただし、Web開発者がブラウザベースの最適化を誤って無効にできる微妙な方法があります。 Web開発者がブラウザのスクロールに良い方法と悪い方法で影響を与える方法を見てみましょう。

リスニングプロセスがスクロールを妨げる方法

バックグラウンドスクロールにより、効率が大幅に向上します。スクロールとJavaScriptは完全に分離されているため、互いに干渉することなく並行して動作できます。



しかし、Webページを少し設計した人は誰でも、JavaScriptとスクロールを接続する方法を知っています。

 window.addEventListener(“wheel”, function (e) { e.preventDefault(); // oh no you don't! });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

event.preventDefault()



を呼び出すホイールリスニングプロセスを追加すると、マウスホイールとタッチパッドの両方のスクロールが100％ブロックされます。 そして明らかに、スクロールがブロックされると、バックグラウンドのスクロールもブロックされます。



そのような例の効果はそれほど明白ではありません：

 window.addEventListener(“wheel”, function (e) { console.log('wheel!'); // innocent listener, not calling preventDefault() });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数がpreventDefault()



呼び出さない場合、スクロールをまったくブロックできないか、最悪の場合は関数自体の期間だけスクロールをブロックできないとpreventDefault()



考えるかもしれません。 ただし、実際には、空のリスニングプロセスでさえ、このページのすべてのJavaScriptプロセスが完了するまでスクロールを完全にブロックします。 これは、 このデモで確認できます。



マウスホイールをリッスンすることは、大きなブロッキングJavaScript操作と相互作用しませんが、共通のイベントループがあるため、バックグラウンドスレッドは、より長いJavaScript操作が完了するまで待機してから、イベントリスナーから応答を受け取ります。



なぜ彼は待つ必要がありますか？ JavaScriptは動的なプログラミング言語であり、ブラウザーはpreventDefault()



が呼び出されないことを確信できません。 関数が単にconsole.log()



書き込んでいることが開発者に明らかであっても、ブラウザ開発者はチャンスを残さないことを好みます。 実際、空のfunction() {}



でも同じ結果になります。



これはマウスホイールだけでなく、タッチデバイスでは、 touchstartまたはtouchmoveリスニングプロセスによってスクロールをブロックすることもできます。



ページにリスナーイベントを追加するときは、パフォーマンスに影響するため注意が必要です。



スクロールJavaScript APIはいくつかありますが、スクロールはブロックされません。 スクロールイベントは多少非論理的ですが、スクロール後にブロックされないため、スクロール後に起動され 、キャンセルされません。 また、IEとMicrosoft Edgeで導入され、最近ChromeとFirefoxで導入された新しいPointer Events APIは 、元々、スクロールを誤ってブロックしないように設計されました。



wheelまたはtouchstartイベントをリッスンする必要がある場合でも、Web開発者がスクロールが最高品質で機能することを保証する方法には、いくつかの秘trickがあります。 これらのトリックのいくつかを見てみましょう。

グローバルおよびローカルのリスニングプロセス

前の例では、グローバルリスニングプロセスのケースを見ました（つまり、 ウィンドウまたはドキュメントにアタッチされています ）。 しかし、個々のスクロール要素のリスニングプロセスについてはどうでしょうか。



言い換えると、スクロールは機能するが、ページには独自の独立したスクロールを行う個別の領域があるページを想像してください。 この領域でのみリスニングプロセスを追加すると、ブラウザはページ全体のスクロールをブロックしますか？

 document.getElementById('scrollableDiv') .addEventListener(“wheel”, function (e) { // In theory, I can only block scrolling on the div itself! });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単なデモページで確認すると、スクロールのリスニングプロセスが独立したスクロールのdivにある場合、Microsoft EdgeとSafariはドキュメント全体のスムーズなスクロールを残すことに気付くでしょう。



ブラウザとその動作の表は次のとおりです。

	2本指タッチパッド	タッチ	マウスホイール	クリックアンドドラッグ	キーボード
デスクトップエッジ14（Windows）	あります	あります	あります	あります	いや
デスクトップChrome 56（Windows）	いや	あります	いや	いや	いや
デスクトップFirefox 51（Windows）	いや	いや	いや	いや	いや
デスクトップChrome 56（MacOS）	いや	N / a	いや	いや	いや
デスクトップFirefox 51（MacOS）	あります	N / a	あります	いや	いや
Safari 10.1（MacOS）	あります	N / a	あります	いや	いや

結果は、これらのブラウザ機能を活用するためにWeb開発者が利用できる最適化があることを示しています。 ドキュメント全体に対してホイール/タッチリスニングプロセスを使用する代わりに、リスニングプロセスをドキュメントの特定のサブセクションに追加して、ページの他のすべての部分でスクロールがスムーズに維持されるようにすることをお勧めします。 つまり、ホイール/タッチスタートリスニングプロセスを可能な限り最高レベルに委任するのではなく、必要な要素のためにそれらを分離するのが最善です。



残念ながら、すべてのJavaScriptフレームワークでこの方法が許可されているわけではありません。特に、Reactは、ページの一部にのみ適用する場合でも、ドキュメント全体にグローバルなリスニングプロセスを追加する傾向があります。 ただし、この問題専用のオープンチケットがあり、Reactの担当者は、プルリクエストを喜んで受け入れると述べました。 （ 私たちの提案に非常に迅速に反応したReactの人たちを尊重します ）

パッシブリスニングプロセス

ホイール/タッチスタートのグローバルリスニングプロセスを避けることは良い習慣ですが、達成しようとしている効果によっては、不可能な場合もあります。 また、いくつかの点で、単にPreventDefault()



を呼び出す可能性があり、それを待っているために、イベントをリッスンするだけでブラウザが全世界を停止するのは馬鹿げているように見えます。



幸いなことに、Web開発者がリスニングプロセスを「パッシブ」として明示的にマークし、待機を回避できるようになったときに、ブラウザーに新しい機能が表示されるようになりました。

 window.addEventListener(“wheel”, function (e) { // Not calling preventDefault()! }, { passive: true } // I pinkie-swear I won't call preventDefault() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチでは、ブラウザはホイールリスニングプロセスが完全に存在しないかのようにスクロールを処理します。 この機能は、Chrome、Firefox、Safariの最新バージョンで既に利用可能であり、Microsoft Edgeの将来のリリースですぐに利用可能になるはずです 。 （パッシブリスニングプロセスを認識しないブラウザーをサポートするには、 機能検出を使用する必要があることに注意してください）。



一部のイベント（ touchstartやtouchmoveを含む）では、バージョン56のChromeが介入することを決定し、デフォルトでパッシブにしました 。 リスニングプロセスを追加する場合、ブラウザ間のこのわずかな違いに留意してください！

おわりに

これまで見てきたように、Webでのスクロールは非常に複雑なプロセスであり、すべてのブラウザーはパフォーマンスを改善するさまざまな段階にあります。 しかし、全体として、Web開発者に明確なアドバイスを提供できます。



まず、 ホイールまたはタッチリスナープロセスをグローバルドキュメントまたはウィンドウオブジェクトに追加するのではなく、個々のスクロールで小さな要素に追加するのが最善です。 また、開発者は、互換性の問題を回避するために、可能であれば機能検出を使用して、パッシブリスニングプロセスを使用する必要があります。 ポインターイベント（そこにpolyfillがあります ）を使用し、 スクロールイベントをリッスンすることも、不注意でロックをスクロールするのを防ぐ確実な方法です。



この記事がWeb開発者に役立つヒントを提供し、内部のブラウザが何であるかを一目で見られることを願っています。 疑いもなく、ブラウザが進化し、ウェブが成長するにつれて、スクロールの仕組みはさらに複雑で洗練されたものになります。



Microsoft Edgeチームは、この分野で革新を続け、より多くのサイトとユーザーにシームレスなスクロールを提供します。 控えめなスクロールバー-Webで最も古く、物議を醸している相互作用についてこれを考えてみましょう！



*結果は、2017年2月に各ブラウザの最新バージョンで取得されました。 それ以来、Firefox 52はスクロールのサポートを更新し、スクロールバーによるスクロールを除くすべてのテストでEdge 14の動作と一致するようになりました。 他のブラウザでもスクロールの実装が改善され、ウェブがより速く、より影響を受けやすくなることを願っています！