【ITニュース解説】Why Input Latency Symptoms Can Mislead Developers: A Deep Dive Into the Real Causes

UIが反応しない、ボタンを押したのにハイライト表示が遅い、文字を入力したのに画面に表示されるまで少し間がある。このような入力遅延、つまりインプットレイテンシは、ウェブアプリケーションを開発する多くのエンジニアが一度は経験する問題だ。開発者はこの現象に遭遇すると、まず「JavaScriptの処理が重いせいで、メインスレッドがブロックされているからだ」と考え、パフォーマンスプロファイラを開いて長いタスクを探し、JavaScriptコードの最適化を試みることが多い。しかし、この直感的な判断は、しばしば真の原因を見誤らせることがある。実際には、入力遅延の背後には、イベント処理の仕組み、レンダリングの過程、そしてプロファイラが示す情報の複雑な関係が隠されている場合があるのだ。

ブラウザはユーザーの入力操作を単に瞬時にアプリケーションに伝えるわけではない。入力イベントはいくつかの段階を経て処理される。まず、OSとブラウザがマウスの動き、キーボードの入力、タッチ操作などのハードウェア信号を受け取る。次に、特にポインターやタッチイベントの場合、ブラウザは複数のイベントを一つにまとめたり（イベント統合、Coalescing）、まとめてからアプリケーションに渡したりすることがある。これは、アプリが大量のイベントで負荷を受けないようにするためだが、ユーザーから見ると、実際の入力とイベントが発火するタイミングにわずかなズレが生じ、それが遅延として感じられることがある。例えば、モバイルではかつて、ダブルタップを検出するためにタッチイベントが最大300ミリ秒遅延する仕様があったが、これはポインターイベントの導入により改善されている。その後、ブラウザは適切なDOM要素に対してイベントを発火させ、最終的にアプリケーションのJavaScriptで記述されたイベントリスナーが実行される。もし、このイベントがJavaScriptに到達するまでの間にメインスレッドが別の重い処理で忙しかった場合、イベントのコールバックはキューに格納され、実行が遅れてしまう。つまり、JavaScriptのコードが実行されるよりずっと前から、入力イベントはすでに遅延している可能性があるのだ。

JavaScriptがDOMの状態を更新したり、アプリケーションのロジックを実行したりした後も、すぐに画面に変化が反映されるわけではない。ブラウザは、その変更をユーザーが見える形にするために、レンダリングパイプラインと呼ばれる一連の処理を実行する。このパイプラインは、まず影響を受けるCSSスタイルを再計算し（スタイル再計算）、次に要素の位置やサイズを計算してレイアウトを決定する（レイアウト）。その後、計算された情報に基づいてピクセルを描画し（ペイント）、最後に複数の描画レイヤーを結合して最終的な画面表示を作成する（コンポジット）。これらのレンダリングステップは、JavaScriptの処理が完了した後に非同期で実行される。もしJavaScriptがメインスレッドを長時間ブロックすると、これらのレンダリング作業も待たされることになる。しかし、たとえJavaScriptの処理が迅速に終わったとしても、CSSの指定が複雑だったり、DOMの構造が大規模だったりすると、スタイル計算やレイアウト、ペイントの処理自体が重くなり、結果として画面更新が遅延することがある。この場合、JavaScriptは問題ないのに、見た目の反応が遅れることになる。

開発ツール（DevTools）のパフォーマンスプロファイラは強力なツールだが、そのタイムライン表示を正しく理解することは難しい。タイムラインには、イベントが発火した時刻やハンドラの実行時間を示す「イベントタイミング」、新しいコンテンツが描画された時刻を示す「フレーム」、メインスレッドを長時間占有する「ロングタスク」など、様々な情報が表示される。入力イベントと重なっている最も長いタスクが、必ずしも入力遅延の直接的な原因とは限らないという点に注意が必要だ。たとえば、ある長いタスクが完了した後に、ようやく入力イベントのハンドラが実行されることがある。また、JavaScriptのハンドラがトリガーしたレンダリング作業は、JavaScriptの処理が完全に終わってから始まるため、タイムライン上のJavaScriptの終了地点と実際の画面更新の間には時間差がある。入力遅延とは、イベントがブラウザに入ってから、その結果が画面に表示されるまでの全体の時間のことを指すため、イベント処理の遅延とレンダリングの遅延の両方を含んでいることを理解する必要がある。たとえば、JavaScriptのハンドラ自体は高速でも、その後に発生するスタイル再計算が長時間かかることで、ユーザーが視認できるUIの更新が遅れる場合があるのだ。

実際に、あるウェブアプリケーションで入力が遅く感じるという報告があり、プロファイラを確認したところ、イベントハンドラの処理に50ミリ秒、その後のレイアウト計算に100ミリ秒かかっていることが分かった。当初はJavaScriptのイベントハンドラを最適化したり、処理を制限したりすることで解決できると考えられた。しかし、根本的な解決策は、重いCSSセレクタを分割してレイアウト処理を高速化することや、will-changeというCSSプロパティを使ってブラウザに描画レイヤーを事前に作成させることで、レンダリングの効率を向上させることだった。このケースでは、JavaScriptではなく、レンダリング作業が真のボトルネックだったのである。

真のボトルネックを特定するためには、プロファイラのタイムラインをより詳しく分析することが重要だ。まず、入力イベントがブラウザで発火した時刻と、そのイベントのJavaScriptハンドラが実際に実行された時刻の間に大きなギャップがあるかどうかを確認する。もしギャップがあれば、その間にメインスレッドが別の処理で忙しかったことを意味する。次に、ハンドラが終了した後のスタイル計算、レイアウト、ペイントの作業時間に着目する。もしレイアウト処理が長ければ、DOM構造やCSSに高コストな部分があることを示唆している。さらに、Event Timing APIを利用して、ユーザーの入力からイベント処理までの実際の遅延をより正確に測定することも有効な手段だ。また、問題を切り分けるために、JavaScriptのイベントハンドラを最小限にして入力遅延が解消するか試す、CSSやDOMを簡素化してレイアウトのコストを測定する、Chromeのレンダリングパネルを使ってペイントやコンポジットのレイヤーを視覚化するといった方法も有効だ。

開発者が陥りがちな誤解としては、高コストなJavaScriptのみを原因だと決めつけてしまうこと、イベント統合やポインターイベントの特性による入力イベントのバッチ処理を見落とすこと、プロファイラのタイムラインを誤って解釈すること、そしてブラウザがバッテリーやCPU使用率を最適化するためにレンダリングやイベントの発火を遅らせるなどの最適化やヒューリスティックを考慮しないことなどが挙げられる。入力遅延は、一見単純な問題に見えるかもしれないが、その裏ではハードウェア入力、イベント処理、JavaScriptの実行、そしてレンダリングという複雑なダンスが繰り広げられている。それぞれの段階が遅延の原因となり得るため、JavaScriptの遅延に見える症状が、実はレンダリングやイベントディスパッチの微妙な問題である可能性も少なくない。次回、入力が遅いと感じた際には、安易にJavaScriptのハンドラだけを非難するのではなく、イベントのタイミング、レンダリングの負荷、そしてブラウザのパイプライン全体がどのように連携しているかを注意深く観察することで、真のボトルネックをより早く特定し、入力遅延を根本的に解決できるだろう。