モバイル版のCore Web Vitalsを最適化してINPを改善するには？

モバイル端末のINPを改善するうえで重要なのは、ページのダウンロードを速くすることではなく、クリック、タップ、キーボード入力の後、ブラウザーが次のフレームをできるだけ早く表示することです。画像の圧縮やCDNの導入は読み込み体験を改善できますが、ボタンをクリックしてから反応が返るまで時間がかかる問題を直接解決するものではありません。メインスレッドがスクリプトの実行やページのレンダリングに占有されていれば、操作は依然として遅くなります。

Core Web Vitalsの観点からモバイル体験を改善するには、INPを入力遅延、イベント処理時間、表示遅延に分け、時間を要している原因に応じて対処する必要があります。クリックコールバックを短縮するだけ、あるいはラボテストのスコアを一度上げるだけでは、実ユーザーの操作応答性が改善したとは言えません。

INPが測定するのは、操作から次のフレームまでの時間であり、業務の完了時間ではありません

INP（Interaction to Next Paint：次の描画までのインタラクション）は、ページのライフサイクル全体を通じて発生する、対象となるクリック、タップ、キーボード操作を観察し、最も遅い操作に近い応答状況を示します。操作が多い場合、計算時にはルールに基づいて一部の極端な値が除外されるため、すべてのクリック時間の単純な平均でも、絶対的な最大値でもありません。

GoogleのCore Web Vitals評価では、INPが200ミリ秒以下の場合は「良好」、200ミリ秒を超え500ミリ秒以下の場合は「改善が必要」、500ミリ秒を超える場合は「不良」とされます。サイトの合格判定には実訪問データの75パーセンタイルが使われ、モバイルとデスクトップがそれぞれ評価されます。これは、1回のページ訪問内で代表的なインタラクションを選ぶこととは、異なる階層の統計です。

INPはAPIの応答時間でもありません。問い合わせを送信した直後に「送信中」の状態が描画され、その後にネットワークリクエストが完了する場合、その操作のINPは低くなることがあります。しかし、INPが低いからといって業務が正常に完了したとは限りません。リクエスト時間、失敗率、重複送信は別途監視する必要があります。

まず遅い箇所を特定し、その後で対策を決める

インタラクションの入力遅延とは、ユーザーの操作からイベントコールバックの実行開始までに発生する待ち時間です。処理時間は関連するコールバックの実行にかかる時間で、表示遅延はコールバック終了から次のフレームが表示されるまでの時間です。これらのいずれも、モバイル端末でボトルネックになる可能性があります。

ユーザーがクリックしたときに、メインスレッドがスクリプトの解析、サードパーティコードの実行、または別のタスクの処理中であれば、入力遅延が増加します。コールバック内で大量の商品を同期的に絞り込んだり、フォーム全体を検証したり、多数のコンポーネントを更新したりすると、処理時間が増加します。コールバックの終了後に広範囲のスタイル計算、レイアウト、描画が必要な場合は、表示遅延が大きくなります。

Chrome DevToolsのパフォーマンスパネルを使い、メニューの展開、商品フィルター、仕様の切り替え、問い合わせの送信などを記録し、インタラクションのトレースに沿ってメインスレッドのタスクとレンダリング処理を確認できます。50ミリ秒を超えるタスクは長いタスクに分類されますが、あくまで調査の手がかりです。短いタスクが連続しても描画が遅れることがあるため、「長いタスクがない」ことをINP合格の証明としてはいけません。

スクリプトの実行を単に遅らせるより、ブロックを減らすことが重要

入力遅延が大きい場合は、ユーザーが操作を始めた後にスクリプトが集中して実行されていないか確認します。マーケティングサイトでは、オンラインサポート、分析タグ、広告トラッキング、ポップアップコンポーネントを、読み込み時間と実行コストの観点から個別に確認する必要があります。asyncやdeferを使うとスクリプトの読み込み・実行タイミングは変えられますが、実行中にメインスレッドを占有することは解消されません。

必須でないスクリプトは、ページの用途、同意の状態、実際の利用ニーズに応じて読み込み、重複したタグを整理します。遅延読み込みを行う場合も、すべてのスクリプトを初回クリック時にまとめて起動しないようにしてください。そうすると、読み込みコストがインタラクションの経路に移るだけです。

同期処理は小分けにし、バッチの間でメインスレッドを解放します。対応ブラウザーではscheduler.yield()を使用できますが、それ以外の環境では代替手段が必要です。PromiseやqueueMicrotaskだけで処理を分割しても確実ではありません。マイクロタスクキューは描画前に実行され続ける可能性があるためです。DOMに依存しない、CPU負荷の高い計算はWeb Workerに移せますが、通信やデータコピーのオーバーヘッドを評価する必要があります。

イベントコールバックとレンダリングの両方を縮小する

クリックコールバックでは、読み込み状態の表示、現在の選択肢の指定、重複送信の防止など、必要な状態変更を優先して行い、その後、緊急性の低い処理をスケジュールします。画面を変更した後に同期処理を続けても、ユーザーがすでに反応を目にしたことにはなりません。ブラウザーに描画の機会を与える必要があります。

商品フィルターでは計算結果をキャッシュし、操作のたびにすべてのデータを再走査しないようにします。フォーム検証では、文字を1つ入力するたびにフォーム全体を再計算することを避けます。デバウンスは即時性が求められない検索の負荷軽減に適していますが、ボタンの視覚的な反応を遅らせたり、必要な操作の遅延を覆い隠したりするために使うべきではありません。

表示遅延が大きい場合は、DOMの規模、スタイルの影響範囲、コンポーネントの更新境界を確認します。商品リストが長い場合は仮想化を利用できますが、アクセシビリティと検索エンジンのクロール要件にも対応する必要があります。「スタイルを書き込む—サイズを読み取る」処理を繰り返すと強制レイアウトが発生することがあるため、読み取りをまとめてから書き込みます。フレームワークを使ったアプリケーションでは、コールバック時間だけでなく、局所的な状態変化によって無関係なコンポーネントまで更新されていないか確認します。

requestAnimationFrameも、時間のかかる処理を入れておく場所ではありません。内部のコードは描画前に実行されるため、大量の計算を入れると次のフレームをブロックします。

1回のテストだけでなく、実訪問データで検証する

ラボテストは原因の再現に適しており、実ユーザーモニタリングは影響範囲の確認に適しています。PageSpeed InsightsのCrUXデータは実際の訪問体験を反映します。トラフィックが不足している場合はページ単位のデータが表示されないことがあり、データがないことを性能が良好だと解釈してはいけません。Lighthouseの合計ブロッキング時間は、読み込み段階でのメインスレッドの負荷を見つける参考になりますが、INPの代替指標ではありません。

サイト内ではweb-vitalsとそのアトリビューション機能を使用して、インタラクションの対象、ページタイプ、各段階の所要時間を記録できます。フォームの内容などの個人情報を収集しないようにしてください。テストは実際のモバイル端末と適切なCPUスロットリング条件で行います。デスクトップブラウザーの狭い画面表示だけでは、モバイル端末の処理能力の違いを反映できません。

リリースの受け入れテストでは、同種のページを近い端末条件で比較してINPの分布を確認し、重要なインタラクションが引き続き正しく完了するか再テストします。CrUXは直近28日間のデータを使用するため、変更後すぐに効果のすべてが反映されるとは限りません。GoogleのINPの定義に基づけば、有効な改善の根拠となるのは実際のインタラクションの待ち時間が短くなったことであり、リソースサイズの減少や一度のテストスコアの上昇ではありません。